L'utilisation inappropriée de « policy action set tloc-list » entraîne une coupure du trafic

Options de téléchargement

  • PDF     (409.1 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (261.1 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (150.4 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:10 juin 2019
ID du document:214502

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit l'application de stratégie inappropriée de l'action set tloc-list qui conduit à une coupure de trafic dans certaines situations quand la liaison préférée tombe en panne mais que des chemins de sauvegarde sont toujours disponibles.

    Note: Toutes les sorties de commande présentées dans ce document proviennent de routeurs vEdge. Cependant, l'approche de dépannage reste la même pour un routeur qui exécute le logiciel SDWAN IOS®-XE. Utilisez le mot clé sdwan afin d'obtenir les mêmes résultats sur le logiciel IOS®-XE SDWAN. Par exemple, show sdwan omp routes au lieu de show omp routes.

    Informations générales

    Pour les besoins de la démonstration et afin de mieux comprendre le problème décrit plus loin, considérez ce schéma de topologie :

    En outre, voici le tableau qui résume les paramètres système :

    nom de l'hôte site-id system-ip
    bord1 13 10.155.0.118
    verge3 13 10.155.0.120
    verge4 4 10.155.0.50
    vsmart1 1  10.155.0.3

      

    vEdge1 et vEdge3 ont tous deux une route statique configurée qui pointe vers un tronçon suivant dans le VPN côté service :

    vpn 40
 ip route 10.223.115.101/32 192.168.40.10
!

    Pour atteindre ces objectifs : 

    1. Faites de la liaison metro-ethernet vEdge1 la liaison préférée pour le trafic entrant sur le « site 13 ».

    2. MFaites de la liaison metro-ethernet vEdge3 la deuxième liaison préférée pour le trafic entrant sur le « site 13 ».

    3. Faites de la liaison Internet publique vEdge1 la troisième liaison préférée pour le trafic entrant sur le « site 13 ».

    4. Faites de la liaison publique-Internet vEdge3 la liaison la moins préférée pour le trafic entrant sur le « site 13 ».

    Cette stratégie de contrôle vSmart est configurée :

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

    Problème

    Conditions normales

    vSmart obtient ces routes avec 4 TLOC possibles comme tronçons suivants :

    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  -

    Et définit une préférence pour les routes annoncées en conséquence :

    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 sélectionne un TLOC approprié et installe cette route dans la table de routage :

    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

    Le transfert de trafic fonctionne comme prévu :

    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

    Conditions de panne

    Finalement, une panne se produit sur vEdge1 et l'interface orientée LAN côté service s'arrête (ou est arrêtée par l'administrateur afin d'effectuer un test, par exemple, le résultat sera le même) :

      

    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

    Étant donné que vEdge1 ne dispose pas d'un tronçon suivant valide pour la route 10.223.115.101/32, cette route est supprimée des tables de routage et de transfert et ne l'annonce plus à 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#

    Parallèlement, vEdge3 annonce toujours cette route (ce qui est attendu) :

    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 obtient maintenant 2 routes de vEdge3 comme prévu :

    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  -

    Mais dans le même temps, vSmart continue à faire la publicité suivante :

    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

    Comme vous pouvez le voir, le seul expéditeur a été changé et c'est le comportement attendu parce que l'action tloc-list agit de façon similaire à (en gros) "set next-hop" et définit de force le mauvais TLOC, donc l'accessibilité est perdue.

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

    Solution

    En guise de solution, cette approche est proposée afin d'éviter de définir des informations de tronçon suivant TLOC erronées :

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

    Une telle politique améliore la situation et empêche l'annonce de la route avec le saut suivant TLOC incorrect :

    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

    Par conséquent, l'accessibilité est préservée tout au long des scénarios de défaillance :

    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

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    10-Jun-2019
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Eugene Khabarov
      Ingénieur TAC Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits