Konfiguration und Verifizierung des LISP IGP Assist Extended Subnet Mode des Nexus 7000

Einführung

In diesem Dokument wird erläutert, wie der LISP IGP Assist Extended Subnet Mode (ESM) mit einem Nexus 7000 bereitgestellt wird.

Topologie

Details der Topologie

• DC1 und DC2 sind zwei von OTV erweiterte Standorte.
• Die VLANs 144, 145 und 244 werden auf allen Agg-, Access-Layer- und OTV-Switches konfiguriert.
• SVIs für diese VLANs werden auf den Agg-Switches konfiguriert. Die SVIs 144 und 244 befinden sich im VRF-Tenant-1. SVI 145 befindet sich im VRF-Tenant-2. 
• Bei der Bereitstellung von LISP IGP Assist müssen die SVIs nicht in VRFs sein. In diesem Beispiel werden mehrere VRFs verwendet, um nur die erforderlichen Konfigurationsänderungen (unter jedem relevanten VRF-Kontext) zu veranschaulichen. Alle SVIs können sich im gleichen VRF befinden und können weiterhin LISP IGP-Unterstützung verwenden. 
• HSRP wird in den VLANs 144, 145 und 244 konfiguriert. Die FHRP-Isolierung wird in dieser Topologie konfiguriert. Das bedeutet, dass auf insgesamt vier Switches HSRP ausgeführt wird und beide Seiten über ein Aktiv/Standby-Paar verfügen. Die FHRP-Isolierung wird durch Filtern von HSRP Hello-Nachrichten erreicht. 
• DC1-agg1 und DC2-Agg2 sind vPC-Paare. Gleiches gilt für DC2-Agg1 und DC2-Agg2
• LISP-Konfigurationen werden unter den SVIs 144, 145 und 244 angewendet
• Die EIGRP-Nachbarschaft wird von Agg zu den Core-Switches pro VRF eingerichtet. Sub-Schnittstellen werden von Agg-Switches für jede VRF-Instanz bis zu den Core-Switches ausgeführt, und über diese Sub-Schnittstellen wird EIGRP Neighborship gebildet.
• Remote-Router (Zweigstelle) sind ebenfalls Teil derselben IGP-Domäne. 
• Wenn LISP IGP Assist verwendet wird, gibt es kein LISP Encap/Decap. Daher müssen die LISP-Routen an das IGP umverteilt werden (hier ist es EIGRP). Für dieses in diesem Dokument dargestellte Bereitstellungsmodell verfügen die Zweigstellen-Router nicht über eine LISP-Konfiguration.

Verwendete Komponenten

• Aggregation: Core-Switches sind Nexus 7000 mit SUP2E, F3/M3 mit 8.2(4) NXOS-Version
• Zweigstellen-Router sind ASR1ks
• OTV wird in einem anderen VDC auf diesen Nexus 7000-Switches konfiguriert. OTV und LISP müssen sich in unterschiedlichen VDCs befinden. Die gemeinsame Nutzung von VDC ist nicht möglich.

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.

Erforderliche Konfigurationen auf AGG-Switches

LISP-spezifische Konfigurationen auf DC1-Agg1 und DC1-Agg2

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.

LISP-spezifische Konfigurationen auf DC2-Agg1 und DC2-Agg2

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

IGP-spezifisch

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

Routenzuordnungen/Präfixlisten

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.

OTV-VDC-Konfigurationen

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

Routenauffüllung aufgrund der LISP-Konfiguration

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.

Reihenfolge der Ereignisse, wenn der Host in einer LISP-fähigen SVI online ist

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

Benachrichtigungsmeldungen zuordnen

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

Neuverteilung von LISP/32-Routen auf IGP

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

Pfad des Pakets für Inter-VLAN-RZ

# 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

Pfad des Pakets für Inter-VLAN-Inter-DC (Von VLAN 144 bis VLAN 244)

# 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

Pfad des Pakets für Inter-VLAN-Inter-DC(Von VRF-Tenant-1 zu VRF-Tenant-2)

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

Pfad des Pakets, wenn ein Zweigstellen-1-Host versucht, einen Silent-Host zu erreichen, der im Rechenzentrum2 vorhanden ist

# 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

Reihenfolge der Ereignisse, wenn ein Host von DC1 nach DC2 wechselt (Roam)

# 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

Nützliche Verifizierungs-Befehle

# show lisp dynamic-eid detail vrf <VRF-Name> 

# Show ip route lisp vrf <VRF-Name>

# show lisp dynamic-eid summary vrf <VRF-Name>