Configurazione e verifica di Nexus 7000 LISP IGP Assist Extended Subnet Mode

Introduzione

Questo documento spiega come distribuire LISP IGP Assist Extended Subnet Mode (ESM) utilizzando un Nexus 7000

Topologia

Dettagli della topologia

• DC1 e DC2 sono due posizioni estese da OTV
• Le Vlan 144, 145 e 244 sono configurate su tutti gli switch Agg, Access Layer e OTV
• Le SVI per queste Vlan sono configurate sugli switch Gag. le SVI 144 e 244 sono in VRF tenant-1; SVI 145 è in VRF tenant-2. 
• Durante l'installazione di LISP IGP Assist, non è necessario che le SVI siano in VRF; In questo esempio vengono utilizzati più VRF solo per illustrare le modifiche alla configurazione necessarie (in ogni contesto VRF rilevante); Tutte le SVI possono trovarsi nello stesso VRF e possono comunque utilizzare LISP IGP assist 
• l'HSRP è configurato nelle Vlan 144, 145 e 244; In questa topologia, è configurato l'isolamento FHRP, il che significa che in totale 4 switch eseguiranno HSRP e che entrambi i dispositivi disporranno di una coppia attivo/standby. L'isolamento FHRP si ottiene filtrando i messaggi Hello HSRP. 
• DC1-agg1 e DC2-Agg2 sono coppie vPC; Lo stesso vale per DC2-Agg1 e DC2-Agg2
• Le configurazioni LISP vengono applicate con le SVI 144, 145 e 244
• Il vicinato EIGRP è stabilito da Agg ai core switch per VRF. Le sottointerfacce funzionano dagli switch Agg per ciascun VRF fino ai core switch e su queste sottointerfacce è formata la connessione EIGRP.
• Anche i router remoti (filiali) fanno parte dello stesso dominio IGP. 
• Quando si usa LISP IGP Assist, non c'è nessuna incapsulamento/decifrazione LISP e quindi le route LISP dovranno essere ridistribuite all'IGP (qui è EIGRP). Per questo modello di distribuzione illustrato in questo documento, i router della filiale non disporranno di alcuna configurazione LISP.

Componenti usati

• Agg, gli switch principali sono Nexus 7000 con SUP2E, F3/M3 con versione 8.2(4) NXOS
• I router per filiali sono ASR1
• OTV è configurato in un altro VDC su questi switch Nexus 7000; OTV e LISP devono trovarsi su VDC diverse. La condivisione di VDC non è un'opzione.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Configurazioni richieste sugli switch AGG

Configurazioni specifiche LISP su DC1-Agg1 e 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

# La mappatura del database deve essere fornita in modo che su un lato sia necessario specificare gli indirizzi IP di loopback DC1-Agg1 e DC1-Agg2; All'interno di DC2-Agg1 e DC2-Agg2, sarà necessario creare un loopback univoco e inserirlo nel mapping del database.

# In modalità assistita IGP, se si utilizza la configurazione-> "ip lisp itr-etr", viene iniettato il percorso host /32 null0 per le Vlan non abilitate per LISP; Quindi la configurazione corretta è "ip lister" per la modalità di assistenza IGP.

Configurazioni specifiche LISP su DC2-Agg1 e 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

# La differenza tra le configurazioni di DC1 e DC2 Agg LISP sono i loopback definiti nel "mapping del database". Nella configurazione DC1, questa verrà definita con i loopback di DC1-Agg1 e DC1-Agg2 e per DC2, i mapping del database verranno definiti con i loopback presenti in DC2-Agg1 e DC2-Agg2

# Le altre configurazioni IGP/Route-maps/prefix-lists mostrate di seguito saranno simili (Gli indirizzi IP assegnati per le interfacce sono effettivamente diversi)

Specifico IGP

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 abilitato AGG VDCs anche formerà il vicinato IGP al lato core 

