rob_67 10 Posted November 13, 2007 Report Share Posted November 13, 2007 Hallo, habe zwei 7500er Router, von denen einer VPN Server spielt und einen 876er Router. Auf dem VPN Server habe ich Tunnelinterfaces mit Zertifikaten á la interface Tunnel0 ip address 10.10.10.1 255.255.255.252 no ip redirects ip mtu 1400 ip nhrp authentication mysecret ip nhrp map multicast dynamic ip nhrp network-id 42 ip tcp adjust-mss 1360 no ip split-horizon eigrp 999 tunnel source Async1 tunnel mode gre multipoint tunnel key 42 tunnel protection ipsec profile dmvpn mit verschiedenen IP Adressen pro Tunnelinterface und Gegenstelle. Auf allen Routern existieren Zertifikate. Auf den Einwahlrouter sieht es folgendermaßen aus: interface Tunnel0 ip address 10.10.10.2 255.255.255.252 ip nhrp authentication mysecret ip nhrp map 10.10.10.1 172.26.7.2 ip nhrp map multicast 172.26.7.2 ip nhrp network-id 42 ip nhrp nhs 10.10.10.1 ip tcp adjust-mss 1360 no ip split-horizon eigrp 999 tunnel source Async1 tunnel destination 172.26.7.2 tunnel key 42 tunnel protection ipsec profile dmvpn Die VPNs funktinieren, leider nicht gleichzeitig. Sobald beide 7500 er Router connected sind, fliegt der 876 er Tunnel weg (IKE Phase 2 completed, Router zeigt auch VPN an, aber es funzt nicht). An Fehlermeldungen kommt ciscountypisch auch nichts gescheites... Beide Router nutzen auch das gleiche physikalische Interface aber unterschiedliche Tunnelinterfaces auf dem VPN Server und sind in verschiedenen DMVPNs (versch. Tunnelkeys und Authentication). Kurzzeitig kann ich beide Gegenstellen anpingen, bis der 876er weg ist. Hat jemand eine Idee? Gruss Rob Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Also wenn die VPNs stehen und die am Anfang kurz pingen kannst deutet das doch ganz stark auf irgendeine Fehlkonfiguration im EIGRP hin. Da schon mal gedebuggt? Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 Hi, könnte vielleicht sein, habe aber nur nach den Updates geschaut... Werde nochmal genauer debuggen, vielleicht finde ich da noch etwas... Gruss rob Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Oder einfach mal mit statischen Routen testen .. Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 hi, es ist doch nicht das eigrp, aber das Tunnelinterface fliegt wieder weg, aber nur das zum 876 (SA has invalid SPI)... Das Tunnelinterface geht up down...:confused: Gruss rob Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Hast du bei der 876 auch tunnel source Async1? Die Clientzertifikate unterscheiden sich im CN? Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 Hi, die 876 hat als source die IP vom VLAN1, alle router haben die gleiche CN (Problem?). Habe jetzt crypto isakmp invalid-spi-recovery angeschaltet, der Tunnel bleibt oben?! Gruss rob Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Mit Zertifikaten authentifzierst du ja Devices, gleiches Zertifikat (CN), bedeutet gleiche Maschine. Es muesste also eine Funktion a la OpenVPN (duplicate-cn) aktiv sein. Ausm Kopf weiss ich nicht obs sowas fuer IOS gibt. Den Befehl kenne ich leider nicht, anhand der Kurzdoku vom Command Lookup Tool verstehe ich das so, dass, wenn ein Wert in Phase I den Aufbau der SA verhindert, dieser nicht beachtet werden soll (ich kann hier auch totalen Schwachsinn verzapfen), was wiederrum zur Folge haette, dass man sich mit allen selbst ausgestellten Zertifikaten authorisieren koennte. Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 sagen wir mal so, unter cn sehe ich in den Zertifikaten den CA Server und unter subject sehe ich die Router, die sich natürlich schon unterscheiden bzw. beim CA Certificate sehe ich unter CN den CA Server selbst. An den Zertifikaten kann ich auch nicht rumdrehen, da die vom CA Server erstellt werden... Einzeln sind die ja auch Ok... Hier was zu dem feature: When an invalid security parameter index error (shown as "Invalid SPI") occurs in IP Security (IPSec) packet processing, the Invalid Security Parameter Index Recovery feature allows for an Internet Key Exchange (IKE) security association (SA) to be established. The "IKE" module sends notification of the "Invalid SPI" error to the originating IPSec peer so that Security Association Databases (SADBs) can be resynchronized and successful packet processing can be resumed. Ist vor allem dafür gedacht, wenn eine Kiste bootet, daß die Gegenseite das auch mitbekommt und nicht alle Pakete mit invalid SPI verwirft. Meint aber sicher nicht, daß jetzt am Zertifikat vorbei gehandelt wird... Die Frage ist, warum tritt das auf... Ist es ein Bug oder ist es ein feature? Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Und jetzt gehen alle 3 zusammen? :) Oder meckert jetzt wieder die Grosse rum? Nicht das der DMVPN Server die Verbindung zum anderen wieder kappt weil er wieder resynchronized. Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 ...es gingen alle drei, aber nur bis zur security lifetime, jetzt ist der 876 zweimal hintereinander gecrasht... 12.4.15T1 Enterprise... vielleicht probier ich es in zwei jahren nochmal, wenn die iossen besser sind?! warum ist der 876 eigentlich immer der Verlierer? Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Hm, vielleicht kann man das irgendwie eingrenzen? Z.B. mal keine Zertifikate verwenden und auf EIGRP verzichten? Der Crash kommt auch nicht weil du crypto komplett debuggst und der Speicher ueberlaeuft? Quote Link to comment
rob_67 10 Posted November 13, 2007 Author Report Share Posted November 13, 2007 ja, werde ich nochmal probieren... auf dem 876 lief fast kein debug, nur auf den großen kisten, die sind jetzt auch im dezember eol... eine ganz heisse version war auch 12.4.11 T4 vom 876, die war nur am crashen... Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Ich gugg mir grad die Open Caveats an: Cross-Platform Release Notes for Cisco IOS Release 12.4 T, Part 5: Caveats [Cisco IOS Software Releases 12.4 T] - Cisco Systems QoS hast du da nich drauf konfiguriert? Wennst magst kann auch die komplette Konfig der 876 preisgeben (ueber PN?). Quote Link to comment
Wordo 11 Posted November 13, 2007 Report Share Posted November 13, 2007 Und das hier hab ich noch in den Mainline Caveats gefunden: CSCsh84102 Symptoms: The following symptoms may occur: –Some DMVPN spokes become unreachable and a loop appears in a traceroute. –When you enter the show adjacency details command on the hub, the output shows that the adjacency rewrite information for a problematic spoke is the same as for another spoke. –There is an inconsistency between the NHRP cache and the adjacency for the problematic spoke. Conditions: These symptoms are observed in a DMVPN configuration when the hub has CEF enabled. Workaround: Disable CEF on the hub. Vielleicht mal auch 12.4.17 Mainline draufbuegeln, nur so zum testen. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.