La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento spiega come distribuire LISP IGP Assist Extended Subnet Mode (ESM) utilizzando un Nexus 7000
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.
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.
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)
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
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
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 >>>>>
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)
# 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.
# 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.
# 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.
# 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
# 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
# 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#
# 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
# 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
# show lisp dynamic-eid detail vrf <nome VRF>
# Show ip route lisp vrf <nome VRF>
# show lisp dynamic-eid summary vrf <nome VRF>