mturba

Und mit welchem Kommando hast du versucht, den Hostnamen zu ändern? Auf den Switch läuft CatOS, sollte also mit set system name Switch123 funktionieren.

An der entsprechenden Stelle im Configuration Guide der ASA wird eigentlich alles gesagt: Dort wird vorgeschlagen, nur Subinterfaces zu konfigurieren und diese jeweils den VLANS zuzuordnen. Das physikalische Interface sollte nicht für die Weiterleitung von Verkehr verwendet werden.

Ich möchte mal in den Raum stellen, dass es eventuell doch möglich ist - vorausgesetzt, der Rechner hat eine Netzwerkkarte die 802.1q unterstützt. Dann könnte man das Interface Fa1/0/10 des 35xx als Trunkport mit native VLAN 3 definieren und das VLAN 2 getagged übertragen, vorausgesetzt, der Switch verwirft nicht die zu großen Frames. Siehe auch: http://www.mcseboard.de/cisco-forum-allgemein-38/0815-switch-trunkport-105634.html

Frage 1: Weil 198.18.2.63 mit der verwendeten Maske 255.255.255.224 eine Broadcastadresse ist. Frage 2: Word processing-Programme haben erstmal nichts mit Datenübertragung zu tun. Generell sind Anwendungsprogramme nicht Bestandteil des OSI-Modells, wohl aber die Dienste, die von ihnen verwendet werden. Deswegen ist TFTP hier richtig. Gruß, Martin

Kannst du mal ein "show dsl int atm0" posten? Ich hatte hier mit meinem 876 ähnliche Probleme... ein Update der Firmware des integrierten ADSL-Modems hat geholfen: ftp://ftp.cisco.com/pub/access/800/ Gruß, Martin

Wahrscheinlich hast du mit 0x21422 die Baudrate des Terminals verstellt. Entweder du probierst mit deinem Terminalprogramm einfach alle durch, oder du baust dein Teil auseinander und suchst den baud reset jumper: Cisco 2600 and 3600 Hints and Tricks [Cisco 2600 Series Multiservice Platforms] - Cisco Systems

Ja, das sollte so funktionieren: access-list match_inside deny ip 10.33.3.0 255.255.255.0 host 1.2.3.4 access-list match_inside permit ip 10.33.3.0 255.255.255.0 any global (out-1) 2 10.80.0.1 nat (inside) 2 access-list match_inside Gruß, Martin

Das hängt davon ab, was für eine Art von VPN du aufbauen willst... IPSec, L2TP, PPTP?

Hmm, so vielleicht? conf t ! controller e1 1/0 framing crc4 linecode hdb3 clock source internal channel-group 1 timeslots 1-31 speed 64 no shutdown exit ! interface serial 1/0:0 ip address 1.2.3.4 255.255.255.0 encapsulation ppp no shutdown exit ! Eventuell ist der Controller auch controller e1 0/0, dann muss entsprechend auch serial 0/0:0 konfiguriert werden...

Nee, das kann man ausschließen. Eine Brücke zwischen den VLANs kann er auf keinen Fall werden, da er ja keine Informationen im 802.1q-Tag ändert bzw. ändern kann und so auch keine Frames zwischen einzelnen VLANs vermitteln wird. Ebensowenig wird er ein 802.1q-Tag aus einem Frame entfernen. Insofern ist das kein Problem. Gutes Netzwerkdesign ist das allerdings trotzdem nicht, auch wenn's funktioniert ;)

Evtl. hilft auch ein "debug snmp requests" oder "debug snmp sessions" bzw. ein "debug snmp packets". Damit kannst du zumindest schonmal sicherstellen, dass auf dem Switch die SNMP-Requests ankommen und Informationen darüber, wieso der Switch vielleicht den Zugriff verweigert.

v4 ?? Dachte imme SNMP geht bis Version 3 Das v4, was du meinst, bezieht sich auf die Adresse 10.0.1.200::::::, also IPv4. SNMP-Version, die hier verwendet ist, ist v1. Dem Logfile nach scheint der Zugriff zwar generell möglich zu sein (wenn man dem "error status" glauben kann), allerdings aber nicht auf die system-OID (1.3.6.1.2.1.1). Spontan wüsst ich jetzt auch nicht direkt, wieso... dieser Bereich sollte mit ner RO-Community auf jeden Fall zugreifbar sein. Bei der Switch-Konfiguration kann man eigentlich auch nicht viel verkehrt machen - auf unseren 2950ern sieht die folgendermassen aus (natürlich mit anderen Community-Strings) ;) snmp-server community public RO snmp-server community private RW snmp-server location at_home snmp-server contact my_email@provider.tld snmp-server host 1.2.3.4 public Hast du mal spaßeshalber probiert, mit ner RW-Community zuzugreifen? Hatte da mal ein ähnlich eigenartiges Problem mit nem ProCurve-Switch...

