In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird erläutert, wie der LISP IGP Assist Extended Subnet Mode (ESM) mit einem Nexus 7000 bereitgestellt wird.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Common Configuration on both DC1-Agg1 and DC1-Agg2 feature lisp vrf context tenant-1 # This example is based on SVI 144 in VRF- tenant-1 and SVI 145 in VRF- tenant-2 ip lisp etr # This is needed to initialize LISP and only etr is needed on a IGP assist mode Environment lisp instance-id 2 # Instance-ID should be unique per VRF ip lisp locator-vrf default # Locator Is specified in Default VRF lisp dynamic-eid VLAN144 # Dynamic EID definition for Vlan 144 database-mapping 172.16.144.0/24 10.10.10.1 priority 50 weight 50 # Database-mapping for 172.16.144.0/24 which is the Vlan 144; IP-> 10.10.10.1 is the Loopback100 IP address(which is the unique IP on DC1-AGG1) database-mapping 172.16.144.0/24 10.10.10.2 priority 50 weight 50 # Database-mapping for 172.16.144.0/24 which is the Vlan 144; IP-> 10.10.10.2 is the Loopback100 IP address(which is the unique IP on DC1-AGG2) map-notify-group 239.254.254.254 # Multicast group that will be used by LISP enabled switches to communicate about new EID learns or periodic EID notification messages no route-export away-dyn-eid # This is a hidden command required to stop advertising any null0 /32 route for a remote host to the IGP lisp dynamic-eid VLAN244 # Dynamic EID definition for Vlan 244 database-mapping 172.16.244.0/24 10.10.10.1 priority 50 weight 50 database-mapping 172.16.244.0/24 10.10.10.2 priority 50 weight 50 map-notify-group 239.254.254.254 no route-export away-dyn-eid vrf context tenant-2 ip lisp etr lisp instance-id 3 ip lisp locator-vrf default lisp dynamic-eid VLAN145 database-mapping 172.16.145.0/24 10.10.10.1 priority 50 weight 50 database-mapping 172.16.145.0/24 10.10.10.2 priority 50 weight 50 map-notify-group 239.254.254.254 no route-export away-dyn-eid Configuration on DC1-Agg1 interface Vlan144 no shutdown vrf member tenant-1 lisp mobility VLAN144 lisp extended-subnet-mode # SVI needs to be in ESM Mode-Extended subnet mode ip address 172.16.144.250/24 ip pim sparse-mode hsrp 144 preempt priority 254 ip 172.16.144.254 interface Vlan145 no shutdown vrf member tenant-2 lisp mobility VLAN145 lisp extended-subnet-mode ip address 172.16.145.250/24 ip pim sparse-mode hsrp 145 preempt priority 254 ip 172.16.145.254 interface Vlan244 no shutdown vrf member tenant-1 lisp mobility VLAN244 lisp extended-subnet-mode ip address 172.16.244.250/24 hsrp 244 preempt priority 254 ip 172.16.244.254 interface loopback100 ip address 10.10.10.1/32 ip router eigrp 100 ip pim sparse-mode Configuration on DC1-Agg2 interface Vlan144 no shutdown vrf member tenant-1 lisp mobility VLAN144 lisp extended-subnet-mode ip address 172.16.144.251/24 ip pim sparse-mode hsrp 144 ip 172.16.144.254 interface Vlan145 no shutdown vrf member tenant-2 lisp mobility VLAN145 lisp extended-subnet-mode ip address 172.16.145.251/24 ip pim sparse-mode hsrp 145 ip 172.16.145.254 interface Vlan244 no shutdown vrf member tenant-1 lisp mobility VLAN244 lisp extended-subnet-mode no ip redirects ip address 172.16.244.251/24 hsrp 244 ip 172.16.244.254 interface loopback100 ip address 10.10.10.2/32 ip router eigrp 100 ip pim sparse-mode
# Die Datenbankzuordnung muss so bereitgestellt werden, dass auf einer Seite sowohl die IP-Adressen DC1-Agg1 als auch DC1-Agg2 Loopback angegeben werden müssen. Innerhalb von DC2-Agg1 und DC2-Agg2 muss ein eindeutiges Loopback erstellt und in die Datenbank-Zuordnung übernommen werden.
# Wenn in einem IGP-assistiermodus die Konfiguration-> "ip lisp itr-etr" verwendet wird, wird die /32 null0-Hostroute für VLANs aktiviert, die nicht LISP-aktiviert sind. Die richtige Konfiguration ist also "ip lisp etr" für den IGP-Supportmodus.
Common Configuration on both DC2-Agg1 and DC2-Agg2 feature lisp vrf context tenant-1 ip lisp etr lisp instance-id 2 ip lisp locator-vrf default lisp dynamic-eid VLAN144 database-mapping 172.16.144.0/24 10.10.20.1 priority 50 weight 50 # Note that the IP addresses used in DC2 Agg switches are 10.10.20.1 and 10.10.20.2(Which are Loopbacks Configured on DC2-Agg switches) database-mapping 172.16.144.0/24 10.10.20.2 priority 50 weight 50 map-notify-group 239.254.254.254 no route-export away-dyn-eid lisp dynamic-eid VLAN244 database-mapping 172.16.244.0/24 10.10.20.1 priority 50 weight 50 database-mapping 172.16.244.0/24 10.10.20.2 priority 50 weight 50 map-notify-group 239.254.254.254 no route-export away-dyn-eid vrf context tenant-2 ip lisp etr lisp instance-id 3 ip lisp locator-vrf default lisp dynamic-eid VLAN145 database-mapping 172.16.145.0/24 10.10.20.1 priority 50 weight 50 database-mapping 172.16.145.0/24 10.10.20.2 priority 50 weight 50 map-notify-group 239.254.254.254 no route-export away-dyn-eid
Configuration on DC2-Agg1
interface Vlan144 no shutdown vrf member tenant-1 lisp mobility VLAN144 lisp extended-subnet-mode ip address 172.16.144.252/24 ip pim sparse-mode hsrp 144 preempt priority 254 ip 172.16.144.254 interface Vlan145 no shutdown vrf member tenant-2 lisp mobility VLAN145 lisp extended-subnet-mode ip address 172.16.145.252/24 ip pim sparse-mode hsrp 145 preempt priority 254 ip 172.16.145.254 interface Vlan244 no shutdown vrf member tenant-1 lisp mobility VLAN244 lisp extended-subnet-mode ip redirects ip address 172.16.244.252/24 hsrp 244 preempt priority 254 ip 172.16.244.254 interface loopback100 ip address 10.10.20.1/32 ip router eigrp 100 ip pim sparse-mode Configuration on DC2-Agg2
interface Vlan144 no shutdown vrf member tenant-1 lisp mobility VLAN144 lisp extended-subnet-mode ip address 172.16.144.253/24 ip pim sparse-mode hsrp 144 ip 172.16.144.254 interface Vlan145 no shutdown vrf member tenant-2 lisp mobility VLAN145 lisp extended-subnet-mode ip address 172.16.145.253/24 ip pim sparse-mode hsrp 145 ip 172.16.145.254 interface Vlan244 no shutdown vrf member tenant-1 lisp mobility VLAN244 lisp extended-subnet-mode no ip redirects ip address 172.16.244.253/24 hsrp 244 preempt ip 172.16.244.254 interface loopback100 ip address 10.10.20.2/32 ip router eigrp 100 ip pim sparse-mode
# Der Unterschied zwischen DC1- und DC2-Agg-LISP-Konfigurationen sind die in der "Datenbankzuordnung" definierten Loopbacks. In der DC1-Konfiguration wird dies mit den Loopbacks von DC1-Agg1 und DC1-Agg2 definiert, und für DC2 wird die Datenbankzuordnung mit den Loopbacks definiert, die sich in DC2-Agg1 und DC2-Agg2 befinden.
# Die übrigen Konfigurationen für IGP/Routenzuordnungen/Präfixlisten, die unten gezeigt werden, sind ähnlich (die für die Schnittstellen zugewiesenen IP-Adressen sind tatsächlich unterschiedlich).
router eigrp 100 address-family ipv4 unicast vrf tenant-1 distance 90 245 # External EIGRP Routes have to have an AD which is higher than the default LISP AD(which is 240); Reason being, if the redistributed route from dc1-agg1 comes back to dc1-agg2 via eigrp, default EIGRP External is 170 which will override LISP route causing problems redistribute lisp route-map lisp-to-eigrp # This command is to redistribute LISP /32 routes only to the IGP(EIGRP In this example) redistribute direct route-map direct # This is needed so that the direct routes(/24 SVI routes in LISP) are redistributed to the IGP; This will be needed if there is some device that is trying to communicate to a silent host in the LISP enabled Vlan vrf tenant-2 distance 90 245 redistribute lisp route-map lisp-to-eigrp redistribute direct route-map direct
# LISP-fähige AGG-VDCs bilden auch die IGP-Nachbarschaft zur Core-Seite.
# In diesem Beispiel wurden Subschnittstellen, die Teil der einzelnen Tenant-VRFs waren, verwendet, um die Nachbarschaft zum Core zu bilden, wie unten gezeigt.
interface Ethernet3/6.111 encapsulation dot1q 111 vrf member tenant-1 ip address 192.168.98.1/30 ip router eigrp 100 no shutdown interface Ethernet3/6.212 encapsulation dot1q 212 vrf member tenant-2 ip address 192.168.198.1/30 ip router eigrp 100 no shutdown
ip prefix-list lisp-to-eigrp seq 5 permit 0.0.0.0/0 ge 32 # This is the prefix list that is matching any /32 routes which are to be redistributed from LISP To IGP route-map direct permit 10 # This is for the Direct routes route-map lisp-to-eigrp deny 10 # This is to prevent any null0 routes from being redistributed to IGP from LISP match interface Null0 route-map lisp-to-eigrp permit 20 # This is to allow redistribution of /32 host routes match ip address prefix-list lisp-to-eigrp
# Alle oben genannten Konfigurationen sind für alle AGG-Switches (DC1 und DC2) erforderlich. Berücksichtigen Sie, dass eindeutige IP-Adressen für die SVIs, Loopbacks und HSRP VIP für alle SVIs identisch sind.
HSRP-Filterung
# Bei IGP-unterstützten Bereitstellungen muss die FHRP-Isolierung vorhanden sein, wenn sie mittels OTV oder einem anderen Mechanismus verlängert wird.
# Dies geschieht durch Filtern von FHRP Hello-Nachrichten innerhalb des OTV-VDC.
# In diesem Beispiel wird N7k OTV verwendet. Daher wurden die folgenden Konfigurationen angewendet, um die FHRP-Pakete im OTV-VDC zu filtern.
ip access-list ALL_IPs 10 permit ip any any mac access-list ALL_MACs 10 permit any any ip access-list HSRP_IP 10 permit udp any 224.0.0.2/32 eq 1985 20 permit udp any 224.0.0.102/32 eq 1985 mac access-list HSRP_VMAC 10 permit 0000.0c07.ac00 0000.0000.00ff any 20 permit 0000.0c9f.f000 0000.0000.0fff any arp access-list HSRP_VMAC_ARP 10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00 20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000 30 permit ip any mac any vlan access-map HSRP_Localization 10 match mac address HSRP_VMAC match ip address HSRP_IP action drop vlan access-map HSRP_Localization 20 match mac address ALL_MACs match ip address ALL_IPs action forward vlan filter HSRP_Localization vlan-list 144-145 ip arp inspection filter HSRP_VMAC_ARP vlan 144-145 mac-list OTV_HSRP_VMAC_deny seq 10 deny 0000.0c07.ac00 ffff.ffff.ff00 mac-list OTV_HSRP_VMAC_deny seq 11 deny 0000.0c9f.f000 ffff.ffff.f000 mac-list OTV_HSRP_VMAC_deny seq 20 permit 0000.0000.0000 0000.0000.0000 route-map OTV_HSRP_filter permit 10 match mac-list OTV_HSRP_VMAC_deny otv-isis default vpn Overlay0 redistribute filter route-map OTV_HSRP_filter
# FHRP-Filterungskonfigurationen sind NUR für OTV-VDCs erforderlich. Wenn eine ASR OTV-Bereitstellung verwendet wird, sollten die Filtermechanismen entsprechend den Vorgaben des ASR-Konfigurationsleitfadens verwendet und dokumentiert werden.
OTV Suppress ARP
# Deaktivieren der ARP-ND-Cache-Funktion in OTV-VDCs
interface Overlay0 no otv suppress-arp-nd >>>>>
DC1-AGG1# show ip route lisp vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.0/25, ubest/mbest: 1/0 *via Null0, [240/1], 07:22:30, lisp, dyn-eid 172.16.144.128/25, ubest/mbest: 1/0 *via Null0, [240/1], 07:22:30, lisp, dyn-eid
# Wenn LISP auf SVI 144 aktiviert ist, werden zwei Null0-Routen automatisch erstellt. SVI 144 ist ein /24-Subnetz, sodass die erste Null0-Route von 172.16.144.0/25 und die zweite von 172.16.144.128/25 ist, wie oben gezeigt.
# Dies ist geplant und erwartet. Dies geschieht, um sicherzustellen, dass die Pakete von nicht erkannten Hosts eine RPF-Ausnahme auslösen, die dazu führt, dass die Pakete an die CPU abgestraft werden und letztendlich bei der Host Detection (EID) helfen.
# Die Hosterkennung an LISP-fähigen Schnittstellen basiert auf dem Empfang von L3-Datenverkehr von IP-Adressen innerhalb des in der Datenbankzuordnungskonfiguration angegebenen Bereichs.
Um die Erkennung von Hosts zu vereinfachen, beachten Sie, dass bei Aktivierung von LISP auf einer Schnittstelle:
# RPF-Ausnahmen sind auf der Schnittstelle aktiviert, sodass Pakete, die von unbekannten Quellen generiert werden, die Ausnahme auslösen
# Vom LISP ausgehende Null0-Routen werden installiert, um sicherzustellen, dass unbekannte Quellen die RPF-Ausnahme auslösen
Da diese Lösung für die L2-Erweiterung zwischen den beiden Rechenzentren auf OTV beruht, kann die ARP-Signalisierung nicht direkt zur Erkennung von IP-Hosts verwendet werden, da sie in vielen Fällen an alle Switches übertragen wird.
ARP-Signale werden jedoch als Indikator für LISP verwendet, dass ein unerkannter Host vorhanden sein kann. Da sich der Host an einer beliebigen Seite der OTV-Bridge befinden kann, startet der LISP einen Lokalisierungsmechanismus, nachdem er eine neue IP-MAC-Bindung gelernt hat.
Der Lokalisierungsmechanismus funktioniert wie folgt:
# Der Switch erhält eine neue IP-MAC-Bindung (über GARP, RARP oder eine ARP-Anforderung).
# Der Switch, der als aktiver HSRP fungiert, sendet eine Echoanfrage an den Host, die jedoch von der HSRP-VIP-Adresse stammt.
# Der Host antwortet auf die Echoanfrage, aber nach der FHRP-Isolierung in OTV wird die Echoantwort nur auf dem Rechenzentrums-Standort empfangen, auf dem sich der Host befindet.
# Da die Echo-Antwort ein L3-Paket ist, wird der Host von LISP erkannt.
# Wenn ein IP-Paket auf einer LISP-aktivierten SVI empfangen wird, leitet dieser selbst den LISP-Prozess ein, um darüber zu informieren, dass der Endpunkt lokal ist. Es werden keine ICMP ECHO-Anfragen gesendet, um zu bestätigen, ob der Gastgeber lokal ist oder nicht. Daher ist es wichtig zu beachten, dass ein Ping von einem DC2-Host zu DC1-AGG-SVI-IP-Adressen zu einer Beschädigung der Endpunktidentifizierung führt, die ebenfalls zu Ping-Verlusten oder Datenverkehrsengpässen führen kann, da der Host jetzt als lokale EID in DC1 im Gegensatz zu DC2 identifiziert wird. Aus diesem Grund sollten Pings nicht von SVI-IP-Adressen in einer LISP-Umgebung stammen, da dies die Routing-Tabelle beschädigen und zu Blackholing des Datenverkehrs führen kann. Das gleiche Problem tritt auf, wenn die Hosts im LISP-aktivierten VLAN versuchen, einen Ping an die SVI-IP-Adressen zu senden. Das Pingen des VIP sollte in Ordnung sein, da auf beiden Seiten derselbe vorhanden und aktiv ist, und die lokale Seite fängt das Paket ab.
Ein Beispiel für einen Eintrag in der Routing-Tabelle, wenn ein Host in DC1 online ist, ist unten dargestellt.
DC1-AGG1# show ip route 172.16.144.1 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.1/32, ubest/mbest: 1/0, attached *via 172.16.144.1, Vlan144, [240/1], 3d05h, lisp, dyn-eid via 172.16.144.1, Vlan144, [250/0], 3d05h, am DC1-AGG2# sh ip route 172.16.144.1 vr tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.1/32, ubest/mbest: 1/0, attached *via 172.16.144.1, Vlan144, [240/1], 3d05h, lisp, dyn-eid via 172.16.144.1, Vlan144, [250/0], 3d05h, am
# Wie oben gezeigt, gibt es zwei Routen; Ein Prozess nach LISP mit der administrativen Distanz von 240 und ein weiterer Prozess nach AM-> Adjacency Manager (eingetragen durch ARP-Prozess) mit AD von 250.
# Beide Agg Switches in DC1 haben den gleichen Eintrag.
# Außerdem listet LISP den gleichen Eintrag für den Host in der dynamischen EID-Tabelle auf, wie unten gezeigt.
DC1-AGG1# show lisp dynamic-eid detail vrf tenant-1 | in 144.1, nex 1 172.16.144.1, Vlan144, uptime: 3d05h, last activity: 00:14:38 Discovered by: packet reception DC1-AGG2# show lisp dynamic-eid detail vrf tenant-1 | in 144.1, nex 1 172.16.144.1, Vlan144, uptime: 3d05h, last activity: 00:00:37 Discovered by: site-based Map-Notify
# Die Erkennung ist in beiden Fällen unterschiedlich. DC1-AGG1, bei dem es sich um das aktive HSRP handelt, zeichnet den Eintrag mithilfe von "Paketempfang" auf. Dies bedeutet im Wesentlichen, dass ein Paket einging, das dazu führte, dass es als EID hinzugefügt wurde.
# Sobald die Agg1 von einer EID erfahren hat, sendet sie eine Multicast-Nachricht von der IP-> Loopback100-IP-Adresse (definiert in Datenbankzuordnung) an die Gruppe-> 239.254.254.254(konfiguriert oben). Der vPC-Peer-Switch empfängt diese Nachricht und füllt den Eintrag entsprechend aus und betrachtet sie als EILokal D, da die Datenbankzuordnung sowohl die IP-Adressen dc1-agg1 als auch dc1-agg2 enthält. Das gleiche Multicast-Paket würde auch über das OTV an die Remote-Standorte übertragen. Remote-Standorte würden die Datenbankzuordnung jedoch überprüfen, und da dieses Paket von einer IP-Adresse stammt, die sich von der "Datenbankzuordnung" unterscheidet, wird es von den DC2 AGg-Switches nicht als lokale EID angesehen.
# Wenn ein Host von LISP-aktivierter SVI erkannt wird, wird eine ausgelöste "Map-notify"-Nachricht an die Multicast-Gruppe gesendet, die in der entsprechenden dynamischen EID-Konfiguration definiert ist.
# Außer den Meldungen für ausgelöste Zuordnungsbenachrichtigungen gibt es periodische Map-Notification-Meldungen, die vom HSRP Active (or FHRP active) Switch in diesem VLAN gesendet werden.
# Ein PCAP der Karte Benachrichtigung Nachricht ist wie folgt.
# Dies ist der Schlüssel für IGP-Supportmodus. Jede /32-LISP-Route wird an IGP umverteilt. Möglich wird dies durch den Befehl "redistribute LISP", der unter EIGRP angewendet wurde.
# Jede /32-Host-Route wird nach der Neuverteilung als externe EIGRP-Route angesehen. Eine Anpassung der EIGRP-Verwaltungsdistanz wurde vorgenommen, um sie zu erhöhen. Dadurch wird sichergestellt, dass die LISP-Route im Gegensatz zur eingehenden EIGRP-externen Route in URIB verbleibt. z. B. DC1-Agg1 und DC1-Agg2 sind EIGRP-Nachbarn mit DC1-Core. Eine /32-Route wurde mittels Umverteilung von DC1-AGG1 nach DC1-Core eingespeist. Da es sich beim DC1-Core um einen EIGRP-Nachbarn mit DC1-Agg2 handelt, kann die gleiche Route zurück nach DC1-Agg2 gehen und die Chance haben, die LISP-Route (die ein AD von 240 aufweist) zu gewinnen, wenn das EIGRP AD 170 betrug. Um dies zu vermeiden, wurde die externe EIGRP-Route-AD auf 245 geändert.
# Die /32-Route, die von den DC1-Agg-Switches gelernt wurde, wird auf EIGRP umverteilt, und der DC1-Core-Eintrag sieht wie unten aus.
DC1-CORE# sh ip route 172.16.144.1 IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.1/32, ubest/mbest: 2/0 *via 192.168.98.1, Eth3/20.111, [170/51456], 00:00:01, eigrp-100, external *via 192.168.98.5, Eth3/22.112, [170/51456], 18:14:51, eigrp-100, external
# Die Route ist in der Global Routing-Tabelle vorhanden, und auf der Core-Seite ist kein VRF konfiguriert.
# Aufgrund der "Redistribution Direct", die auf AGG-Switches konfiguriert wurde, verfügt der Core auch über eine /24-ECMP-Route für das übergeordnete Subnetz (siehe unten). Dies hilft, Datenverkehr für einen unbeaufsichtigten Host anzuziehen (für den es keine /32-Route gibt).
DC1-CORE# sh ip route 172.16.144.10 # Checking for a non existent Host 172.16.144.10 IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.0/24, ubest/mbest: 2/0 *via 192.168.98.1, Eth3/20.111, [170/51456], 00:02:13, eigrp-100, external *via 192.168.98.5, Eth3/22.112, [170/51456], 18:17:03, eigrp-100, external
# Außerdem wird eine /24 ECMP-Route für die DC1- und DC2-Kerne sichtbar.
Branch1-Router# sh ip route 172.16.144.10 Routing entry for 172.16.144.0/24 Known via "eigrp 100", distance 170, metric 51712, type external Redistributing via eigrp 100 Last update from 192.168.99.2 on GigabitEthernet0/0/1, 00:00:17 ago Routing Descriptor Blocks: 192.168.99.2, from 192.168.99.2, 00:00:17 ago, via GigabitEthernet0/0/1 # 192.168.99.2 is DC2-Core Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2 * 192.168.99.1, from 192.168.99.1, 00:00:17 ago, via GigabitEthernet0/0/1 # 192.168.99.1 is DC1-Core Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2
# Diese Route würde sicherstellen, dass ein Zweigstellen-Host zu einem unbeaufsichtigten Host gelangen kann, der sich an beiden Standorten befindet.
# Wenn DC1-Host1 -> 172.16.144.1 versucht, DC2-Host1-> 172.16.144.2 zu erreichen, handelt es sich hierbei um Intra-VLAN-Datenverkehr zwischen Rechenzentren. DC1-Host 1 sendet eine ARP-Anfrage, die das OTV durchläuft und DC2-Host1 erreicht.
# DC2-Host1 antwortet mit einer ARP-Antwort, die zurück zum DC1-Host1 kommt
# Nachfolgende ICMP-Pakete werden über OTV gesendet
# Wenn DC1-Host1-> 172.16.144.1 versucht, DC2-Host2-> 172.16.244.2 zu erreichen, wird das Paket in DC1 NICHT von VLAN 144 auf 244 geroutet. Stattdessen folgt sie einem gerouteten Pfad von DC1-Agg zum DC1-Core und erreicht dann den DC2-Core. Das endgültige Routing wird von den DC2-Agg-Switches zum Ziel-VLAN-244 durchgeführt.
# Eine Traceroute von DC1-Host1 zu DC2-Host2 ist wie folgt:
DC1-HOST# traceroute 172.16.244.2 vrf vlan144 traceroute to 172.16.244.2 (172.16.244.2), 30 hops max, 40 byte packets 1 172.16.144.250 (172.16.144.250) 1.149 ms 0.841 ms 0.866 ms # DC1-AGG1 2 192.168.98.2 (192.168.98.2) 1.004 ms 0.67 ms 0.669 ms # DC1-CORE 3 192.168.99.2 (192.168.99.2) 0.756 ms 0.727 ms 0.714 ms # DC2-CORE 4 192.168.94.5 (192.168.94.5) 1.041 ms 0.937 ms 192.168.94.1 (192.168.94.1) 1.144 ms # DC2-Agg1/DC2-Agg2 5 172.16.244.2 (172.16.244.2) 2.314 ms * 2.046 ms # DC2-Host2
# Dies entspricht der Kommunikation zwischen VLANs und Rechenzentren zwischen zwei VLANs (vorheriges Beispiel).
# Wenn DC1-host1-> 172.16.144.1 versucht, DC2-Host3-> 172.16.145.2 zu erreichen, handelt es sich hierbei um Datenverkehr zwischen VLAN und Rechenzentrum, der in VLAN 144(VRF-Tenant-1) generiert und für VLAN 145 bestimmt ist. VRF-Tenant-2). Im Gegensatz zu herkömmlichen N7k OTV-Bereitstellungen wird dieser Datenverkehr etwas anders behandelt. Auf DC1-Seite findet kein Inter-VLAN-Routing statt. Dieser Datenverkehr wird geroutet und an den DC1-Core gesendet. Der Core leitet ihn weiter über das IGP zum DC2-Core weiter.
# Um dieses Dokument willen wird das VRF-Auslaufen pro Standort durch den Core Switch durchgeführt. Dabei kann es sich um ein beliebiges Gerät (z. B. eine Firewall) handeln. Hinsichtlich der LISP-Konfiguration gibt es keine Änderungen, wenn Inter-VRF-Leaking vorhanden ist oder nicht.
DC1-AGG1# sh ip route 172.16.145.2 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.145.2/32, ubest/mbest: 1/0 *via 192.168.98.2, Eth3/6.111, [245/51968], 00:00:46, eigrp-100, external
# Eine Traceroute von DC1-Host1 zu DC2-Host3 offenbart das gleiche wie die Routing-Traceroute zwischen VLANs und Layer 3, die durch den Core geroutet wird. Kurz gesagt, der Inter-VLAN-Datenverkehr verwendet kein OTV.
DC1-HOST# traceroute 172.16.145.2 vrf vlan144 traceroute to 172.16.145.2 (172.16.145.2), 30 hops max, 40 byte packets 1 172.16.144.250 (172.16.144.250) 1.049 ms 0.811 ms 0.81 ms # DC1-AGG1 2 192.168.98.2 (192.168.98.2) 0.844 ms 0.692 ms 0.686 ms # DC1-CORE 3 192.168.99.2 (192.168.99.2) 0.814 ms 0.712 ms 0.735 ms # DC2-CORE 4 192.168.194.1 (192.168.194.1) 0.893 ms 0.759 ms 192.168.194.5 (192.168.194.5) 0.89 ms # DC2-Agg1/DC2-Agg2 5 172.16.145.2 (172.16.145.2) 1.288 ms * 1.98 ms # DC2-Host3 DC1-HOST#
# Host in Branch-1-172.17.200.1 versucht, DC2-Silent Host zu erreichen - 172.16.144.119. Da der Host stumm ist, ist im DC2 keine /32-Route vorhanden.
DC2-AGG1# show ip route 172.16.144.119 vr tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.0/25, ubest/mbest: 1/0 *via Null0, [240/1], 20:48:29, lisp, dyn-eid DC2-AGG2# show ip route 172.16.144.119 vr tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.0/25, ubest/mbest: 1/0 *via Null0, [240/1], 20:48:13, lisp, dyn-eid
# Gemäß LISP-Design entspricht die Route 172.16.144.119 der Route 172.16.144.0/25 null0.
# Wenn der Zweigstellen-Router ein Paket mit der Ziel-IP = 172.16.144.119 empfängt, verfügt URIB über eine ECMP/24-Route zu DC1-Core und DC2-Core. Das bedeutet im Wesentlichen, dass das Paket an einen der Core-Switches gesendet wird.
Branch1-Router# sh ip route 172.16.144.119 Routing entry for 172.16.144.0/24 Known via "eigrp 100", distance 170, metric 51712, type external Redistributing via eigrp 100 Last update from 192.168.99.2 on GigabitEthernet0/0/1, 00:08:54 ago Routing Descriptor Blocks: 192.168.99.2, from 192.168.99.2, 00:08:54 ago, via GigabitEthernet0/0/1 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2 * 192.168.99.1, from 192.168.99.1, 00:08:54 ago, via GigabitEthernet0/0/1 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2
Branch1-Router#sh ip cef exact-route 172.17.200.1 172.16.144.119 dest-port 1
172.17.200.1 -> 172.16.144.119 =>IP adj out of GigabitEthernet0/0/1, addr 192.168.99.1
# Das Paket gemäß CEF hasht auf 192.168.99.1(d. h. DC1-Core).
# DC1-Core hat 2 ECMP-Pfade; Eine Richtung Richtung DC1-Agg1 (HSRP Aktiv) und die andere Richtung DC1-Agg2 (HSRP Standby). Aus dem Routing-Hash wird der ausgewählte Pfad DC1-Agg2 sein.
DC1-CORE# sh routing hash 172.17.200.1 172.16.144.119 1 1 Load-share parameters used for software forwarding: load-share mode: address source-destination port source-destination Universal-id seed: 0xfdba3ebe Hash for VRF "default" Hash Type is 1 Hashing to path *192.168.98.5 Eth3/22.112 For route: 172.16.144.0/24, ubest/mbest: 2/0 *via 192.168.98.1, Eth3/20.111, [170/51456], 00:19:57, eigrp-100, external *via 192.168.98.5, Eth3/22.112, [170/51456], 18:34:47, eigrp-100, external
DC1-CORE# sh cdp nei int e3/22 Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge S - Switch, H - Host, I - IGMP, r - Repeater, V - VoIP-Phone, D - Remotely-Managed-Device, s - Supports-STP-Dispute Device-ID Local Intrfce Hldtme Capability Platform Port ID DC1-AGG2(JAF1534CHCJ) Eth3/22 172 R S s N7K-C7009 Eth3/7
# Da DC1-Agg2 keine Einträge im URIB hat, wird das Paket empfangen und an die CPU gesendet, wodurch der DC1-Agg2 gezwungen wird, eine ARP-Anfrage von der SVI-IP-Adresse zu generieren, wie unten gezeigt.
2020-02-18 15:09:05.673165 172.17.200.1 -> 172.16.144.119 ICMP 114 Echo (ping) request id=0x0022, seq=0/0, ttl=254
2020-02-18 15:09:05.675041 de:ad:20:19:22:22 -> Broadcast ARP 60 Who has 172.16.144.119? Tell 172.16.144.251
# Diese ARP-Anfrage ist eine Broadcast-Anfrage und wird in der gesamten Layer 2-Domäne weitergeleitet, die auch das DC2 über die OTV-Erweiterung umfasst.
# RZ2-Silent Host antwortet jetzt auf die ARP-Anfrage von DC1-Agg2
# DC1-Agg2 erhält diese ARP-Antwort vom unbeaufsichtigten Host
2020-02-18 15:09:05.675797 64:12:25:97:46:41 -> de:ad:20:19:22:22 ARP 60 172.16.144.119 is at 64:12:25:97:46:41
# Da das empfangene Paket ARP war (das als Hinweis für LISP dient), wird eine ICMP ECHO-Anfrage vom HSRP VIP-> 172.16.144.254 generiert und für den stummen Host-> 172.16.144.119 bestimmt. Die Absicht, das Paket vom HSRP VIP zu beziehen, besteht darin, zu verstehen, ob der Host lokal oder remote ist. Wenn der Host remote ist, ist das FHRP Active auch im Remote-Rechenzentrum vorhanden, das das ICMP ECHO-Reply-Paket vom Host abfangen würde. Dies führt dazu, dass DC2-Agg2 (das HSRP-Aktiv) Informationen zu diesem Eintrag erhält, und der LISP-Prozess wird nun eine EID Learn-Datei auf der Grundlage dieses IP-Pakets erstellen. Das DC1-Agg2, das ursprünglich die ICMP ECHO-Anfrage vom HSRP VIP bezogen hat, erhält nie eine Antwort, sodass auf DC1-Seite niemals Endpunkterfahrung stattfinden wird. Stattdessen wird es auf der Seite DC2 stehen.
DC2-AGG2# show lisp dynamic-eid detail vrf tenant-1 LISP Dynamic EID Information for VRF "tenant-1" Dynamic-EID name: VLAN144 Database-mapping [2] EID-prefix: 172.16.144.0/24, LSBs: 0x00000003 Locator: 10.10.20.1, priority: 50, weight: 50 Uptime: 21:50:32, state: up Locator: 10.10.20.2, priority: 50, weight: 50 Uptime: 21:50:13, state: up, local Registering more-specific dynamic-EIDs Registering routes: disabled Allowed-list filter: none applied Map-Server(s): none configured, use global Map-Server Site-based multicast Map-Notify group: 239.254.254.254 Extended Subnet Mode configured on 1 interfaces Number of roaming dynamic-EIDs discovered: 3 Last dynamic-EID discovered: 172.16.144.254, 00:01:10 ago Roaming dynamic-EIDs: 172.16.144.2, Vlan144, uptime: 19:09:07, last activity: 00:05:21 Discovered by: packet reception 172.16.144.119, Vlan144, uptime: 00:05:55, last activity: 00:05:55 Discovered by: packet reception 172.16.144.252, Vlan144, uptime: 3d21h, last activity: 00:01:10 Discovered by: packet reception Secure-handoff pending for sources: none
# Sobald der LISP-Prozess die EID auf DC2-Agg2 (HSRP aktiv) erkennt, wird
a) Lokale Installation von /32
b) Weiterverteilung der Route zum DC2-Core
c) Senden einer standortbasierten Benachrichtigung als Multicast-Nachricht im VLAN(in diesem Beispiel wird die Nachricht an die Gruppe gerichtet -> 239.254.254.254)
DC2-AGG1# show lisp dynamic-eid detail vrf tenant-1 LISP Dynamic EID Information for VRF "tenant-1" Dynamic-EID name: VLAN144 Database-mapping [2] EID-prefix: 172.16.144.0/24, LSBs: 0x00000003 Locator: 10.10.20.1, priority: 50, weight: 50 Uptime: 21:52:39, state: up, local Locator: 10.10.20.2, priority: 50, weight: 50 Uptime: 21:52:08, state: up Registering more-specific dynamic-EIDs Registering routes: disabled Allowed-list filter: none applied Map-Server(s): none configured, use global Map-Server Site-based multicast Map-Notify group: 239.254.254.254 Extended Subnet Mode configured on 1 interfaces Number of roaming dynamic-EIDs discovered: 4 Last dynamic-EID discovered: 172.16.144.254, 00:03:07 ago Roaming dynamic-EIDs: 172.16.144.2, Vlan144, uptime: 19:11:04, last activity: 00:00:21 Discovered by: site-based Map-Notify 172.16.144.110, Vlan144, uptime: 20:04:09, last activity: 20:04:09 Discovered by: site-based Map-Notify 172.16.144.119, Vlan144, uptime: 00:07:52, last activity: 00:00:21 Discovered by: site-based Map-Notify 172.16.144.252, Vlan144, uptime: 21:50:51, last activity: 00:00:21 Discovered by: site-based Map-Notify Secure-handoff pending for sources: none
# Am Ende empfängt der Zweigstellen-Router1 diese /32-Route, die dazu führt, dass der Zweigstellen-Router den Datenverkehr an den richtigen DC2-Core-Switch sendet.
Branch1-Router# sh ip route 172.16.144.119 Routing entry for 172.16.144.119/32 Known via "eigrp 100", distance 170, metric 51712, type external Redistributing via eigrp 100 Last update from 192.168.99.2 on GigabitEthernet0/0/1, 00:06:25 ago Routing Descriptor Blocks: * 192.168.99.2, from 192.168.99.2, 00:06:25 ago, via GigabitEthernet0/0/1 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2
# Da L2-Erweiterung für diese Topologie konfiguriert ist, kann ein Host von DC1 zu DC2 wechseln.
# Host-> 172.16.144.100 befindet sich in VLAN 144 und anfänglich in DC1.
# Die Route innerhalb der DC1-Agg1- und DC1-Agg2-Switches verläuft wie folgt, wenn der Host in DC1 online ist.
DC1-AGG1# sh ip route 172.16.144.100 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.100/32, ubest/mbest: 1/0, attached *via 172.16.144.100, Vlan144, [240/1], 00:05:03, lisp, dyn-eid via 172.16.144.100, Vlan144, [250/0], 00:05:05, am DC1-AGG2# sh ip route 172.16.144.100 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.100/32, ubest/mbest: 1/0, attached *via 172.16.144.100, Vlan144, [240/1], 00:08:05, lisp, dyn-eid via 172.16.144.100, Vlan144, [250/0], 00:08:07, am
# Die Route eines Zweigstellen-Routers verweist wie unten auf den DC1-Core, und eine Traceroute weist die DC1-Core/Agg-Switches darauf hin, den Host zu erreichen, der sich in DC1 befindet.
Branch1-Router#sh ip route 172.16.144.100 Routing entry for 172.16.144.100/32 Known via "eigrp 100", distance 170, metric 51712, type external Redistributing via eigrp 100 Last update from 192.168.99.1 on GigabitEthernet0/0/1, 00:00:06 ago Routing Descriptor Blocks: * 192.168.99.1, from 192.168.99.1, 00:00:06 ago, via GigabitEthernet0/0/1 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2 Branch1-Router#traceroute 172.16.144.100 source 172.17.200.1 Type escape sequence to abort. Tracing the route to 172.16.144.100 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.99.1 1 msec 1 msec 0 msec # DC1-Core 2 192.168.98.5 1 msec 1 msec # DC1-Agg2 192.168.98.1 1 msec # DC1-Agg1 3 172.16.144.100 1 msec 0 msec 1 msec # DC1-Host
# Wenn der Host nach DC2 wechselt, würde er ein GARP aus dem VLAN 144 senden. Dies wird bei den DC2-Agg-Switches beobachtet.
2020-02-24 22:23:05.024902 Cisco_5a:4a:e7 -> Broadcast ARP 60 Gratuitous ARP for 172.16.144.100 (Request)
# Sobald ein Paket mit dem ARP/GARP/RARP empfangen wird, löst es den Lokalisierungsmechanismus aus, eine ICMP-Echo-Anfrage vom VIP an den Host zu senden
2020-02-24 22:23:05.026781 172.16.144.254 -> 172.16.144.100 ICMP 60 Echo (ping) request id=0xac10, seq=0/0, ttl=128
# Host-172.16.144.100 antwortet jetzt auf das HSRP VIP
2020-02-24 22:23:07.035292 172.16.144.100 -> 172.16.144.254 ICMP 60 Echo (ping) reply id=0xac10, seq=0/0, ttl=255
# Sobald das IP-Paket bei DC2-Agg1 eingegangen ist, erkennt der LISP die EID und gibt einen Eintrag in die Routing-Tabelle für den Host ein und beginnt mit der Neuverteilung zum EIGRP.
DC2-AGG1# sh ip route 172.16.144.100 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.100/32, ubest/mbest: 1/0, attached *via 172.16.144.100, Vlan144, [240/1], 00:00:30, lisp, dyn-eid via 172.16.144.100, Vlan144, [250/0], 00:00:32, am
# Nach der Neuverteilung sieht der DC1-Agg-Standort (der der ursprüngliche Eigentümer dieses Hosts war) nun die Änderung in der RIB, die auf das EIGRP verweist.
DC1-AGG1# sh ip route 172.16.144.100 vrf tenant-1 IP Route Table for VRF "tenant-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.144.100/32, ubest/mbest: 1/0 *via 192.168.98.2, Eth3/6.111, [245/51968], 00:03:47, eigrp-100, external
# Auf einem Remote-Zweigstellen-Router wird jetzt die Routenänderung angezeigt, und die Tracerouten spiegeln die Pfadänderung zu den DC2-Core-/Aggregations-Switches wider (siehe unten).
Branch1-Router#sh ip route 172.16.144.100 Routing entry for 172.16.144.100/32 Known via "eigrp 100", distance 170, metric 51712, type external Redistributing via eigrp 100 Last update from 192.168.99.2 on GigabitEthernet0/0/1, 00:00:00 ago Routing Descriptor Blocks: * 192.168.99.2, from 192.168.99.2, 00:00:00 ago, via GigabitEthernet0/0/1 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1492 bytes Loading 1/255, Hops 2 Branch1-Router#traceroute 172.16.144.100 source 172.17.200.1 Type escape sequence to abort. Tracing the route to 172.16.144.100 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.99.2 1 msec 0 msec 1 msec # DC2-Core 2 192.168.94.1 1 msec 1 msec 1 msec # DC2-Agg1 3 172.16.144.100 0 msec 0 msec 1 msec # Host-after move to DC2
# show lisp dynamic-eid detail vrf <VRF-Name>
# Show ip route lisp vrf <VRF-Name>
# show lisp dynamic-eid summary vrf <VRF-Name>