Nexus 7000 Configuratie en verificatie van IGP-ondersteuning van LIJST - uitgebreid subnetmodel

Inleiding

Dit document legt uit hoe u LISP IGP Assist Extended Subnet Mode (ESM) kunt implementeren met behulp van een Nexus 7000

Topologie

Details van de topologie

• DC1 en DC2 zijn twee locaties die uitgebreid zijn door OTV
• De VLAN's 144, 145 en 244 worden geconfigureerd op alle AG-, toegangslaag- en OTV-switches
• SVI's voor deze VLAN's worden ingesteld op de Agg-switches. SVI's 144 en 244 zijn in VRF-huurder-1; SVI 145 is in VRF huurder-2. 
• Tijdens de implementatie van de IGP-hulp van de LISP is het geen vereiste dat de SVI's in VRF's moeten zijn; In dit voorbeeld worden meerdere VRF’s gebruikt om de wijzigingen in de configuratie te illustreren die vereist zijn (onder elke relevante VRF-context); Alle SVI’s kunnen in dezelfde VRF worden geplaatst en kunnen nog steeds LISP-IGP-ondersteuning gebruiken 
• HSRP is ingesteld in VLAN’s 144, 145 en 244; FHRP-isolatie wordt ingesteld in deze topologie, wat betekent dat in totaal 4 switches HSRP zullen uitvoeren en beide kanten een actief/stand-by paar zullen hebben. FHRP-isolatie wordt bereikt door HSRP-Hallo berichten te filteren. 
• DC1-agg1 en DC2-Agg2 zijn vPC-paren; Hetzelfde geldt voor DC2-agg1 en DC2-agg2
• LISP-configuraties worden toegepast onder de SVI's 144, 145 en 244
• Ecu buurtschap is gevestigd van Agg tot de Core Switches per VRF. De subinterfaces draaien van Agg-switches voor elke VRF tot aan de kernswitches en de EcpBand wordt gevormd over deze subinterfaces.
• Remote Routers (Vestiging) maken ook deel uit van hetzelfde IGP-domein. 
• Wanneer de IGP van LISP Assist wordt gebruikt, is er geen Encap/Decap van de LISP en zullen de routes van de LISP moeten opnieuw verdeeld worden aan IGP (hier is het EIS). Voor dit inzetmodel dat in dit document wordt weergegeven, hebben de Vestigingsrouters geen LISP-configuratie.

Gebruikte componenten

• Agg, Core-switches zijn Nexus 7000 met SUP2E, F3/M3 actief op 8.2(4) NXOS-versie
• Vestigingsrouters zijn ASR1ks
• OTV is ingesteld in een andere VDC op deze Nexus 7000-switches; OTV en LISP moeten op verschillende VDC's staan. Het delen van de VDC is geen optie.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Vereiste configuraties op AGG-switches

LISP-specifieke configuratie voor DC1-agg1 en 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

# De database mapping moet zodanig worden verstrekt dat aan één kant zowel de DC1-Agg1- als DC1-Agg2 Loopback IP-adressen moeten worden gespecificeerd; Binnen DC2-Agg1 en DC2-Agg2 zal een unieke loopback moeten worden gemaakt en hetzelfde in de database-mapping moeten zetten.

# In een IGP assistent-modus, als de configuratie-> "ip lisp itr-etr" wordt gebruikt, zal dit resulteren in injecteren /32 00-host route voor niet LISP-enabled VLAN’s; Dus de juiste configuratie is "ip lisp etr" voor IGP hulpmodus.

LISP-specifieke configuratie voor DC2-agg1 en 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

# Het verschil tussen DC1 en DC2 AGG LISP configuraties zijn de loopbacks gedefinieerd in de "database mapping". In DC1-configuratie zal dit worden gedefinieerd met de loopbacks van DC1-Agg1 en DC1-Agg2, en voor DC2 zullen de mappings van de gegevensbank worden gedefinieerd met de loopbacks die in DC2-Agg1 en DC2-Agg2 zijn

#Rest van de hieronder getoonde IGP/Route-maps/prefix-lijsten configuraties zal gelijk zijn (de IP adressen toegewezen voor de interfaces zijn inderdaad verschillend)

IGP-specifiek

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-enabled AGG VDC's zullen ook IGP-buurten vormen aan de Core side 