# Per questo esempio, le sottointerfacce che facevano parte di ogni VRF tenant sono state utilizzate per formare il vicinato verso il nucleo come mostrato di seguito.

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

Route-map/Elenchi di prefissi

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 

# Tutte le configurazioni precedenti sono richieste su tutti gli switch AGG (DC1 e DC2). Tenere presente che fornire indirizzi IP univoci per SVI, loopback e VIP HSRP saranno gli stessi per tutte le SVI

Configurazioni VDC OTV

Filtro HSRP

# Per le distribuzioni di assistenza IGP, quando esteso mediante OTV o qualsiasi altro meccanismo, l'isolamento FHRP deve essere in atto; 

# Questa operazione viene eseguita filtrando i messaggi FHRP Hello all'interno del VDC OTV

# In questo esempio, viene usato N7k OTV, quindi sono state applicate le configurazioni di seguito per filtrare i pacchetti FHRP in OTV VDC.

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

# Le configurazioni del filtro FHRP sono necessarie SOLO per i VDC OTV; Se si utilizza una distribuzione ASR OTV, utilizzare i meccanismi di filtro appropriati e documentati come indicato nella guida alla configurazione di ASR.

OTV - sopprimi ARP

# Disabilitazione della funzione ARP ND-cache sui VDC OTV

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

Popolamento route dovuto alla configurazione LISP

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

# Quando LISP è abilitato su SVI 144, verranno create automaticamente due route Null0; SVI 144 è una subnet /24, quindi la prima route null0 verrà impostata su 172.16.144.0/25 e la seconda su 172.16.144.128/25, come mostrato in precedenza. 

# Previsto e progettato; questa operazione viene effettuata per essere certi che i pacchetti provenienti da host non rilevati attivino un'eccezione RPF, che causerà la punizione dei pacchetti alla CPU e contribuirà al rilevamento degli host (EID)

Sequenza di eventi quando l'host è online in una SVI abilitata per LISP

# Il rilevamento host sulle interfacce abilitate LISP si basa sulla ricezione del traffico L3 dagli indirizzi IP compresi nell'intervallo specificato nella configurazione del mapping del database.

Per facilitare il rilevamento degli host, notare che quando il protocollo LISP è abilitato su un'interfaccia:
 # Eccezioni RPF abilitate sull'interfaccia, in modo che i pacchetti generati da origini sconosciute attivino l'eccezione
 # I cicli LISP con origine Null0 vengono installati per garantire che origini sconosciute attivino l'eccezione RPF

Poiché questa soluzione si basa sull'estensione OTV per L2 tra i due data center, la segnalazione ARP non può essere utilizzata direttamente per rilevare gli host IP poiché in molti casi viene trasmessa a tutti gli switch.

Tuttavia, i segnali ARP sono utilizzati come indicazione per LISP che potrebbe essere presente un host non rilevato. Poiché l'host può risiedere su qualsiasi lato del bridge OTV, LISP avvia un meccanismo di localizzazione dopo aver appreso un nuovo binding IP-MAC.
Il meccanismo di localizzazione funziona come segue:
 # Lo switch apprende un nuovo binding IP-MAC (tramite GARP, RARP o una richiesta ARP).
 # Lo switch con funzione di HSRP attivo invia una richiesta echo all'host ma l'origine è l'indirizzo VIP HSRP
 # L'host risponde alla richiesta echo, ma a seguito dell'isolamento FHRP in OTV, la risposta echo viene ricevuta solo sul sito DC in cui risiede l'host
 # Poiché la risposta echo è un pacchetto L3, l'host viene rilevato da LISP.

