Dépannage d'une défaillance OMP et de TLOC-Action

Introduction

Ce document décrit le dépannage des scénarios de défaillance du protocole OMP (Overlay Management Protocol) et les meilleures pratiques pour assurer la résilience du réseau dans Cisco SD-WAN.

Conditions préalables

Exigences

Cisco vous recommande de connaître la solution SD-WAN (Software Defined Wide Area Network) de Cisco.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Cisco IOS Catalyst SD-WAN Manager alias vManage
• Cisco IOS Catalyst SD-WAN Validator aka vBond
• Contrôleur SD-WAN Cisco IOS Catalyst alias vSmart
• Périphériques vEdge

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est actif, assurez-vous de comprendre l'impact potentiel de toute commande.

Présentation d'OMP

Comme vous le savez, le périphérique Cisco SD-WAN Edge partage uniquement les routes avec le contrôleur Catalyst SD-WAN. Pour qu’une route soit valide et installée dans sa table de transfert :

• Le localisateur de transport du tronçon suivant (TLOC) doit être accessible, c'est-à-dire que le périphérique Edge doit avoir une route valide pour le TLOC.
• Le TLOC vers lequel il pointe est actif. Pour qu'une TLOC soit active, une session de transfert bidirectionnel (BFD) active doit être associée à cette TLOC. Les sessions BFD sont établies par chaque périphérique, ce qui crée une session BFD distincte avec chaque TLOC distant. Si une session BFD devient inactive, le contrôleur Cisco Catalyst SD-WAN supprime de la table de transfert toutes les routes OMP qui pointent vers ce TLOC.
• La route OMP doit être calculée comme étant la meilleure route.

Bien que toutes ces instructions soient logiques et simples, il existe une différence significative entre OMP et les protocoles de routage traditionnels tels que EIGRP (Enhanced Interior Gateway Routing Protocol) et OSPF (Open Shortest Path First) lors de scénarios de défaillance.

Scénario d'échec EIGRP

Dans le réseau suivant, il y a trois sites, à savoir Site1, Site3 et Site4, ayant des routeurs RTR1/RTR2, RTR3 et RTR4 respectivement avec une seule connexion WAN. Le protocole de routage traditionnel EIGRP est exécuté sur IPSec et IP1, IP2, IP3 et IP4 sont les adresses IP de l'interface WAN dans les emplacements respectifs.

Le réseau doit être décomposé, en mettant l’accent sur les routeurs RTR3 et RTR4 pour l’instant. Sur RTR3, la route pour atteindre le réseau 10.1.4.0/24 passe par un tunnel direct entre RTR3 et RTR4. Si le tunnel tombe en panne, comment le protocole EIGRP réagit-il dans ce cas ? Dès que le tunnel est désactivé, le protocole EIGRP s’exécute et envoie une requête aux routeurs voisins pour le réseau 10.1.4.0/24. En fonction des réponses reçues, il l’examine et installe le nouveau chemin pour la destination dans la table de routage après le meilleur calcul de chemin.

Il s’agit d’une explication très simple du processus de convergence du protocole de routage traditionnel. Ainsi, les protocoles de routage traditionnels tels que le protocole EIGRP sont capables d’effectuer un recalcul du réseau :

• Lorsque la route actuelle vers une destination tombe en panne
• Lorsqu'il n'existe aucun successeur potentiel pour une destination
• En cas de modification de la topologie

Scénario d'échec OMP

Les deux scénarios de défaillance pour OMP sont traités ici :

1. Défaillance Directe
2. Défaillance Indirecte

Défaillance Directe

Dans la topologie suivante, il y a trois sites avec une seule connexion de transport.

Supposons que tout est défini sur la valeur par défaut sur le contrôleur SD-WAN Catalyst. Les périphériques vEdge partagent les informations de routage directement avec le contrôleur Catalyst SD-WAN et le contrôleur les partage avec tous les périphériques vEdge. La topologie suivante présente la table de routage de tous les routeurs :

Actuellement, toutes les sessions BFD sont actives.