# In dit voorbeeld werden subinterfaces die deel uitmaakten van elke VRF-huurder gebruikt om de wijk naar de kern te vormen, zoals hieronder wordt weergegeven.

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

Routekaarten/prefixlijsten

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 bovenstaande configuraties zijn vereist op alle AGG-switches (DC1 en DC2). Houd in gedachten om unieke IP-adressen te bieden voor de SVI’s, Loopbacks en HSRP VIP hetzelfde voor alle SVI’s

OTV VDC-configuraties

HSRP-filtering

# Voor IGP-hulpimplementaties, moet, wanneer deze worden uitgebreid door middel van OTV of een ander mechanisme, de FHRP-isolatie zijn ingesteld; 

# Dit gebeurt door de FHRP Hallo-berichten binnen de OTV VDC te filteren

# In dit voorbeeld wordt N7k OTV gebruikt en zijn dus onderstaande configuraties toegepast om de FHRP-pakketten in OTV VDC te filteren.

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-filtering Configuraties zijn alleen vereist op OTV-VDC’s; Als een ASR OTV-toepassing wordt gebruikt, moeten de filtermechanismen worden gebruikt als relevant en gedocumenteerd volgens de ASR-configuratiegids.

OTV-onderdrukking: ARP

# Uitschakelen van ARP ND-cache op OTV VDC’s

interface Overlay0
 no otv suppress-arp-nd >>>>> 

Routebevolking door LISP-configuratie

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

# Als LISP is ingeschakeld op SVI 144 zijn er twee Null0-routes die automatisch worden aangemaakt; SVI 144 is een /24-net en dus 1st 00-route is vanaf 172.16.144.0/25 en de tweede zal 172.16.144.128/25 zijn zoals hierboven wordt getoond. 

# Dit wordt verwacht en door ontwerp; Dit gebeurt om ervoor te zorgen dat de pakketten die afkomstig zijn van niet-ontdekte hosts, een RPF-uitzondering veroorzaken die ertoe zal leiden dat de pakketten worden gestraft op CPU’s en uiteindelijk zal helpen bij Host Detectie (EID)

Volgorde van gebeurtenissen wanneer host online komt in een LISP-enabled SVI

# Host detectie op LISP enabled interfaces is gebaseerd op de ontvangst van L3 verkeer van IP adressen binnen het bereik dat in de database-mapping configuratie is gespecificeerd.

Om de detectie van hosts te vergemakkelijken, dient u erop te letten dat wanneer LISP op een interface is ingeschakeld:
 # RPF uitzonderingen worden ingeschakeld op de interface zodat de pakketten die door onbekende bronnen worden gegenereerd de uitzondering activeren
 # LISP-bron Null0-routes geïnstalleerd om ervoor te zorgen dat onbekende bronnen de RPF-uitzondering activeren

Aangezien deze oplossing op OTV voor L2 uitbreiding tussen de twee datacenters steunt, kan ARP-signalering niet direct worden gebruikt om IP-hosts te detecteren, aangezien in veel gevallen wordt uitgezonden naar alle switches.

ARP-signalen worden echter gebruikt als indicatie voor LISP dat een host niet wordt gedetecteerd. Aangezien de host aan elke kant van de OTV-brug kan wonen, start LISP een localisatiemechanisme nadat hij een nieuwe IP-MAC-binding heeft geleerd.
Het localisatiemechanisme werkt als volgt:
 # De switch leert een nieuwe IP-MAC-binding (door een ARP-, RARP- of ARP-verzoek).
 # De switch die als een actief HSRP werkt stuurt een echo-verzoek naar de host maar is afkomstig van het HSRP VIP-adres
 # De host antwoordt op het echo-verzoek, maar na het FHRP-isolement in OTV wordt het echo-antwoord alleen ontvangen op de DC-site waar de host verblijft
 # Aangezien het echo antwoord een L3 pakket is, wordt de host vervolgens gedetecteerd door LISP.