Deine Konfiguration war schon richtig, bis auf die zweite Zeile. Dass der Host 192.168.2.6 beim Zugriff auf das Internet die IP-Adresse 21.7.14.6 verwendet, ist damit implizit gegeben, da der statische xlate-Eintrag ja besteht, also kein dynamisches NAT durchgeführt wird. Das hier sollte reichen, um den Host 192.168.2.6 von außen erreichbar zu machen: ! ! Die Adresse 192.168.2.6 auf die Adresse 21.7.14.6 mappen static (dmz,outside) 21.7.14.6 192.168.2.6 netmask 255.255.255.255 ! ! Traffic von überall zur globalen Adresse 21.7.14.6 erlauben access-list acl_outside permit ip any host 21.7.14.6 ! ! Accessliste an Interface outside binden access-group acl_outside in interface outside ! Gruß, Martin

Wenn die Endpunktadresse nicht bekannt ist, kannst du dafür 0.0.0.0 mit der Maske 0.0.0.0 verwenden, wie es auch für die Remote-VPN-Konfiguration gemacht wird: crypto isakmp key 123cisco address 0.0.0.0 0.0.0.0 Allerdings schreibt Cisco dazu: (Quelle: Cisco IOS Security Configuration Guide, Release 12.4 - Configuring Internet Key Exchange for IPSec VPNs [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems) Eine Alternative dazu wäre, RSA-Keys zu verwenden: Cisco IOS Security Configuration Guide, Release 12.4 - Configuring Internet Key Exchange for IPSec VPNs [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems

Ist eventuell im Log der Clients was zu finden, was auf einen Fehler beim Registrieren ihres Namens im DNS hindeutet?

Das Gerät ist offensichtlich "dumm" genug, die Frames nicht zu verwerfen. * Ist ein Ethernet-Gerät nicht 802.1q-fähig, so muss es zwangsläufig den Tag Protocol Identifier (TPID) als Längenfeld interpretieren. Dort findet sich ein Wert von 8100h. Dieser Wert ist allerdings keine gültige Ethernet II-Type ID. Scheinbar stört das aber den Switch nicht * Die Länge des Frame überschreitet unter Umständen die max. zulässige Framelänge im Ethernet von 1518, da die max. Framelänge für getaggte Frames 1522 beträgt. Offensichtlich interessiert sich der Switch dafür auch nicht und kann mit den 4 Byte größeren Frames noch umgehen.

Hm, hab irgendwie Mist gebaut beim Einfügen des Links vorhin... hab meinen Beitrag entsprechend ergänzt. Der Vorteil liegt darin, dass Antwortverkehr dynamisch erlaubt werden kann und z.B. nicht allgemein HTTP oder tcp established erlaubt werden muss.

Ist denn im Logging des Switches irgendwas zu sehn, z.B. eine SNMP security access violation oder ähhnliches? Hast du's erstmal ohne die ACL versucht zum Testen? Prinzipiell unterscheidet sich die SNMP-Konfiguration auf einem Switch nicht von der eines Routers (ähnliche IOS-Version vorausgesetzt).

Noch ein bisschen sicherer bekommst du's, wenn du session filtering mit reflexiven Accesslisten verwendest: Cisco Systems - Configuring IP Access Lists Das ist aber vorsichtig zu verwenden - je nach Routermodell geht das ganz schön auf die CPU.

Kannst du das an irgendwas konkretem festmachen oder ist das nur ne Vermutung? Ich kann mir nicht vorstellen, dass man überhaupt keine Punkte bekommt, wenn man am Schluß die Konfiguration nicht sichert. Desweiteren glaube ich auch nicht, dass für eine Simulation 150 Punkte angesetzt sind. Das würde bei den meisten Prüfungen dann ja mehr als die Hälfte der Gesamtpunkte ausmachen...

Standardmässig ist spanning-tree aktiv, wenn es nicht explizit deaktiviert wurde. Evtl. kannst du mal ein "show running | include spanning" posten.

Kannst du ein bisschen genauer beschreiben, was bei dir nicht funktioniert? Funktioniert gar kein Zugriff, oder nur nicht auf bestimmte OIDs? Gibt es Fehlermeldungen? Wie sieht die Konfiguration dazu aus?

Das "z" im Namen des Images steht dafür, dass es ZIP-compressed ist (siehe IOS Naming Scheme). Spontane Reboots können sowohl durch Hard- als auch durch Softwarefehler hervorgerufen werden.

Hm, dann fällt mir als Möglichkeit eigentlich nur eine userbasierte Authentifizierung ein... z.B. mit HTTP Authentication.. oder aber die User, die zugreifen dürfen, bauen eine VPN-Verbindung zur PIX auf. Ist nur die Frage, ob bei letzterem die Performance noch ausreichend ist.

Ich kann das auf unserer ASA hier nachvollziehen. Sobald ich ein eingebe, ist der Port 80 von außen offen, unabhängig von der Accessliste. Allerdings reagiert auf dem Port dann auch nichts... Gruß, Martin