# Se si riceve un pacchetto IP su una SVI abilitata per LISP, questo stesso invierà il processo LISP informando che il punto finale è Locale; non verranno inviate richieste ECHO ICMP per confermare ulteriormente se l'host è locale o meno. È quindi di fondamentale importanza notare che un ping tra gli indirizzi IP dell'host DC2 e quelli dell'SVI DC1-AGG causerà il danneggiamento dell'identificazione dell'endpoint e potrebbe causare la perdita del ping o il blocco del traffico, in quanto l'host viene ora identificato come EID locale in DC1 rispetto a DC2. Pertanto, i ping non devono avere origine dagli indirizzi IP dell'SVI in un ambiente LISP, in quanto ciò potrebbe danneggiare la tabella di routing e causare il blocco del traffico. Lo stesso problema si verifica se gli host sulla VLAN abilitata per LISP provano a eseguire il ping sugli indirizzi IP delle SVI; Il ping dell'indirizzo VIP deve essere eseguito correttamente poiché lo stesso è presente e attivo su entrambi i lati e il sito locale acquisirà il pacchetto.

Di seguito è riportato un esempio di voce della tabella di routing quando un host è in linea in DC1.

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

# Come visto sopra, ci sono due percorsi; Una per LISP processo con la Distanza amministrativa di 240 e l'altra da AM-> Gestione adiacenze (popolato dal processo ARP) che ha AD di 250.

# Entrambi gli switch Agg in DC1 avranno la stessa voce.

# inoltre, LISP elencherà la stessa voce per l'host nella tabella EID dinamica come mostrato di seguito.

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

# Rilevamento è diverso in entrambi i casi; Il DC1-AGG1, l'HSRP attivo, registra l'ingresso attraverso la "ricezione del pacchetto", che significa fondamentalmente che è arrivato un pacchetto che ha portato ad aggiungerlo come EID

# Una volta che Agg1 è venuto a conoscenza di un EID, invia un messaggio multicast dall'indirizzo IP di origine IP-> Loopback100 (definito nella mappatura del database) al gruppo-> 239.254.254.254 (configurato sopra) e lo switch peer vPC lo riceve e popola la voce di conseguenza e lo considera come un EID locale a causa del mapping del database che ha entrambi gli indirizzi IP di dc1-agg1 e dc1-agg2. Questo stesso pacchetto multicast attraverserebbe anche i siti remoti attraverso OTV; Tuttavia, i siti remoti controllano il mapping del database e, poiché il pacchetto proviene da un indirizzo IP diverso da quello del "mapping del database", non verrà considerato come EID locale dagli switch DC2 AGg.

Mapping messaggi di notifica

# Quando un host viene rilevato dalla SVI abilitata LISP, al gruppo multicast definito nella corrispondente configurazione EID dinamica viene inviato un messaggio di "notifica mappa" attivato

# Oltre ai messaggi di notifica delle mappe attivati, sono disponibili messaggi di notifica delle mappe periodici inviati dallo switch HSRP attivo (o FHRP attivo) su tale vlan; 

# Un PCAP del messaggio di notifica mappa è il seguente.

Ridistribuzione delle route LISP /32 a IGP

# Questa è la chiave per la modalità di assistenza IGP; Qualsiasi percorso /32 LISP sarà ridistribuito all'IGP; Ciò è reso possibile dal comando "redistribute LISP" applicato in EIGRP.  

# Qualsiasi route host /32 verrà considerata come route esterna EIGRP dopo la ridistribuzione. È stato effettuato un adeguamento della distanza amministrativa EIGRP per aumentarla. In questo modo si assicura che il percorso LISP rimanga nell'URIB rispetto al percorso esterno EIGRP in entrata. ad esempio; DC1-Agg1 e DC1-Agg2 sono adiacenti EIGRP con DC1-core. Una route /32 è stata iniettata da DC1-AGG1 a DC1-Core tramite ridistribuzione. Ora che il DC1-Core è adiacente EIGRP con DC1-Agg2, lo stesso percorso potrebbe tornare a DC1-Agg2 e avere la possibilità di vincere sulla route LISP (che ha un AD di 240) se l'AD EIGRP era 170; Per evitare ciò, la via esterna EIGRP AD è stata modificata a 245. 

# Il percorso /32 appreso dagli switch DC1-Agg viene ridistribuito su EIGRP e la voce DC1-core è simile a quella riportata di seguito. 

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

