#9370

was ist so schlimm an Password Recovery? Das Thema ist ausführlich bei Cisco dokumentiert und kann nur durchgeführt werden, wenn eine Verbindung über die serielle Konsole besteht. Ich verstehe die Aufregung hier nicht. @Neopolis: suche bei Cisco mal unter Password Recovery /#9370

Mit den Infos ist es extrem schwierig etwas genaues zu sagen. Ein "show ip route 213.164.131.98" am Router A wäre hilfreich, aber dann würde auch die Config und weitere show commands auf den Routern notendig sein. /#9370

einfach das "sysopt connection permit-ipsec" rausgeben und den Verkehr per ACL am Interface steuern. In der 6.x musst du dann möglicherweise ESP und ISAKMP in die ACL mitaufnehmen. Da bin ich mir aber nicht ganz sicher. /#9370

das "no logging event..." bezieht sich auf syslogs. Für snmp musst du die richtigen traps deaktivieren: Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, 12.2(31)SGA - Configuring SNMP [Cisco Catalyst 4500 Series Switches] - Cisco Systems /#9370

k.a. - ohne Routing Tabellen kann man jetzt nur spekulieren... /#9370

hatte Router A eine Route auf 213.164.131.98? /#9370

tut mir leid. 2x richtig. /#9370

es geht aber darum, dass Y zurückfindet und nicht C (der auch, aber bei dem Problem geht es vorrangig um Y). Hast du Routing Tabellenauszüge von den betroffenen Routern und von den Y Endgeräten? Ist die Y IP Adresse am C erreichbar? /#9370

wie schaut die Retourroute aus? Hat Y eine Route nach A und B? Wenn der Router ein GW of last resort hat, dann schickt er es auch dorthin... /#9370

ACE == Access Control Entry == eine Zeile in der ACL /#9370

Ich habe ein Präso gesehen, in der auch von Switchübergreifenden Channels die Rede ist... Das müsste man aber sicher probieren. /#9370

bei den "herkömmlichen" Cisco Switches gibt es eine Cluster Möglichkeit. Im Configuration Guide für den 3030 Switch ist diese Möglichkeit auch aufgeführt, nur fehlt dieser Switch in der Übersichtstabelle für die unterstützten Geräte. Am besten mal anschauen und probieren: Config Guide: Cisco Catalyst Blade Switch 3030 Software Configuration Guide, Rel. 12.2(37)SE - Clustering Switches [Cisco Catalyst Blade Switch 3000 Series] - Cisco Systems Command Reference: http://www.cisco.com/en/US/partner/products/ps6748/products_command_reference_chapter09186a008081639d.html In der 3030 Command Reference sind aber leider keine cluster Commands zu finden. Siehe auch Doku für 3560: http://www.cisco.com/en/US/partner/products/hw/switches/ps5528/products_command_reference_chapter09186a0080818708.html /#9370

das kann nicht nur sein - das ist so.

jetzt habe ich mir das Problem noch einmal genau durchgelesen (nach dem 3500XL Hinweis von czappb), da ich zuerst meinte, es handelt sich um einen 3560 Switch - genauer lesen müsste man. 1) Ein XL Switch kann immer nur ein L3 Interface aktiv haben. Deshalb sind die anderen auch auf down. 2) Ein XL Switch ist ein reiner L2 Switch! Der wird nie Pakete zwischen den VLANs routen -> den helper-address command dürfte es gar nicht geben. 3) Du könntest einen Trunk zum Server einrichten, auf dem alles VLANs transportiert werden. /#9370

du meinst folgendes: du bekommst eine IP Adresse dynamisch zugewiesen und möchtest hinter dem Router einen Server betreiben, der über Port forwarding erreichbar ist. Als erstes das anschauen: Configuring Network Address Translation: Getting Started [iP Addressing Services] - Cisco Systems Dann mit diesem Befehl probieren - habe ich selber noch nicht gemacht, sollte aber klappen: ip nat inside source static tcp local-ip local-port interface global-port siehe auch: NAT Commands /#9370

Wenn ich dich richtig verstanden habe meinst du folgendes: Sample Config: access-list nonat permit ip host1 host2 access-list policy permit ip 10.0.0.0 255.0.0.0 192.168.2.0 255.255.255.0 nat (i) 0 access-list nonat access-group policy in interface inside Du willst nun wissen, ob die ACLs in dieser Reihenfolge gehören, oder ob auch zuerst die policy ACL und dann die nonat ACL konfiguriert werden kann? Der PIX ist es ****egal in welcher Reihenfolge die ACLs konfiguriert sind. Es kommt nur auf die Reihenfolge der ACEs an. /#9370

@adam^sad: Setup: 192.168.1.1 Netz ---> VPNC - NAT auf 192.168.2.1 ----> Firewall -----> 10.1.1.1 Der Client mit der IP Adresse 10.1.1.1 will auf den Client mit der IP Adresse 192.168.1.1 zugreifen. Da die 192.168.1.1 hinter einem NAT Device liegt und nach außen mit 192.168.2.1 erscheint, muss der 10.1.1.1 Client auf 192.168.2.1 zugreifen. Die 192.16.1.1 Adresse bekommt der Client gar nicht mit, da sie ja vom VPNC umgesetzt wird - das ist der Sinn vom NAT. ------------- @hegl: ja, die PIX macht zuerst NAT und dann IPSec. Deshalb musst du auch immer das NAT 0 bei IPSec konfigurieren. /#9370

poste mal den Sniffer Trace... /#9370

da ist mir leider nichts bekannt. Vielleicht gibt es eine SNMP MIB? Du könntest das aber anders lösen: Eine Hostroute auf ein unterschiedliches Testgerät jeweils über Leitung 1 und 2 legen. Wenn du Testgerät 1 pingst, dann muss Leitung 1 aktiviert werden und wenn du Testgerät 2 pingst, dann geht das über Leitung 2. Somit kannst du mit einem herkömmlichen ping sagen, ob die Leitung funktioniert. /#9370

Wenn du NAT machst, dann willst du nicht mit deiner richtigen IP Adresse erscheinen, sondern mit der genateten. /#9370

"isdn test call interface" im privileged EXEC mode. /#9370

du musst Zugriff auf die IP Adresse erlauben, die die Gegenstelle sieht. Wenn du lokal 10.x hast und nach außen mit 192.168.x erscheinst, dann muss Zugriff auf die 192.168.x erfolgen und somit an der Firewall erlaubt sein. /#9370

du könntest zwei GRE Tunnel konfigurieren und schauen, dass der erste über Leitung 1 geroutet wird und der zweite über Leitung zwei. Dahinter machst du dann auch Loadsharing mit Routing. /#9370

Hallo nochmal, ich habe noch ein wenig gesucht und folgende Links gefunden: http://www.educaid.ch/schuelerdaten/Skripte/Telematik/telematik_osi_modell.pdf Cisco - TCP/IP In beiden Quellen werden die IP Routingprotokolle OSPF, IGRP, EIGRP als Layer-3 Protokolle angegeben. Die Frage wird demnach falsch aufgelöst. /#9370

in dem Dokument steht ES-IS als Routing Protokoll, in einem anderen Dokument, auch bei Cisco, steht was anderes: ES-IS is more of a discovery protocol than a routing protocol. (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/osi_rout.htm). Jetzt lässt sich natürlich darüber streiten, was ein Routing Protokoll ist. Ich habe aber zufällig einen Blick in das Lösungsheft von dem Test gemacht und da ist ES-IS als richtige Antwort drinnen. /#9370