Sommario

Introduzione

Premesse

Problema

Condizioni normali

Condizioni di errore

Soluzione

Introduzione

Questo documento descrive l'applicazione di policy non appropriata dell'azione set tloc-list che porta a blocchi del traffico in alcune situazioni in cui il collegamento preferito non è attivo ma i percorsi di backup sono ancora disponibili.

Nota: Tutti gli output dei comandi presentati in questo documento provengono da router vEdge. Tuttavia, l'approccio alla risoluzione dei problemi rimane lo stesso per un router con software IOS®-XE SDWAN. Usare la parola chiave sdwan per ottenere gli stessi output sul software IOS®-XE SDWAN. Ad esempio, visualizzare le route omp sdwan anziché visualizzare le route omp.

Premesse

Per una dimostrazione e per comprendere meglio il problema descritto più avanti, considerare il seguente diagramma topologico:

Inoltre, la tabella che riepiloga le impostazioni di sistema è la seguente:

hostname

id-sito

ip-sistema

vedge1

13

10.155.0.118

vedge3

13

10.155.0.120

vedge4

4

10.155.0.50

vsmart1

1

10.155.0.3

Sia vEdge1 che vEdge3 dispongono di una route statica configurata che punta a un hop successivo nella VPN sul lato servizio:

vpn 40

ip route 10.223.115.101/32 192.168.40.10

!

Per conseguire tali obiettivi:

1. Impostare il collegamento metro-ethernet vEdge1 come collegamento preferito per il traffico in entrata che entra nel "sito 13".

2. MRende il collegamento metro-ethernet vEdge3 il secondo collegamento preferito per il traffico in entrata che entra nel "sito 13".

3. Rendere vEdge1 public-internet link come terzo collegamento preferito per il traffico in entrata che entra nel "sito 13".

4. Rendere il collegamento Internet pubblico vEdge3 il collegamento meno preferito per il traffico in entrata nel "sito 13".

I criteri di controllo vSmart sono configurati:

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

Condizioni normali

vSmart ottiene queste route con 4 possibili TLOC come hop successivi:

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  -

E imposta una preferenza per le route annunciate di conseguenza:

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 seleziona un valore TLOC appropriato e installa la route nella tabella di routing:

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

L'inoltro del traffico funziona come 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

Condizioni di errore

Alla fine, si verifica un errore su vEdge1 e l'interfaccia di connessione LAN sul lato servizio non funziona (o viene chiusa dall'amministratore per eseguire un test, ad esempio, il risultato sarà lo stesso):

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

Poiché vEdge1 non dispone di un hop successivo valido per la route 10.223.115.101/32, questa route viene rimossa dalle tabelle di routing e inoltro e non viene più annunciata 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#

Allo stesso tempo, vEdge3 annuncia ancora questa route (prevista):

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 ottiene 2 route da vEdge3 come previsto:

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  -

Allo stesso tempo, vSmart continua a pubblicizzare questo:

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

Come si può vedere, l'unico originatore è stato cambiato e questo è il comportamento previsto perché l'azione tloc-list agisce in modo simile (più o meno) a "set next-hop" e imposta forzatamente il TLOC sbagliato, quindi la raggiungibilità viene persa.

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

Soluzione

Per risolvere questo problema, viene proposto un approccio di questo tipo per evitare di impostare le informazioni dell'hop successivo del TLOC errate:

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

!

!

Tale politica migliora la situazione e impedisce la pubblicità della rotta con l'hop successivo TLOC sbagliato:

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

Di conseguenza, viene preservata la raggiungibilità in tutti gli scenari di errore:

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