# Als er een IP-pakket op een SVI-enabled-LIJST is ontvangen, dan voert u het LISP-proces in om te weten dat het Eindpunt plaatselijk is; er zullen geen verzoeken van ICMP ECHO worden verzonden om verder te bevestigen of de gastheer lokaal is of niet. Daarom is het van cruciaal belang op te merken dat een Ping van DC2 Host naar DC1-AGG SVI IP-adressen leidt tot corruptie van de identificatie van de eindpunten, wat ook kan leiden tot het opvullen van verlies of een verkeerstekort, aangezien de gastheer nu in DC1 wordt geïdentificeerd als een lokale EID in plaats van DC2. Dus pings moeten niet afkomstig zijn van SVI IP-adressen in een LISP-omgeving, omdat dit de routingtabel kan verstoren tot het blokkeren van het zwarten gevolge kan hebben. Het zelfde probleem zal voorkomen als de Hosts die in LISP Enabled VLAN zijn de SVI IP adressen proberen te pingelen; Het indrukken van de VIP zou fijn moeten zijn aangezien het zelfde aanwezig is en actief op zowel Zijkanten als de plaats Lokaal zal het pakket vangen.

Een voorbeeld van het routeren van een tabelingang wanneer een gastheer online is in DC1 is zoals hieronder;

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

# Zoals hierboven is gezien, zijn er twee routes; Eén per LISP-proces met de administratieve Afstand van 240 en andere door AM-> Adjacency Manager (bevolkt door ARP-proces) die AD van 250 heeft.

# Beide Agg-switches in DC1 hebben dezelfde ingang.

# tevens zal LISP dezelfde vermelding voor de host in de dynamische EID-tabel opnemen als hieronder wordt weergegeven.

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

# Discovery is in beide gevallen verschillend; DC1-AGG1, het actieve HSRP, registreert de ingang door middel van "pakkethesie", wat betekent dat er een pakje was dat erin kwam, dat resulteerde in het toevoegen van het product als een EID

#zodra Agg1 kennis kreeg van een EID, stuurt zij een multicast bericht van het IP-bronadres Loopback100 IP-adres (gedefinieerd onder database mapping) naar de groep-C> 239.254.254.254(ingesteld hierboven) en de vPC-peer-switch ontvangt het ook en vult de vermelding dienovereenkomstig aan, en beschouwt dit als een lokale EID de database mapping met zowel de IP-adressen van dc1-agg1 als dc1-agg2. Dit zelfde multicast pakket zou ook door de OTV naar de externe sites lopen; Afstandssites zouden echter de database mapping controleren en aangezien dit pakket afkomstig is van een IP-adres dat verschilt van dat van de "database mapping", wordt het niet als een lokale EID beschouwd door de DC2 AGg-switches.

Meldingen kaart

# Wanneer een host wordt gedetecteerd door LISP-enabled SVI, wordt een geactiveerd "map-notification" bericht verzonden naar de multicastgroep die wordt gedefinieerd onder de corresponderende dynamische EID-configuratie

# Andere dan de getriggerde map-notification, er zijn periodieke plattegronden die worden verstuurd door de actieve (of FHRP actieve) schakelaar in dat VLAN; 

#Een PCAP van een kaart bericht is als volgt.

Herverdeling van LISP/32-routes naar IGP

# Dit is de sleutel voor IGP-hulpmodus; Elke /32 LISP-route wordt opnieuw verdeeld onder IGP; Dit wordt mogelijk gemaakt door de opdracht "LISP opnieuw verdelen" die onder Ecu werd toegepast.  

#Any2/32 host-route zal na de herdistributie worden gezien als een Ecu-externe route. Een aanpassing van de Administratieve afstand werd gedaan om het hoger te maken. Dit is om ervoor te zorgen dat de LISP route in URIB in tegenstelling tot de inkomende Externe Routeschema zal blijven. bijvoorbeeld; DC1-Agg1 en DC1-Agg2 zijn buren EBRE met DC1-core. Een A/32-route werd door DC1-AGG1 aan DC1-Core geïnjecteerd door middel van herverdeling. Nu de DC1-Core een buurman is met een Ecu van DC1-Agg2, kan de zelfde route terugkeren naar DC1-Agg2 en een kans hebben om over de route van een LIJST (die een AD van 240 heeft) te winnen als de RuE 170 was; Om dit te vermijden, is de externe route Ecu aangepast aan 245. 

# De /32 route die door de DC1-Agg-switches is geleerd, wordt herverdeeld naar Ecu en de DC1-core invoer ziet er hieronder uit. 

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

# De route is aanwezig in de Global Routing-tabel en er is geen VRF ingesteld aan de Core-zijde. 

