DMVPN funzt nicht richtig

[rob_67 10]

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

[Wordo 11]

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?

[rob_67 10]

Hi, könnte vielleicht sein, habe aber nur nach den Updates geschaut... Werde nochmal genauer debuggen, vielleicht finde ich da noch etwas...

 

 

Gruss

 

rob

[Wordo 11]

Oder einfach mal mit statischen Routen testen ..

[rob_67 10]

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

[Wordo 11]

Hast du bei der 876 auch tunnel source Async1? Die Clientzertifikate unterscheiden sich im CN?

[rob_67 10]

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

[Wordo 11]

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.

[rob_67 10]

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?

[Wordo 11]

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.

[rob_67 10]

...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?

[Wordo 11]

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?

[rob_67 10]

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...

[Wordo 11]

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?).

[Wordo 11]

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.