O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como configurar a malha SD-WAN para configurar um vEdge de filial específico como a divisão regional de Internet preferida com a ajuda do Direct Internet Access (DIA) e da política de dados centralizada. Essa solução pode ser útil no caso, por exemplo, de um site regional usar algum serviço centralizado, como o Zscaler®, e ser usado como um ponto de saída preferencial da Internet. Essa implantação exige que túneis Generic Routing Encapsulation (GRE) ou Internet Protocol Security (IPSec) sejam configurados a partir de uma VPN de transporte e o fluxo de dados é diferente da solução DIA regular, onde o tráfego chega diretamente à Internet.
A Cisco recomenda ter conhecimento deste tópico:
As informações neste documento são baseadas nestas versões de software e hardware:
O tráfego de VPN de serviço do vEdge2, que deve chegar à Internet, é encaminhado para outro vEdge1 de filial, usando túneis de plano de dados. vEdge1 é o roteador no qual o DIA foi configurado para breakout de Internet local.
Nome do host | vEdge1 | vEdge2 |
Função de host | Dispositivo de filial com DIA (Internet breakout regional) | Dispositivo de filial sem DIA configurado |
VPN 0 | ||
Locais de transporte (TLOC) 1 | biz-internet, ip: 192.168.110.6/24 | biz-internet, ip: 192.168.110.5/24 |
Locais de transporte (TLOC) 2 | internet pública, ip: 192.168.109.4/24 | internet pública, ip: 192.168.109.5/24 |
VPN de serviço 40 | Interface ge0/1, ip: 192.168.40.4/24 | Interface ge0/2, ip: 192.168.50.5/24 |
O vEdge2 tem um túnel de plano de dados estabelecido com o vEdge1 e outros sites (conectividade em estilo de malha completa)
vEdge1 tem DIA configurado com ip route 0.0.0.0/0 vpn 0.
Configuração da política de dados centralizada 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 - não exige nenhuma configuração especial.
Aqui você pode encontrar as etapas para executar a verificação se uma política foi aplicada corretamente.
1. Verifique se a política está ausente do vEdge2:
vedge2# show policy from-vsmart % No entries found.
2. Verifique a programação da Base de Informações de Encaminhamento (FIB). Deve mostrar a ausência da rota (Blackhole) para o destino na 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. Aplique a política de dados do vSmart na seção apply-policy da configuração do vSmart ou ative na GUI do vManage.
4. Verifique se o vEdge2 recebeu com êxito a política de dados do 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. Verifique a programação da Base de Informações de Encaminhamento (FIB), que mostra as possíveis rotas para o destino na 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. Confirme a acessibilidade ao destino na 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
Aqui você pode encontrar as etapas de configuração do vEdge1.
1. Ative a Network Address Translation (NAT) na interface de transporte, onde o DIA deve ser usado:
vpn 0 ! interface ge0/0 description "DIA interface" ip address 192.168.109.4/24 nat <<<<==== NAT activated for a local DIA !
2. Adicione a rota estática ip route 0.0.0.0/0 vpn 0 em uma VPN de serviço para ativar o 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. Verifique se o RIB contém a rota NAT:
vedge1# show ip route vpn 40 | include nat 40 0.0.0.0/0 nat - ge0/0 - 0 - - - F,S
4. Confirme se o DIA funciona e podemos ver a sessão Internet Control Message Protocol (ICMP) para 173.37.145.84 a partir do vEdge2 em conversões 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 -
Note: Esta solução não nos permite organizar redundância ou compartilhamento de carga com diferentes saídas regionais.
Não funciona com roteadores IOS-XE
A partir de agora, não há possibilidade de obter a rota padrão, apontando para o túnel GRE\IPSec no vEdge1, a ser anunciada por meio de OMP para vEdge2 (redistribuir o protocolo de OMP de rota nat). Observe que o comportamento pode mudar em versões futuras do software.
Nosso objetivo é criar uma rota padrão estática regular (rota IP 0.0.0.0/0 <endereço IP do próximo salto>) que possa ser originada pelo vEdge2 (dispositivo preferido para DIA) e propagada ainda mais via OMP.
Para isso, a VPN fictícia é criada no vEdge1 e um loop de porta física é executado com cabo. O loop é criado entre as portas atribuídas à VPN fictícia e a porta na VPN desejada, o que exige uma rota padrão estática. Além disso, você pode criar um loop com apenas uma interface física conectada ao switch com VLAN fictícia e duas subinterfaces atribuídas às VPNs correspondentes na figura abaixo:
Aqui você pode encontrar o exemplo de configuração do vEdge1.
1. Crie uma VPN fictícia:
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. Verifique se a rota DIA, que aponta para a interface NAT, foi adicionada com êxito à tabela de roteamento:
vedge1# show ip route vpn 50 | i nat 50 0.0.0.0/0 nat - ge0/0 - 0 - - - F,S
3. VPN de serviço usada para fins de produção, onde a rota padrão regular é configurada (qual OMP será capaz de anunciar):
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. Verifique o RIB quanto à presença da rota padrão que aponta para a interface de 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. Verifique se o vEdge1 anunciou a rota padrão via 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. O vEdge2 não exige nenhuma configuração, a rota padrão é recebida via OMP, que aponta para o 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. Confirme a acessibilidade para 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
Note: Essa solução permite organizar a redundância ou o compartilhamento de carga com diferentes saídas regionais.
Não funciona com roteadores IOS-XE
Quando a política de dados centralizada é usada para o DIA local, a maneira possível de injetar a rota padrão, ela aponta para um dispositivo regional com o DIA que é o uso dessa rota padrão estática: ip route 0.0.0.0/0 Null0.
Devido ao fluxo de pacotes internos, o tráfego que chega das filiais alcança o DIA graças à política de dados e nunca alcança a rota Null0. Como você pode ver aqui, a pesquisa do próximo salto acontece somente após uma implantação de política.
O vEdge2 tem um túnel de plano de dados estabelecido com o vEdge1 e outros sites (conectividade em estilo full-mesh). Não exige nenhuma configuração especial.
O vEdge1 tem o DIA configurado com política de dados centralizada.
Aqui você pode encontrar as etapas de configuração do vEdge1.
1. Ative a Network Address Translation (NAT) na interface de transporte, onde o DIA deve ser usado:
vpn 0 ! interface ge0/0 description "DIA interface" ip address 192.168.109.4/24 nat <<<<==== NAT activated for a local DIA !
2. Adicione a rota estática ip route 0.0.0.0/0 null0 em uma VPN de serviço para anunciar o padrão às filiais:
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. Verifique se o RIB contém a rota padrão:
vedge1# show ip route vpn 40 | include 0.0.0.0 40 0.0.0.0/0 static - - - 0 - - - B,F,S
4. Verifique se o vEdge1 anunciou a rota padrão via 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. Verifique se a política está ausente no vEdge1 e se o DIA não está habilitado:
vedge1# show policy from-vsmart % No entries found.
6. Verifique a programação da Base de Informações de Encaminhamento (FIB). Ele deve mostrar a ausência da rota (Blackhole) para o destino na Internet, pois o DIA não está ativado:
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
Configuração de política de dados centralizada vSmart para 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
Aplique a política de dados do vSmart na seção apply-policy da configuração do vSmart ou ative na GUI do vManage.
7. Verifique se o vEdge1 recebeu com êxito a política de dados do 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. Verifique a programação da Base de Informações de Encaminhamento (FIB), que mostra as possíveis rotas para o destino na 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. Confirme a acessibilidade ao destino na 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
Etapas de verificação do vEdge2:
1. Confirme se a rota padrão foi recebida e instalada com êxito no 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. Verifique a programação da Base de Informações de Encaminhamento (FIB), que mostra as possíveis rotas para o destino na 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. Confirme a acessibilidade ao destino na 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. Confirme se o DIA funciona e podemos ver a sessão Internet Control Message Protocol (ICMP) para 173.37.145.84 a partir do vEdge2 em conversões 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 -
Note: Essa solução permite organizar a redundância ou o compartilhamento de carga com diferentes saídas regionais.
Não funciona com roteadores IOS-XE
Essa solução pode ser usada para roteadores SD-WAN baseados em IOS-XE e Viptela OS.
Resumindo, nesta solução, uma rota padrão para o DIA (0.0.0.0/0 Null0) é dividida em duas sub-redes 0.0.0.0/1 e 128.0.0.0/1 apontando para Null0. Essa etapa é feita para evitar a sobreposição de uma rota padrão que deve ser anunciada às filiais e à rota padrão, usada para o DIA local. Nas rotas do IOS-XE usadas para o DIA, a distância administrativa (AD) é igual a 6, enquanto a AD do padrão estático é 1. O benefício da solução é a capacidade de usar o esquema de redundância quando o DIA regional é configurado em dois locais diferentes.
1. Ativar NAT em uma interface de transporte
2. Em um modelo de recurso para uma VPN de serviço, onde o DIA deve ser usado, adicione as seguintes rotas estáticas IPv4:
- 0.0.0.0/1 e 128.0.0.0/1 apontando para VPN. Essas rotas são usadas para o DIA
- 0.0.0.0/0 apontando para Nulo 0. Essa rota é usada para anunciar através do OMP para filiais (semelhante à da Solução 3)
3. Verifique se as rotas foram adicionadas com êxito ao 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. Verifique se o DIA funciona bem 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. Verificar se a rota padrão foi anunciada com êxito a uma filial e instalada no 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. Verifique se o DIA funciona bem 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. Verifique se a tradução NAT do roteador DIA regional foi bem-sucedida.
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
Note: Essa solução permite organizar a redundância ou o compartilhamento de carga com diferentes saídas regionais.
Note: CSCvr72329 - solicitação de aprimoramento "redistribuição de rota NAT para OMP"