Contenido

Introducción

Antecedentes

Problema

Condiciones normales

Condiciones de fallo

Solución

Introducción

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.

Antecedentes

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

!

!

Problema

Condiciones normales

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

Condiciones de fallo

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  * * *

Solución

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