Konfiguration der ASR1000-Verschlüsselung über OTV Unicast
Inhalt
Einleitung
In diesem Dokument werden die grundlegenden Konfigurationen beschrieben, die für die Aktivierung von Overlay Transport Virtualization (OTV) mit IPSec-Verschlüsselung verwendet werden. Für die Verschlüsselung über OTV sind keine zusätzlichen Konfigurationen vom OTV-Ende erforderlich. Sie müssen nur verstehen, wie OTV und IPSEC nebeneinander bestehen.
Um Verschlüsselung über OTV hinzuzufügen, müssen Sie einen ESP-Header (Encapsulating Security Payload) über der OTV-PDU hinzufügen. Für die Verschlüsselung der ASR1000 Edge-Geräte (ED) gibt es zwei Möglichkeiten: (i) IPSec (ii) GETVPN
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- ASR1000 Router für Edge-Geräte (ED)
- Core (ISP-Cloud)
- Catalyst 2960 Switches als Access Switch an beiden Standorten
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Es wird davon ausgegangen, dass die Benutzer die grundlegenden Funktionen und Konfigurationen von OTV kennen.
Sie können den folgenden Dokumenten ebenfalls folgen:
Konfigurieren
Netzwerkdiagramm
Konfigurationen
Standort A: ED-Konfigurationen:
Site_A_1#show run |
Site_A_2#show run |
Standort B: ED-Konfigurationen:
Site_B_1#sh run |
Site_B_2#sh run |
Überprüfung
Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.
- Überprüfen Sie, ob die MAC-Adresse des internen VLAN-Hosts (in diesem Fall die SVI auf den 2960 Catalyst Switches) aus den OTV-Routing-Tabellen ermittelt wurde.
- Überprüfen Sie, ob die Verschlüsselungs-Encaps und Decaps für den Overlay (OTV-Verkehr)-Verkehr durchgeführt werden.
Sobald das OTV nach der Konfiguration der Crypto Map auf der Join-Schnittstelle aktiviert wurde, überprüfen Sie den aktiven Forwarder für die lokalen VLANs (in diesem Fall VLAN 100 und 101). Dies zeigt, dass Site_A_1 und Site_B_2 die aktiven Weiterleitungen für die geraden VLANs sind, da Sie die Datenverkehrsverschlüsselung für Pings testen, die von VLAN 100 an Standort A zu VLAN 100 an Standort B initiiert wurden:
Site_A_1#show otv vlan
Key: SI - Service Instance, NA - Non AED, NFC - Not Forward Capable.
Overlay 99 VLAN Configuration Information
Inst VLAN BD Auth ED State Site If(s)
0 100 100 *Site_A_1 active Gi0/0/0:SI100
0 101 101 Site_A_2 inactive(NA) Gi0/0/0:SI101
0 200 200 *Site_A_1 active Gi0/0/0:SI200
0 201 201 Site_A_2 inactive(NA) Gi0/0/0:SI201
Total VLAN(s): 4
Site_B_2#show otv vlan
Key: SI - Service Instance, NA - Non AED, NFC - Not Forward Capable.
Overlay 99 VLAN Configuration Information
Inst VLAN BD Auth ED State Site If(s)
0 100 100 *Site_B_2 active Gi2/2/1:SI100
0 101 101 Site_B_1 inactive(NA) Gi2/2/1:SI101
0 200 200 *Site_B_2 active Gi2/2/1:SI200
0 201 201 Site_B_1 inactive(NA) Gi2/2/1:SI201
Total VLAN(s): 4
Um zu überprüfen, ob die Pakete tatsächlich in einer der beiden EDs gekapselt und entkapselt werden, sollten Sie überprüfen, ob die IPSec-Sitzung aktiv ist und die Zählerwerte in den Crypto-Sitzungen, um zu bestätigen, dass die Pakete tatsächlich verschlüsselt und entschlüsselt werden. Um zu überprüfen, ob die IPSec-Sitzung aktiv ist, da sie nur dann aktiv wird, wenn Datenverkehr durchfließt, überprüfen Sie die Ausgabe von show crypto isakmp sa. Hier werden nur die Ausgänge für die aktiven Forwarder überprüft. Dies sollte jedoch den aktiven Status auf allen EDs anzeigen, damit die OTV over Encryption funktioniert.
Site_A_1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.0.0.1 30.0.0.1 QM_IDLE 1008 ACTIVE
10.0.0.1 40.0.0.1 QM_IDLE 1007 ACTIVE
Site_B_2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
20.0.0.1 40.0.0.1 QM_IDLE 1007 ACTIVE
10.0.0.1 40.0.0.1 QM_IDLE 1006 ACTIVE
Um nun zu bestätigen, ob die Pakete verschlüsselt und entschlüsselt werden, müssen Sie zunächst wissen, was Sie in den Ausgaben von show crypto session detail erwarten. Wenn Sie also das ICMP-Echo-Paket vom Switch Sw_A in Richtung Sw_B initiieren, wird Folgendes erwartet:
- Während das ICMP-Echo aus der ED "Site_A_1", der aktiven Weiterleitung für das VLAN 100, austritt, muss es die OTV-Nutzlast (ICMP-Echo + MPLS + GRE) kapseln.
- Sobald das ICMP-Echo die Site_B_2 ED erreicht, die den aktiven Forwarder für VLAN 100 darstellt, müsste die OTV-Nutzlast entkapselt werden (ICMP-Echo + MPLS + GRE).
- Nun müsste die Site_B_2 ED, sobald sie die ICMP-Echo-Antwort von Sw_B erhält, die OTV-Nutzlast (ICMP-Echo + MPLS + GRE) erneut kapseln.
- Und sobald die ICMP-Echo-Antwort die Site_A_1 ED erreicht, müsste ich die OTV-Nutzlast erneut entkapseln (ICMP-Echo + MPLS + GRE)
Nach den erfolgreichen Pings von Sw_A nach Sw_B ist ein Inkrement von 5 Zählern im Abschnitt "enc" und "dec" der Ausgabe von Kryptositzungsdetails auf beiden aktiven Weiterleitungs-EDs zu erwarten.
Überprüfen Sie das Gleiche in den Notaufnahmen:
Site_A_1(config-if)#do show crypto session detail | section enc
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4608000/3345
Outbound: #pkts enc'ed 10 drop 0 life (KB/Sec) 4607998/3291 <<<< 10 counter before ping
Site_A_1(config-if)#do show crypto session detail | section dec
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/3343
Inbound: #pkts dec'ed 18 drop 0 life (KB/Sec) 4607997/3289 <<<< 18 counter before ping
Site_B_2(config-if)#do show crypto session detail | section enc
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
Outbound: #pkts enc'ed 18 drop 0 life (KB/Sec) 4607997/3295 <<<< 18 counter before ping
Outbound: #pkts enc'ed 9 drop 0 life (KB/Sec) 4607999/3295
Site_B_2(config-if)#do show crypto session detail | section dec
Inbound: #pkts dec'ed 10 drop 0 life (KB/Sec) 4607998/3293 <<<< 10 counter before ping
Inbound: #pkts dec'ed 1 drop 0 life (KB/Sec) 4607999/3293
Sw_A(config)#do ping 192.168.10.1 source vlan 100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/10 ms
Sw_A(config)#
Site_A_1(config-if)#do show crypto session detail | section enc
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4608000/3339
Outbound: #pkts enc'ed 15 drop 0 life (KB/Sec) 4607997/3284 <<<< 15 counter after ping (After ICMP Echo)
Site_A_1(config-if)#do show crypto session detail | section dec
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/3338
Inbound: #pkts dec'ed 23 drop 0 life (KB/Sec) 4607997/3283 <<<< 23 counter after ping (After ICMP Echo Reply)
Site_B_2(config-if)#do show crypto session detail | section enc
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
Outbound: #pkts enc'ed 23 drop 0 life (KB/Sec) 4607997/3282 <<<< 23 counter after ping (After ICMP Echo Reply)
Outbound: #pkts enc'ed 9 drop 0 life (KB/Sec) 4607999/3282
Site_B_2(config-if)#do show crypto session detail | section dec
Inbound: #pkts dec'ed 15 drop 0 life (KB/Sec) 4607997/3281 <<<< 15 counter after ping (After ICMP Echo)
Inbound: #pkts dec'ed 1 drop 0 life (KB/Sec) 4607999/3281
Dieser Konfigurationsleitfaden enthält die erforderlichen Konfigurationsdetails für die Verwendung von IPSec für die Unicast Core Dual-Homed-Konfiguration.
Fehlerbehebung
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Feedback