Come selezionare un particolare sito da utilizzare come Internet Breakout regionale preferito?
Sommario
Introduzione
Questo documento descrive come configurare SD-WAN fabric per configurare una particolare filiale vEdge come breakout Internet regionale preferito con l'aiuto di Direct Internet Access (DIA) e policy di dati centralizzati. Questa soluzione potrebbe essere utile nel caso, ad esempio, in cui un sito regionale utilizza un servizio centralizzato come Zscaler® e dovrebbe essere utilizzato come punto di uscita Internet preferito. Questa distribuzione richiede la configurazione dei tunnel GRE (Generic Routing Encapsulation) o IPSec (Internet Protocol Security) da una VPN di trasporto e un flusso di dati diverso dalla normale soluzione DIA, in cui il traffico raggiunge Internet direttamente.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza di questo argomento:
- Conoscenze base di SD-WAN Policy Framework.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Router vEdge
- vSmart Controller con versione software 18.3.5.
Premesse
Il traffico VPN del servizio da vEdge2, che dovrebbe raggiungere Internet, viene inoltrato a un'altra diramazione vEdge1, utilizzando tunnel del piano dati. vEdge1 è il router in cui DIA è configurata per l'interruzione di Internet locale.
Esempio di rete
| Nome host | vEdge 1 | vEdge2 |
| Ruolo host | Dispositivo di succursale con DIA (Regional Internet Breakout) | Dispositivo di diramazione senza DIA configurato |
| VPN 0 | ||
| TLOC (Transport Locations) 1 | biz-internet, ip: 192.168.110.6/24 | biz-internet, ip: 192.168.110.5/24 |
| TLOC (Transport Locations) 2 | internet-pubblico, ip: 192.168.109.4/24 | internet-pubblico, ip: 192.168.109.5/24 |
| Service VPN 40 | Interfaccia ge0/1, ip: 192.168.40.4/24 | Interfaccia ge0/2, ip: 192.168.50.5/24 |
Configurazioni
Soluzione 1: Utilizzo centralizzato delle regole sui dati per modificare l'hop successivo.
vEdge2 dispone di un tunnel del piano dati stabilito con vEdge1 e altri siti (connettività in stile rete completa)
Per vEdge1, il comando DIA è configurato con ip route 0.0.0.0/0 vpn 0.
Configurazione delle regole dei dati centralizzate vSmart:
policy
data-policy DIA_vE1
vpn-list VPN_40
sequence 5
match
destination-data-prefix-list ENTERPRISE_IPs
!
action accept
!
!
sequence 10
action accept
set
next-hop 192.168.40.4
!
!
!
default-action accept
!
!
!
lists
vpn-list VPN_40
vpn 40
!
data-prefix-list ENTERPRISE_IPs
ip-prefix 10.0.0.0/8
ip-prefix 172.16.0.0/12
ip-prefix 192.168.0.0/16
!
apply-policy
site-list SITE2
data-policy DIA_vE1 from-service
vEdge2 - non richiede alcuna configurazione speciale.
Qui è possibile trovare i passi per eseguire la verifica se un criterio è stato applicato correttamente.
1. Verificare che i criteri non siano presenti in vEdge2:
vedge2# show policy from-vsmart % No entries found.
2. Controllare la programmazione FIB (Forwarding Information Base). Deve mostrare l'assenza di route (blackhole) per la destinazione su Internet:
vedge2# show policy service-path vpn 40 interface ge0/2 source-ip 192.168.50.5 dest-ip 173.37.145.84 protocol 1 all Number of possible next hops: 1 Next Hop: Blackhole
3. Applicare i criteri dati vSmart nella sezione apply-policy della configurazione vSmart o attivarli nell'interfaccia utente di vManage.
4. Verificare che vEdge2 abbia ricevuto correttamente i criteri dati da vSmart:
vedge2# show policy from-vsmart
from-vsmart data-policy DIA_vE1
direction from-service
vpn-list VPN_40
sequence 5
match
destination-data-prefix-list ENTERPRISE_IPs
action accept
sequence 10
action accept
set
next-hop 192.168.40.4
default-action accept
from-vsmart lists vpn-list VPN_40
vpn 40
from-vsmart lists data-prefix-list ENTERPRISE_IPs
ip-prefix 10.0.0.0/8
ip-prefix 172.16.0.0/12
ip-prefix 192.168.0.0/16
5. Controllare la programmazione Forwarding Information Base (FIB), che mostra possibili percorsi per la destinazione su Internet:
vedge2# show policy service-path vpn 40 interface ge0/2 source-ip 192.168.50.5 dest-ip 173.37.145.84 protocol 1 all Number of possible next hops: 4 Next Hop: IPsec Source: 192.168.110.5 12366 Destination: 192.168.110.6 12346 Color: biz-internet Next Hop: IPsec Source: 192.168.109.5 12366 Destination: 192.168.110.6 12346 Color: public-internet Next Hop: IPsec Source: 192.168.110.5 12366 Destination: 192.168.109.4 12346 Color: biz-internet Next Hop: IPsec Source: 192.168.109.5 12366 Destination: 192.168.109.4 12346 Color: public-internet
6. Confermare la raggiungibilità alla destinazione su Internet:
vedge2# ping vpn 40 173.37.145.84 Ping in VPN 40 PING 173.37.145.84 (173.37.145.84) 56(84) bytes of data. 64 bytes from 173.37.145.84: icmp_seq=1 ttl=63 time=0.392 ms 64 bytes from 173.37.145.84: icmp_seq=3 ttl=63 time=0.346 ms ^C --- 173.37.145.84 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.345/0.361/0.392/0.021 ms
Qui è possibile trovare i passaggi di configurazione di vEdge1.
1. Attivare Network Address Translation (NAT) sull'interfaccia di trasporto, dove DIA deve essere utilizzato:
vpn 0 ! interface ge0/0 description "DIA interface" ip address 192.168.109.4/24 nat <<<<==== NAT activated for a local DIA !
2. Aggiungere la route statica ip route 0.0.0.0/0 vpn 0 in una VPN di servizio per attivare DIA:
vpn 40 interface ge0/4 ip address 192.168.40.4/24 no shutdown ! ip route 0.0.0.0/0 vpn 0 <<<<==== Static route for DIA !
3. Verificare se RIB contiene la route NAT:
vedge1# show ip route vpn 40 | include nat 40 0.0.0.0/0 nat - ge0/0 - 0 - - - F,S
4. Confermare che DIA funziona e possiamo vedere la sessione Internet Control Message Protocol (ICMP) a 173.37.145.84 da vEdge2 nelle traduzioni NAT
vedge1# show ip nat filter | tab
PRIVATE PRIVATE PRIVATE PUBLIC PUBLIC
NAT NAT SOURCE PRIVATE DEST SOURCE DEST PUBLIC SOURCE PUBLIC DEST SOURCE DEST FILTER IDLE OUTBOUND OUTBOUND INBOUND INBOUND
VPN IFNAME VPN PROTOCOL ADDRESS ADDRESS PORT PORT ADDRESS ADDRESS PORT PORT STATE TIMEOUT PACKETS OCTETS PACKETS OCTETS DIRECTION
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 40 icmp 192.168.50.5 173.37.145.84 9269 9269 192.168.109.4 173.37.145.84 9269 9269 established 0:00:00:02 10 840 10 980 -
Soluzione 2: Inject Argomento necessario di tipo GRE\IPSec\NAT. Route predefinito a OMP.
Al momento non è possibile ottenere la route predefinita, che punta al tunnel GRE\IPSec su vEdge1, da annunciare tramite OMP a vEdge2 (ridistribuire il protocollo OMP route NAT). Il comportamento potrebbe cambiare nelle versioni software future.
Il nostro obiettivo è creare una normale route statica predefinita (IP route 0.0.0.0/0 <indirizzo IP dell'hop successivo>) che potrebbe essere originata da vEdge2 (dispositivo preferito per DIA) e ulteriormente propagata tramite OMP.
Per ottenere questo risultato, viene creata una VPN fittizia su vEdge1 e viene eseguito un loop della porta fisica con il cavo. Viene creato un loop tra le porte assegnate a una VPN fittizia e la porta nella VPN desiderata che richiede una route statica predefinita. Inoltre, è possibile creare un loop solo con un'interfaccia fisica collegata allo switch con una VLAN fittizia e due sottointerfacce assegnate alle VPN corrispondenti, come mostrato nell'immagine seguente:
Qui è possibile trovare l'esempio di configurazione di vEdge1.
1. Creare una VPN fittizia:
vpn 50 interface ge0/3 description DIA_for_region ip address 192.168.111.2/30 no shutdown ! ip route 0.0.0.0/0 vpn 0 <<<<==== NAT activated for a local DIA
ip route 10.0.0.0/8 192.168.111.1 <<<<==== Reverse routes, pointing to loop interface GE0/3
ip route 172.16.0.0/12 192.168.111.1
ip route 192.168.0.0/16 192.168.111.1 !
2. Verificare su FIB che la route DIA, che punta all'interfaccia NAT, sia stata aggiunta correttamente alla tabella di routing:
vedge1# show ip route vpn 50 | i nat 50 0.0.0.0/0 nat - ge0/0 - 0 - - - F,S
3. VPN di servizio utilizzata per scopi di produzione, in cui è configurato un percorso predefinito regolare (che OMP potrà pubblicizzare):
vpn 40 interface ge0/4 description CORPORATE_LAN ip address 192.168.40.4/24 no shutdown ! interface ge0/5 description LOOP_for_DIA ip address 192.168.111.1/30 no shutdown ! ip route 0.0.0.0/0 192.168.111.2 <<<<==== Default route, pointing to loop interface GE0/5 omp advertise connected advertise static ! !
4. Verificare che il RIB non presenti una route predefinita che punta all'interfaccia del loop:
vedge1# show ip route vpn 40 | include 0.0.0.0 40 0.0.0.0/0 static - ge0/5 192.168.111.2 - - - - F,S
5. Verificare che vEdge1 abbia annunciato il ciclo di lavorazione predefinito tramite OMP:
vedge1# show omp routes detail | exclude not\ set
---------------------------------------------------
omp route entries for vpn 40 route 0.0.0.0/0 <<<<==== Default route OMP entry
---------------------------------------------------
RECEIVED FROM:
peer 0.0.0.0 <<<<==== OMP route is locally originated
path-id 37
label 1002
status C,Red,R
Attributes:
originator 192.168.30.4
type installed
tloc 192.168.30.4, public-internet, ipsec
overlay-id 1
site-id 13
origin-proto static
origin-metric 0
ADVERTISED TO:
peer 192.168.30.3
Attributes:
originator 192.168.30.4
label 1002
path-id 37
tloc 192.168.30.4, public-internet, ipsec
site-id 13
overlay-id 1
origin-proto static
origin-metric 0
6. vEdge2 non richiede alcuna configurazione. Il percorso predefinito viene ricevuto tramite OMP, che punta a vEdge1
vedge2# show ip route vpn 40 | include 0.0.0.0 40 0.0.0.0/0 omp - - - - 192.168.30.4 public-internet ipsec F,S
7. Confermare la raggiungibilità a 173.37.145.84:
vedge2# ping vpn 40 173.37.145.84 Ping in VPN 40 PING 173.37.145.84 (173.37.145.84) 56(84) bytes of data. 64 bytes from 173.37.145.84: icmp_seq=2 ttl=62 time=0.518 ms 64 bytes from 173.37.145.84: icmp_seq=5 ttl=62 time=0.604 ms ^C --- 192.168.109.5 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.518/0.563/0.604/0.032 ms
Soluzione 3: Immettere la route predefinita per OMP quando si utilizzano i criteri dati centralizzati per DIA.
Quando si utilizzano i criteri dei dati centralizzati per il DIA locale, il modo possibile per inserire il percorso predefinito, punta a un dispositivo regionale con DIA che è l'uso di questo percorso statico predefinito: ip route 0.0.0.0/0 Null0.
A causa del flusso di pacchetti interno, il traffico che arriva dalle filiali raggiunge DIA grazie ai criteri dati e non raggiunge mai la route verso Null0. Come si può vedere qui, la ricerca dell'hop successivo avviene solo dopo una distribuzione dei criteri.
vEdge2 dispone di un tunnel del piano dati stabilito con vEdge1 e altri siti (connettività in stile a maglia completa). Non richiede alcuna configurazione speciale.
vEdge1 dispone di DIA configurato con criteri di gestione dei dati centralizzati.
Qui è possibile trovare i passaggi di configurazione di vEdge1.
1. Attivare Network Address Translation (NAT) sull'interfaccia di trasporto, dove DIA deve essere utilizzato:
vpn 0 ! interface ge0/0 description "DIA interface" ip address 192.168.109.4/24 nat <<<<==== NAT activated for a local DIA !
2. Aggiungere la route statica ip route 0.0.0.0/0 null0 in una VPN del servizio per annunciare il valore predefinito alle diramazioni:
vpn 40 interface ge0/4 ip address 192.168.40.4/24 no shutdown ! ip route 0.0.0.0/0 null0 <<<<==== Static route to null0 that will be advertised to branches via OMP !
3. Verificare se RIB contiene il ciclo di lavorazione predefinito:
vedge1# show ip route vpn 40 | include 0.0.0.0 40 0.0.0.0/0 static - - - 0 - - - B,F,S
4. Verificare che vEdge1 abbia annunciato la route predefinita tramite OMP:
vedge1# show omp routes detail | exclude not\ set
---------------------------------------------------
omp route entries for vpn 40 route 0.0.0.0/0 <<<<==== Default route OMP entry
---------------------------------------------------
RECEIVED FROM:
peer 0.0.0.0 <<<<==== OMP route is locally originated
path-id 37
label 1002
status C,Red,R
Attributes:
originator 192.168.30.4
type installed
tloc 192.168.30.4, public-internet, ipsec
overlay-id 1
site-id 13
origin-proto static
origin-metric 0
ADVERTISED TO:
peer 192.168.30.3
Attributes:
originator 192.168.30.4
label 1002
path-id 37
tloc 192.168.30.4, public-internet, ipsec
site-id 13
overlay-id 1
origin-proto static
origin-metric 0
5. Verificare che il criterio non sia presente in vEdge1 e che DIA non sia abilitato:
vedge1# show policy from-vsmart % No entries found.
6. Controllare la programmazione FIB (Forwarding Information Base). Dovrebbe mostrare l'assenza route (Blackhole) per la destinazione su Internet perché DIA non è abilitato:
vedge1# show policy service-path vpn 40 interface ge0/2 source-ip 192.168.40.4 dest-ip 173.37.145.84 protocol 1 all Number of possible next hops: 1 Next Hop: Blackhole
Configurazione centralizzata delle regole dei dati vSmart per DIA:
policy
data-policy DIA_vE1
vpn-list VPN_40
sequence 5
match
destination-data-prefix-list ENTERPRISE_IPs
action accept
sequence 10
action accept
nat-use vpn0 <<<<==== NAT reference for a DIA
default-action accept
lists
vpn-list VPN_40
vpn 40
data-prefix-list ENTERPRISE_IPs
ip-prefix 10.0.0.0/8
ip-prefix 172.16.0.0/12
ip-prefix 192.168.0.0/16
site-list SITE1
site-id 1001
apply-policy
site-list SITE1 <<<<==== policy applied to vEdge1
data-policy DIA_vE1 from-service
Applicare i criteri dati vSmart nella sezione apply-policy della configurazione vSmart o attivarli nell'interfaccia utente di vManage.
7. Verificare che vEdge1 abbia ricevuto correttamente i criteri dati da vSmart:
vedge1# show policy from-vsmart
from-vsmart data-policy DIA_vE1
direction from-service
vpn-list VPN_40
sequence 5
match
destination-data-prefix-list ENTERPRISE_IPs
action accept
sequence 10
action accept
nat-use vpn0
default-action accept
from-vsmart lists vpn-list VPN_40
vpn 40
from-vsmart lists data-prefix-list ENTERPRISE_IPs
ip-prefix 10.0.0.0/8
ip-prefix 172.16.0.0/12
ip-prefix 192.168.0.0/16
8. Controllare la programmazione Forwarding Information Base (FIB), che mostra possibili route per la destinazione su Internet:
vedge1# show policy service-path vpn 40 interface ge0/2 source-ip 192.168.40.4 dest-ip 173.37.145.84 protocol 1 all Number of possible next hops: 1
Next Hop: Remote
Remote IP:173.37.145.84, Interface ge0/0 Index: 4
9. Confermare la raggiungibilità alla destinazione su Internet:
vedge1# ping vpn 40 173.37.145.84 Ping in VPN 40 PING 173.37.145.84 (173.37.145.84) 56(84) bytes of data. 64 bytes from 173.37.145.84: icmp_seq=1 ttl=63 time=0.192 ms
64 bytes from 173.37.145.84: icmp_seq=3 ttl=63 time=0.246 ms
64 bytes from 173.37.145.84: icmp_seq=3 ttl=63 time=0.236 ms ^C --- 173.37.145.84 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.245/0.221/0.192/0.021 ms
Passaggi verifica vEdge2:
1. Confermare che la route predefinita è stata ricevuta e installata correttamente in RIB:
vEdge2# sh ip route vpn 40 | include 0.0.0.0 40 0.0.0.0/0 omp - - - - 192.168.30.4 biz-internet ipsec F,S
40 0.0.0.0/0 omp - - - - 192.168.30.4 public-internet ipsec F,S
2. Controllare la programmazione Forwarding Information Base (FIB), che mostra possibili percorsi per la destinazione su Internet:
vedge2# show policy service-path vpn 40 interface ge0/2 source-ip 192.168.50.5 dest-ip 173.37.145.84 protocol 1 all Number of possible next hops: 4 Next Hop: IPsec Source: 192.168.110.5 12366 Destination: 192.168.110.6 12346 Color: biz-internet Next Hop: IPsec Source: 192.168.109.5 12366 Destination: 192.168.110.6 12346 Color: public-internet Next Hop: IPsec Source: 192.168.110.5 12366 Destination: 192.168.109.4 12346 Color: biz-internet Next Hop: IPsec Source: 192.168.109.5 12366 Destination: 192.168.109.4 12346 Color: public-internet
3. Confermare la raggiungibilità alla destinazione su Internet:
vedge2# ping vpn 40 173.37.145.84 Ping in VPN 40 PING 173.37.145.84 (173.37.145.84) 56(84) bytes of data. 64 bytes from 173.37.145.84: icmp_seq=1 ttl=63 time=0.382 ms
64 bytes from 173.37.145.84: icmp_seq=1 ttl=63 time=0.392 ms 64 bytes from 173.37.145.84: icmp_seq=3 ttl=63 time=0.346 ms ^C --- 173.37.145.84 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.392/0.361/0.346/0.023 ms
4. Confermare che DIA funziona e possiamo vedere la sessione Internet Control Message Protocol (ICMP) a 173.37.145.84 da vEdge2 nelle traduzioni NAT
vedge1# show ip nat filter | tab
PRIVATE PRIVATE PRIVATE PUBLIC PUBLIC
NAT NAT SOURCE PRIVATE DEST SOURCE DEST PUBLIC SOURCE PUBLIC DEST SOURCE DEST FILTER IDLE OUTBOUND OUTBOUND INBOUND INBOUND
VPN IFNAME VPN PROTOCOL ADDRESS ADDRESS PORT PORT ADDRESS ADDRESS PORT PORT STATE TIMEOUT PACKETS OCTETS PACKETS OCTETS DIRECTION
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 40 icmp 192.168.50.5 173.37.145.84 9175 9175 192.168.109.4 173.37.145.84 9175 9175 established 0:00:00:04 18 1440 18 1580 -
Soluzione 4: Inserire il percorso predefinito per OMP quando viene utilizzato DIA locale.
Questa soluzione può essere utilizzata sia per i router SD-WAN basati su IOS-XE che Viptela OS.
In breve, in questa soluzione, una route predefinita per DIA (0.0.0.0/0 Null0) viene suddivisa in due sottoreti 0.0.0.0/1 e 128.0.0.0/1 che puntano a Null0. Questa operazione viene eseguita per evitare la sovrapposizione di una route predefinita che deve essere annunciata alle diramazioni e la route predefinita, utilizzata per DIA locale. Nelle route IOS-XE utilizzate per DIA, la distanza amministrativa (AD) è uguale a 6, mentre AD con valore statico predefinito è 1. Il vantaggio della soluzione è la possibilità di utilizzare lo schema di ridondanza quando il DIA regionale è configurato in due posizioni diverse.
1. Attivare NAT su un'interfaccia di trasporto
2. In un modello di funzionalità per una VPN di servizio, in cui dovrebbe essere utilizzata la funzione DIA, aggiungere le seguenti route IPv4 statiche:
- 0.0.0.0/1 e 128.0.0.0/1 che puntano a VPN. Queste route vengono utilizzate per DIA
- 0.0.0.0/0 che punta a Null 0. Questa route viene utilizzata per la pubblicità tramite OMP alle filiali (simile alla soluzione 3)
3. Verificare che le route siano state aggiunte correttamente al RIB:
cedge1#show ip route vrf 40
Routing Table: 40
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP, D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2, E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA, i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route, o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route, + - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 0.0.0.0/0 is directly connected, Null0 <<<<==== Static route to null0 that will be advertised to branches via OMP
n Nd 0.0.0.0/1 [6/0], 00:08:23, Null0 <<<<==== DIA route
n Nd 128.0.0.0/1 [6/0], 00:08:23, Null0 <<<<==== DIA route
192.40.1.0/32 is subnetted, 1 subnets
m 192.40.1.1 [251/0] via 192.168.30.207, 3d01h
192.40.2.0/32 is subnetted, 1 subnets
m 192.40.2.1 [251/0] via 192.168.30.208, 3d01h
4. Verificare che DIA funzioni correttamente localmente:
cedge1#ping vrf 40 173.37.145.84 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 173.37.145.84, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
5. Verificare che la route predefinita sia stata annunciata a una filiale e installata in RIB
cedge3#show ip route vrf 40
Routing Table: 40
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP, D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2, E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA, i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route, o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route, + - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.30.204 to network 0.0.0.0
m* 0.0.0.0/0 [251/0] via 192.168.30.204, 00:02:45 <<<<==== Default route that advertised via OMP
192.40.1.0/32 is subnetted, 1 subnets
m 192.40.11.1 [251/0] via 192.168.30.204, 00:02:45
192.40.13.0/32 is subnetted, 1 subnets
C 192.40.13.1 is directly connected, Loopback40
6. Verificare che DIA funzioni correttamente localmente:
cedge3#ping vrf 40 173.37.145.84 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 173.37.145.84, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
7. Controllare sul router DIA regionale la traduzione NAT riuscita.
cedge1#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.109.204:1 192.40.13.1:1 173.37.145.84:1 173.37.145.84:1 Total number of translations: 1
Informazioni correlate
Feedback