# Il router è presente nella tabella di routing globale e sul lato core non è configurato alcun VRF. 

# E a causa della "ridistribuzione diretta" configurata sugli switch AGG, il core disporrà anche di un percorso /24 ECMP per la subnet padre, come mostrato di seguito. Ciò aiuterà ad attirare il traffico per un host silenzioso (per il quale non esiste un percorso /32).

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

# Anche il percorso /24 ECMP è visibile sia ai core DC1 che DC2

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

# Questo percorso assicura che un host di succursale possa raggiungere un host invisibile all'utente che risiede in entrambi i percorsi. 

Percorso del pacchetto per intra-vlan inter-DC

# Quando DC1-Host1 -> 172.16.144.1 tenta di raggiungere DC2-Host1-> 172.16.144.2, si tratta del traffico tra centri dati all'interno della vlan. DC1-Host 1 invia una richiesta ARP che attraversa tutto il percorso OTV e raggiunge DC2-Host1

# DC2-Host1 risponde con una risposta ARP che ritorna a DC1-Host1

# I pacchetti ICMP successivi vengono inviati tramite OTV

Percorso del pacchetto per inter-vlan-DC (dalla Vlan 144 alla Vlan 244)

# Quando DC1-Host1-> 172.16.144.1 tenta di raggiungere DC2-Host2-> 172.16.244.2, il pacchetto NON verrà instradato dalla vlan 144 a 244 nel DC1; Al contrario, segue un percorso indirizzato da DC1-Agg a DC1-Core per poi arrivare a DC2-Core e il routing finale verrà eseguito dagli switch DC2-Agg alla Vlan-244 di destinazione.

# Di seguito è riportato un traceroute tra DC1-Host1 e DC2-Host2.

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

Percorso del pacchetto per inter-vlan-DC (da VRF-tenant-1 a VRF tenant-2)

# Questa procedura sarà simile alla comunicazione tra vlan e controller di dominio da una vlan all'altra (esempio precedente)

# Quando DC1-host1-> 172.16.144.1 tenta di raggiungere DC2-Host3-> 172.16.145.2, si tratta del traffico inter-vlan inter-DC proveniente dalla Vlan 144 (VRF tenant-1) e destinato alla Vlan 145 (VRF tenant-2). A differenza delle normali installazioni N7k OTV, questo traffico verrà trattato in modo leggermente diverso. Non vi sarà alcun routing tra vlan sul lato DC1; Piuttosto, questo traffico verrà indirizzato e inviato al DC1-core e il core lo indirizzerà ulteriormente attraverso l'IGP al DC2-Core

# Ai fini di questo documento, la perdita tra VRF viene effettuata per sito dallo switch core. Potrebbe trattarsi di qualsiasi dispositivo (come un firewall); Non vi sono modifiche dal punto di vista della configurazione LISP se è presente o meno una perdita tra VRF. 

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

# Un traceroute da DC1-Host1 a DC2-Host3 rivelerà lo stesso che il suo non inter-vlan indirizzato, piuttosto il layer 3 indirizzato attraverso il core. In breve, il traffico tra vlan non utilizzerà il protocollo 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# 

Percorso del pacchetto quando un host Branch-1 tenta di raggiungere un host invisibile all'utente presente nel controller di dominio 2

# L'host in Branch-1-172.17.200.1 tenta di raggiungere DC2-Silent Host- 172.16.144.119. Poiché l'host è silenzioso, non sarà presente alcuna route /32 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

# Secondo la progettazione LISP, la route 172.16.144.119 corrisponderà alla route 172.16.144.0/25 null0. 

# Quando il router di succursale riceve un pacchetto con IP di destinazione = 172.16.144.119, l'URI B ha una route ECMP /24 sia per DC1-core che per DC2-core. In pratica, il pacchetto verrà inviato a uno degli switch Core.

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

# Hashing del pacchetto secondo CEF su 192.168.99.1 (ovvero DC1-Core)