vEdge-DC1# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME          TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls             60.1.1.1                        20.1.1.1                        12346       ipsec  7           1000           0:00:03:12      0
2.2.2.2                 1        up          mpls             mpls             60.1.1.1                        10.10.20.2                    12406       ipsec  7           1000           0:06:28:51      0
4.4.4.4                 2        up          mpls             mpls             60.1.1.1                        30.1.1.1                        12386       ipsec  7           1000           0:00:00:51      0
                    

vEdge-DC1# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
20     10.1.1.0/24        2.2.2.2          43     1005        C,I,R          installed      1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R            installed     2.2.2.2                  mpls                           ipsec  -
20     10.1.3.0/24        0.0.0.0          66     1005     C,Red,R        installed      3.3.3.3                  mpls                           ipsec  -
20     10.1.4.0/24        2.2.2.2          45     1006         C,I,R          installed       4.4.4.4                 mpls                           ipsec  - 

Si la connectivité entre vEdge3 et vEdge4 est désactivée, lorsque le tunnel est désactivé, les sessions BFD de vEdge3 et vEdge4 sont également désactivées. Cela les amène à marquer les routes respectives comme 'Non valide' et 'TLOC non résolu'. Vous pouvez le voir dans la sortie suivante :

vEdge3# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX           
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME           
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls                     60.1.1.1                         20.1.1.1                      12386       ipsec          7                    1000                0:05:57:27                         
2.2.2.2                 1        up          mpls             mpls                     60.1.1.1                         10.10.20.2                  12426       ipsec           7                   1000               0:05:57:27                         
4.4.4.4                 4        down     mpls             mpls                     60.1.1.1                         30.1.1.1                      12406       ipsec          7                    1000                 NA                                     



vEdge3# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1     10.1.1.0/24          2.2.2.2          43     1005        C,I,R                installed       1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R                installed       2.2.2.2                  mpls                          ipsec  -
1    10.1.3.0/24           0.0.0.0          66     1005        C,Red,R           installed       3.3.3.3                 mpls                           ipsec  -
1     10.1.4.0/24          2.2.2.2          45     1006        Inv,U                installed       4.4.4.4                 mpls                           ipsec  - 

Défaillance Indirecte

Afin de comprendre « Indirect Failure », supposons que la stratégie de contrôle est définie pour changer le tronçon suivant sur vEdge3 pour la route 10.1.4.0/24 via vEdge2, et sur vEdge4 le tronçon suivant pour 10.1.3.0/24 est changé en vEdge1. En d'autres termes, pour le trafic entre vEdge 3 et 4, vEdge 2 et 1 ont été insérés en tant que tronçons intermédiaires. Vous pouvez le voir dans le schéma suivant :

En cas de défaillance du réseau entraînant une perte de connectivité entre vEdge2 et vEdge4, alors que le tunnel de superposition entre T2 et T4 est en panne, vEdge3 dispose toujours d'une route valide pour 10.1.4.0 via T2. Il envoie donc le trafic vers vEdge2. vEdge2 ne dispose pas d'un tunnel valide avec vEdge4, de sorte que les routes ne seront plus actives sur celui-ci, abandonnant ainsi le trafic.

Sur la base des journaux et des tests précédents, on peut conclure que :

• Avec OMP, il n'y a pas de détection automatique des homologues de routage et des tronçons suivants 
• Il n'y a pas de recalcul de topologie quand un tunnel tombe en panne
• Les routes OMP vers un préfixe de destination ne changent jamais lorsqu'un tunnel tombe en panne. Le seul changement qui se produit est l'accessibilité au tronçon suivant, c'est-à-dire le TLOC.
• En cas de défaillance de la superposition directe, une redondance de tunnel avec plusieurs tunnels vers la même destination doit être fournie.
• Il convient de faire preuve d’une plus grande prudence lors de l’introduction de sauts intermédiaires dans le chemin de superposition et de fournir une redondance de tunnel afin d’éviter le trou d’absence du trafic.

Maintenant, vous savez que par défaut, OMP ne recalcule pas ou ne réachemine pas en cas d'échec de la superposition. Afin de surmonter ce problème, vous pouvez activer une fonctionnalité appelée 'TLOC-Action' via une politique de contrôle.

Action TLOC