# En door de "redistribudirect" die werd ingesteld op AGG-switches, zal de Core ook een /24 ECMP-route hebben voor het moedernet zoals hieronder wordt weergegeven. Dit zal helpen om verkeer aan te trekken voor een stille gastheer (waarvoor geen /32-route is).

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

# Ook een /24 ECMP-route wordt gezien op zowel de DC1- als DC2-kernen

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

#Deze route zou ervoor zorgen dat een Vestigingshost naar een stille host kan reiken die op beide locaties woont. 

Pad van het pakje voor Intra-VLAN inter-DC

# Als DC1-Host1 -> 172.16.14.1 probeert DC2-Host1-> 172.16.144.2 te bereiken, is dit intra VLAN-verkeer tussen datacenters. DC1-Host 1 stuurt een ARP-verzoek in dat alle stappen door de OTV zal lopen en DC2-Host1 zal bereiken

# DC2-Host1 reageert met een ARP-antwoord dat terugkeert naar de DC1-Host1

# Opeenvolgende ICMP-pakketten worden verzonden via OTV

Pad van het pakket voor Inter-VLAN inter-DC(Van VLAN 144 tot VLAN 244)

# Wanneer DC1-Host1-> 172.16.14.1 probeert DC2-Host2-172.16.244.2 te bereiken, wordt het Packet NIET van VLAN 144 naar 244 in DC1 routed Grid-router; Het volgt eerder een routepad van DC1-Agg naar DC1-Core en arriveert dan bij de DC2-Core en de definitieve routing zal worden uitgevoerd door de DC2-Agg-switches naar de bestemming VLAN-244.

# A traceroute van DC1-Host1 naar DC2-Host2 is zoals hieronder.

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

Pad van het pakket voor Inter-VLAN inter-DC (Van VRF-huurder-1 tot VRF huurder-2)

# Dit gaat hetzelfde volgen als inter-VLAN inter-DC communicatie van het ene VLAN naar het andere (vorige voorbeeld)

# Als DC1-host1-> 172.16.14.1 probeert DC2-Host3-> 172.16.145.2 te bereiken, is dit interVLAN-verkeer dat afkomstig is uit VLAN 144 (VRF-huurder-1) en bestemd is voor VLAN 145 (VRF-2). Anders dan bij normale N7k OTV-implementaties zal dit verkeer iets anders worden behandeld. Er zal geen routing tussen VLAN’s plaatsvinden aan DC1-zijde; Dit verkeer zal eerder worden routeerd en naar de DC1-kern worden verzonden en de kern zal het verder door de IGP naar de DC2-Core leiden

# In het belang van dit document wordt het lekken van interVRF per site door de Core Switch uitgevoerd. Het zou elk apparaat kunnen zijn (zoals firewalls); Er zijn geen wijzigingen vanuit het perspectief van de LISP Configuration indien Inter-VRF Leaking aanwezig is of niet. 

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

# A Traceroute van DC1-Host1 tot DC2-Host3 zal het zelfde onthullen dat zijn niet interVLAN routed, eerder Layer 3 door de Core wordt geleid. Kortom, het Inter-VLAN-verkeer zal niet de OTV gebruiken.

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# 

Pad van het Packet wanneer een Vestiging-1 Host probeert een Silent Host te bereiken dat in DC2 aanwezig is

# Host in Branch-1-172.17.200.1 probeert DC2-Silent Host-172.16.144.119 te bereiken. Aangezien de gastheer zwijgt, zal er geen /32-route aanwezig zijn in DC2. 

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

# Volgens het LISP-ontwerp zal de route 172.16.144.119 overeenkomen met de nul-route 172.16.144.0/25. 

# Wanneer de Vestigingsrouter een pakket met de bestemming IP = 172.16.144.119 ontvangt, heeft URIB een ECMP/24-route naar zowel DC1-core als DC2-core. Dat betekent dat het pakket naar één van de Core switches wordt verzonden.

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

# Het pakket per CEF is aan het hakken op 192.168.99.1(dat DC1-Core is)

# DC1-Core heeft 2 ECMP-paden; Een gericht op de DC1-Agg1(actieve HSRP) en de tweede, richting de DC1-Agg2(HSRP). Van het routingstok zal het geselecteerde pad het DC1-Agg2 zijn.

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  