# DC1-Core ha 2 percorsi ECMP; Una verso DC1-Agg1 (HSRP attivo) e la seconda verso DC1-Agg2 (HSRP standby). Dall'hash di routing, il percorso selezionato sarà DC1-Agg2.

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  

# Poiché il DC1-Agg2 non contiene alcuna voce nell'URI, il pacchetto verrà generato e inviato alla CPU, forzando il DC1-Agg2 a generare una richiesta ARP dall'indirizzo IP SVI, come mostrato di seguito.

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

# Questa richiesta ARP è una trasmissione e si propaga nell'intero dominio di layer 2 che include anche il DC2 tramite l'estensione OTV. 

# DC2-Silent Host risponde ora alla richiesta ARP da DC1-Agg2

# DC1-Agg2 riceve questa risposta ARP dall'host invisibile all'utente

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

# Poiché il pacchetto ricevuto è ARP (che serve da suggerimento per LISP), viene generata una richiesta ECHO ICMP proveniente dall'host HSRP VIP-> 172.16.144.254 e destinato all'host invisibile all'utente-> 172.16.144.119. L'intenzione di inviare il pacchetto dall'host HSRP VIP è di capire se l'host è locale o remoto. Se l'host è remoto, il FHRP attivo è presente anche nel centro dati remoto che intercetta il pacchetto di risposta ECHO ICMP dall'host. In questo modo, il DC2-Agg2 (che è l'HSRP attivo) viene a conoscenza di questa voce e il processo LISP crea un EID basato su questo pacchetto IP. Il DC1-Agg2 che ha originato la richiesta ECHO ICMP dall'HSRP VIP non riceve mai una risposta e quindi l'apprendimento end point non avrà mai luogo sul lato DC1; ma sul lato DC2. 

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

# Quando il processo LISP riconosce l'EID su DC2-Agg2 (HSRP attivo),

 a) Installare un /32 localmente

 b) Ridistribuire il percorso a DC2-Core

 c) Inviare una notifica basata sul sito come messaggio multicast nella VLAN (nell'esempio, il messaggio sarà destinato al gruppo -> 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

# Al termine, il router-diramazione1 riceverà questa route /32 che determinerà l'invio del traffico al commutatore DC2-core corretto da parte del router di diramazione.

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

Sequenza di eventi quando un host sposta (roaming) da CD1 a CD2

# Considerando che l'estensione L2 è configurata in questa topologia, un host può essere spostato da DC1 a DC2.

# Host-> 172.16.144.100 si trova inizialmente nella VLAN 144 e nel CD1. 

# Il percorso tra gli switch DC1-Agg1 e DC1-Agg2 sarà il seguente quando l'host è online 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

# Il percorso di un router di succursale punta al DC1-Core come indicato di seguito e un traceroute punta agli switch DC1 Core/agg per raggiungere l'host che si trova nel DC1

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

# Quando l'host si sposta su DC2, invia un'uscita GARP nella Vlan 144. Questa condizione viene rilevata sugli switch DC2-Agg

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

# Non appena viene ricevuto un pacchetto con ARP/GARP/RARP, viene attivato il meccanismo di localizzazione per generare una richiesta Echo ICMP inviata all'host dal 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.144.100 risponderà all'indirizzo VIP HSRP

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

# Non appena il pacchetto IP viene ricevuto sul DC2-Agg1, il LISP rileva l'EID e crea una voce nella tabella di routing per l'host e avvia il processo di ridistribuzione sull'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

# Con la ridistribuzione in atto, il sito DC1-agg (che era il proprietario originale di questo host), vedrebbe ora la modifica nella RIB che punta all'EIGRP

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

# Un router di succursale remoto vedrà il cambiamento di percorso e i tracciati rifletteranno il cambiamento di percorso agli switch core/agg DC2 come mostrato di seguito

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

Comandi di verifica utili

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

# Show ip route lisp vrf <nome VRF>

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