• Dans Cisco SD-WAN, une « action TLOC » au sein d'une stratégie de contrôle permet l'insertion d'un saut intermédiaire (TLOC) à utiliser pour le transfert du trafic tout en conservant une visibilité sur le chemin complet de la source à la destination. Cela signifie que la définition de l'option d'action TLOC permet au contrôleur SD-WAN Cisco Catalyst d'effectuer un suivi de bout en bout du chemin vers le périphérique de destination ultime. Si ce chemin tombe en panne, le contrôleur en informe les routeurs de périphérie WAN qui ont reçu cette route OMP.
• Il fournit un chemin de secours en cas de défaillance de la liaison principale, améliorant ainsi la résilience du réseau et la tolérance aux pannes au sein du réseau de superposition SD-WAN. C'est un moyen de contrôler la façon dont le trafic est acheminé sur le réseau en manipulant les TLOC utilisés pour atteindre une destination.
• Lorsqu'une action TLOC est définie dans une stratégie, elle demande au contrôleur SD-WAN d'insérer une action TLOC intermédiaire dans le calcul de la route, ce qui signifie que le trafic ira d'abord à cet emplacement de « secours » spécifié avant d'atteindre la destination finale si nécessaire.
• Cela est particulièrement utile dans les scénarios où vous voulez assurer la connectivité même si une liaison principale tombe en panne, en réacheminant automatiquement le trafic via un chemin différent (via le TLOC spécifié).

Dans la topologie suivante, concentrons-nous sur vEdge2, vEdge3 et vEdge4 pour mieux le comprendre. Actuellement, aucune stratégie n'est définie et le trafic de données pour 10.1.4.0/24 sur vEdge3 traverse un tunnel direct entre T3 et T4.

Afin d'assurer la tolérance aux pannes et la résilience du réseau, la stratégie de contrôle est configurée pour réacheminer le trafic par un chemin différent (via le TLOC spécifié).

• vEdge4 envoie une mise à jour OMP pour son réseau connecté directement 10.1.4.0/24 avec le tronçon suivant T4 au contrôleur Catalyst SD-WAN sous la forme « 10.1.4.0/24 via T4 ».
• Cette route correspond à une stratégie de contrôle configurée sur le contrôleur SD-WAN et définit un nouveau TLOC et des actions TLOC selon la stratégie définie sur celui-ci, c'est-à-dire qu'elle insère le nouveau 'TLOC intermédiaire'.
• Le contrôleur annonce la route OMP vers vEdge1 avec désormais deux tronçons suivants : TLOC intermédiaire (T3, 3.3.3.3) et TLOC final (tronçon suivant T4 de la route d'origine). Cela indique à vEdge1 que le préfixe de destination 10.1.4.0/24 est accessible via T2 et T4.

Désormais, en fonction de l'action TLOC définie, vEdge1 transfère le trafic pour 10.1.4.0/24. Vous pouvez donc définir ces quatre types d'actions TLOC dans la politique du plan de contrôle :

1. Strict (par défaut) : le paramètre 'TLOC-Action strict' définit que le trafic entre vEdge1 et vEdge4 doit passer par T3 (saut intermédiaire) et que le trafic doit être abandonné si le tunnel entre vEdge1 et vEdge4 tombe en panne.
2. Principal - Le « TLOC-Action primary » définit que le trafic entre vEdge1 et vEdge4 passe par le saut intermédiaire T3 (3.3.3.3) et si ce tunnel de superposition tombe en panne, le contrôleur SD-WAN en informe vEdge1 et le trafic routé sur le tunnel direct vers T4.
3. Sauvegarde - La « sauvegarde TLOC-Action » définit que le trafic entre vEdge1 et vEdge4 passe directement au LOC ultime (tronçon suivant -T4 de la route d'origine) et si le tunnel de superposition directe entre vEdge1 et vEdge4 tombe en panne, le contrôleur SD-WAN en informe vEdge1 et le trafic passe par le tronçon intermédiaire T3.
4. Equal-Cost Multi-Path (ECMP) - Le « TLOC-Action ECMP » spécifie que, dans des circonstances normales, la communication entre vEdge1 et vEdge4 est équilibrée en charge via le saut intermédiaire T3 et le saut final T4.