# Aangezien de DC1-Agg2 geen waarden in het URIB heeft, zal het pakket worden genationaliseerd en naar CPU worden verzonden die de DC1-Agg2 zal dwingen om een ARP-verzoek van het SVI IP-adres te genereren zoals hieronder wordt getoond.

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

# Dit ARP-verzoek is een uitzending en verspreidt zich in het gehele Layer 2-domein dat ook DC2 via de OTV Extension omvat. 

# DC2-Silent Host reageert nu op het ARP-verzoek van DC1-Agg2

# DC1-Agg2 ontvangt dit ARP-antwoord van de stille 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

# Aangezien het ontvangen pakket ARP (dat fungeert als hint voor LISP) was, wordt een ICMP ECHO-aanvraag gegenereerd vanuit HSRP VIP-> 172.16.144.254 en is bestemd voor de stille host-> 172.16.144.119. De bedoeling het pakket aan te kopen HSRP VIP moet begrijpen of de host lokaal of extern is. Als de host extern is, dan is de FHRP Active ook aanwezig in het externe Datacenter dat het ICMP ECHO Reantwoordpakket van de host zou vangen en dit resulteert in DC2-Agg2 (wat de HSRP Active is) om meer te weten te komen over deze invoer en het LISP-proces maakt nu een EID Leer op basis van dit IP-pakket. De DC1-Agg2 die oorspronkelijk het ICMP ECHO-verzoek van de HSRP VIP heeft aangekocht, krijgt nooit een antwoord en dus zal het leren van eindpunten nooit aan DC1-zijde plaatsvinden; Het zal eerder aan de DC2 kant staan. 

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

# Zodra het LISP-proces bekend is met het EID op DC2-Agg2(HSRP actief), zal het

 a) Installeer een computer /32 lokaal

 b) Verdeel de route opnieuw naar DC2-Core

 c) Een bericht op de site verzenden als een multicast bericht in het VLAN (In dit voorbeeld is het bericht bestemd voor de groep -> 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

# Aan het eind, zal de Vestiging-router1 deze /32 route ontvangen die in de router van de Vestiging zal resulteren om het verkeer naar de juiste DC2-core schakelaar te verzenden.

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

Volgorde van gebeurtenissen wanneer een host beweegt (Ram) van DC1 naar DC2

# Gezien het feit dat L2 Extension wordt geconfigureerd op deze topologie kan een Host van DC1 naar DC2 bewegen.

# host-> 172.16.14.100 is in VLAN 144 en in DC1 in eerste instantie. 

# De route binnen DC1-Agg1- en DC1-Agg2-switches zal als volgt zijn wanneer de host online is in DC1

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

# Een branrouter zal de route hebben die naar de DC1-Core wijst zoals hieronder en een tracoute zal de DC1 Core/agg-switches richten om de host te bereiken die in DC1 is

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

# wanneer de host zich naar DC2 beweegt, zou het een GARP in VLAN 144 verzenden. Dit zou worden gezien bij de DC2-Agg switches

2020-02-24 22:23:05.024902 Cisco_5a:4a:e7 -> Broadcast    ARP 60 Gratuitous ARP for 172.16.144.100 (Request)

# Zodra een pakket met het ARP/GARP/RARP/is ontvangen, start het het localisatiemechanisme om een ICMP Echo-aanvraag naar de host te genereren die is betrokken bij de VIP

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.14.100 reageert nu op de 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

# Zodra het IP-pakket bij DC2-Agg1 wordt ontvangen, zal LISP het EID detecteren en in de routingtabel voor de host een boeking doen en het herdistributieproces naar de EIS starten

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

# Met de herdistributie op zijn plaats, zou de DC1-agg site (die de originele eigenaar van deze host was) nu de verandering in de RIB zien aanwijzen naar de EHRM

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

# Een verre Vestigingsrouter zal nu de routeverandering zien en de traceroutes zullen de padverandering in de DC2 kern/Agg-switches weerspiegelen zoals hieronder wordt getoond

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

Handige verificatieopdrachten

# tonen dynamisch-eid detail vrf <VRF Naam> 

#ip routelisp vrf <VRF-naam>

# tonen dynamisch-eid samenvatting van de lissabonstrategie via <VRF-naam>