El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe la aplicación inapropiada de la política de la acción set tloc-list que conduce a la negligencia del tráfico en ciertas situaciones cuando el link preferido deja de funcionar pero las trayectorias de respaldo siguen disponibles.
Nota: Todos los resultados de comandos presentados en este documento provienen de routers vEdge. Sin embargo, el enfoque de solución de problemas sigue siendo el mismo para un router que ejecuta el software SDWAN IOS®-XE. Utilice la palabra clave sdwan para obtener los mismos resultados en el software SDWAN IOS®-XE. Por ejemplo, show sdwan omp routes en lugar de show omp routes.
A efectos de demostración y para entender mejor el problema descrito más adelante, considere este diagrama de topología:
Además, esta es la tabla que resume la configuración del sistema:
nombre del host | id del sitio | system-ip |
vedge1 | 13 | 10.155.0.118 |
vedge3 | 13 | 10.155.0.120 |
vedge4 | 4 | 10.155.0.50 |
vsmart1 | 1 | 10.155.0.3 |
Tanto vEdge1 como vEdge3 tienen una ruta estática configurada que apunta a algún salto siguiente en la VPN del lado del servicio:
vpn 40 ip route 10.223.115.101/32 192.168.40.10 !
Para alcanzar estos objetivos:
1. Convertir el enlace metro-ethernet vEdge1 en el enlace preferido para el tráfico de entrada que entra en el "sitio 13".
2. MConvierta el enlace metro-ethernet vEdge3 en el segundo enlace preferido para el tráfico de entrada que entra en el "sitio 13".
3. Convertir el enlace de Internet público vEdge1 en el tercer enlace preferido para el tráfico de entrada que entra en el "sitio 13".
4. Convierta el enlace de Internet público vEdge3 en el enlace menos preferido para el tráfico de entrada que entra en el "sitio 13".
Esta política de control vSmart está configurada:
policy lists tloc-list SITE13_TLOC_PREF tloc 10.155.0.118 color metro-ethernet encap ipsec preference 200 tloc 10.155.0.118 color public-internet encap ipsec preference 100 tloc 10.155.0.120 color metro-ethernet encap ipsec preference 150 tloc 10.155.0.120 color public-internet encap ipsec preference 50 ! prefix-list SITE13_PREFIX ip-prefix 10.223.115.101/32 ! site-list site13 site-id 13 ! control-policy TE_POLICY_2_SITE4 sequence 10 match route prefix-list SITE13_PREFIX ! action accept set tloc-list SITE13_TLOC_PREF ! ! ! default-action accept ! ! apply-policy site-list site4 control-policy TE_POLICY_2_SITE4 out ! !
vSmart obtiene estas rutas con 4 TLOC posibles como saltos siguientes:
vsmart1# show omp routes 10.223.115.101/32 | b PATH PATH ATTRIBUTE VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE -------------------------------------------------------------------------------------------------------------------------------------- 40 10.223.115.101/32 10.155.0.118 35 1002 C,R installed 10.155.0.118 metro-ethernet ipsec - 10.155.0.118 37 1002 C,R installed 10.155.0.118 public-internet ipsec - 10.155.0.120 35 1002 C,R installed 10.155.0.120 metro-ethernet ipsec - 10.155.0.120 37 1002 C,R installed 10.155.0.120 public-internet ipsec -
Y establece una preferencia para las rutas anunciadas en consecuencia:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference Attributes: originator 10.155.0.118 tloc 10.155.0.120, public-internet, ipsec preference 50 Attributes: originator 10.155.0.118 tloc 10.155.0.120, metro-ethernet, ipsec preference 150 Attributes: originator 10.155.0.118 tloc 10.155.0.118, public-internet, ipsec preference 100 Attributes: originator 10.155.0.118 tloc 10.155.0.118, metro-ethernet, ipsec preference 200
vEdge4 selecciona un TLOC adecuado e instala esta ruta en la tabla de ruteo:
vedge4# show ip routes 10.223.115.101/32 | b PROTOCOL PROTOCOL NEXTHOP NEXTHOP NEXTHOP VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS --------------------------------------------------------------------------------------------------------------------------------------------- 40 10.223.115.101/32 omp - - - - 10.155.0.118 metro-ethernet ipsec F,S
El reenvío de tráfico funciona según lo previsto:
vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 192.168.40.4 (192.168.40.4) 0.835 ms 0.984 ms 1.097 ms 2 192.168.40.10 (192.168.40.10) 2.955 ms 3.056 ms 3.218 ms
Finalmente, se produce un error en vEdge1 y la interfaz de cara a la LAN del lado del servicio se desactiva (o el administrador la apaga para realizar una prueba; por ejemplo, el resultado será el mismo):
vedge1# show interface vpn 40 IF IF IF TCP AF ADMIN OPER TRACKER ENCAP PORT SPEED MSS RX TX VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS ---------------------------------------------------------------------------------------------------------------------------------------------------------- 40 ge0/4 ipv4 192.168.40.4/24 Up Down NA null service 1500 00:50:56:be:91:36 - - 1420 - 129768 0
Como vEdge1 no tiene un salto siguiente válido para la ruta 10.223.115.101/32, esta ruta se elimina de las tablas de routing y reenvío y ya no se anuncia a vSmart:
vedge1# show ip routes 10.223.115.101/32 | b PROTO PROTOCOL NEXTHOP NEXTHOP NEXTHOP VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS --------------------------------------------------------------------------------------------------------------------------------------------- 40 10.223.115.101/32 static - - 192.168.40.21 - - - - I vedge1# show ip fib vpn 40 | i 10.223.115.101/32 vedge1# vedge1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED vedge1#
Al mismo tiempo, vEdge3 sigue anunciando esta ruta (se espera):
vedge3# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED ADVERTISED TO: peer 10.155.0.3 Attributes: originator 10.155.0.120 label 1002 path-id 35 tloc 10.155.0.120, metro-ethernet, ipsec ultimate-tloc not set domain-id not set site-id 13 overlay-id 1 preference not set tag not set origin-proto static origin-metric 0 as-path not set unknown-attr-len not set Attributes: originator 10.155.0.120 label 1002 path-id 37 tloc 10.155.0.120, public-internet, ipsec ultimate-tloc not set domain-id not set site-id 13 overlay-id 1 preference not set tag not set origin-proto static origin-metric 0 as-path not set unknown-attr-len not set
vSmart obtiene 2 rutas ahora desde vEdge3 como se esperaba:
vsmart1# show omp routes 10.223.115.101/32 | b PATH PATH ATTRIBUTE VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE -------------------------------------------------------------------------------------------------------------------------------------- 40 10.223.115.101/32 10.155.0.120 35 1002 C,R installed 10.155.0.120 metro-ethernet ipsec - 10.155.0.120 37 1002 C,R installed 10.155.0.120 public-internet ipsec -
Pero, al mismo tiempo, vSmart continúa anunciando lo siguiente:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference Attributes: originator 10.155.0.120 tloc 10.155.0.120, public-internet, ipsec preference 50 Attributes: originator 10.155.0.120 tloc 10.155.0.120, metro-ethernet, ipsec preference 150 Attributes: originator 10.155.0.120 tloc 10.155.0.118, public-internet, ipsec preference 100 Attributes: originator 10.155.0.120 tloc 10.155.0.118, metro-ethernet, ipsec preference 200
Como puede ver, el único originador fue cambiado y este es el comportamiento esperado porque la acción tloc-list actúa de manera similar a (hablando a grandes rasgos) "set next-hop" y establece con fuerza el TLOC incorrecto, por lo tanto se pierde la disponibilidad.
vedge4# ping vpn 40 10.223.115.101 count 5 Ping in VPN 40 PING 10.223.115.101 (10.223.115.101) 56(84) bytes of data. ^C --- 10.223.115.101 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * *
Como solución, se propone este enfoque para evitar establecer la información de siguiente salto TLOC incorrecta:
policy lists tloc-list vedge1-tlocs tloc 10.155.0.118 color metro-ethernet encap ipsec tloc 10.155.0.118 color public-internet encap ipsec ! tloc-list vedge1-tlocs-preference tloc 10.155.0.118 color metro-ethernet encap ipsec preference 200 tloc 10.155.0.118 color public-internet encap ipsec preference 100 ! tloc-list vedge3-tlocs tloc 10.155.0.120 color metro-ethernet encap ipsec tloc 10.155.0.120 color public-internet encap ipsec ! tloc-list vedge3-tlocs-preference tloc 10.155.0.120 color metro-ethernet encap ipsec preference 150 tloc 10.155.0.120 color public-internet encap ipsec preference 50 ! ! ! policy control-policy TE_POLICY_2_SITE4 sequence 10 match route prefix-list SITE13_PREFIX tloc-list vedge1-tlocs ! action accept set tloc-list vedge1-tlocs-preference ! ! ! sequence 20 match route prefix-list SITE13_PREFIX tloc-list vedge3-tlocs ! action accept set tloc-list vedge3-tlocs-preference ! ! ! default-action accept ! !
Esta política mejora la situación e impide el anuncio de la ruta con el siguiente salto TLOC incorrecto:
vsmart1# show omp routes 10.223.115.101/32 detail | nomore | b ADVERTISED | b "peer 10.155.0.50" | i Attributes\|originator\|\ tloc\|preference Attributes: originator 10.155.0.120 tloc 10.155.0.120, public-internet, ipsec preference 50 Attributes: originator 10.155.0.120 tloc 10.155.0.120, metro-ethernet, ipsec preference 150 Attributes: originator 10.155.0.120 tloc 10.155.0.120, public-internet, ipsec preference not set
Y, como resultado, se conserva la accesibilidad en todos los escenarios de fallos:
vedge4# traceroute vpn 40 10.223.115.101 Traceroute 10.223.115.101 in VPN 40 traceroute to 10.223.115.101 (10.223.115.101), 30 hops max, 60 byte packets 1 192.168.40.6 (192.168.40.6) 0.458 ms 0.507 ms 0.617 ms 2 192.168.40.10 (192.168.40.10) 1.928 ms 1.976 ms 2.069 ms vedge4# ping vpn 40 10.223.115.101 Ping in VPN 40 PING 10.223.115.101 (10.223.115.101) 56(84) bytes of data. 64 bytes from 10.223.115.101: icmp_seq=1 ttl=254 time=0.702 ms 64 bytes from 10.223.115.101: icmp_seq=2 ttl=254 time=0.645 ms 64 bytes from 10.223.115.101: icmp_seq=3 ttl=254 time=0.691 ms 64 bytes from 10.223.115.101: icmp_seq=4 ttl=254 time=0.715 ms 64 bytes from 10.223.115.101: icmp_seq=5 ttl=254 time=0.603 ms ^C --- 10.223.115.101 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 0.603/0.671/0.715/0.044 ms
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
10-Jun-2019 |
Versión inicial |