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.
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.
Ce document décrit le problème qui se produit avec une conception de la redondance lorsque la sélection du chemin OMP (Overlay Management Protocol) est appliquée sur un périphérique vEdge et non sur le contrôleur vSmart qui provoque des résultats indésirables et une perte d'accessibilité au site distant en cas de défaillance de liaison, même si le chemin de sauvegarde est disponible. Ce problème est également connu sous le nom de « vSmart ne prend pas en compte l'état TLOC sur vEdge distant ».
Afin de mieux comprendre le problème, voici un schéma de topologie simple qui décrit la configuration :
Vous trouverez ici une brève description de la configuration.
Les deux sites DC (DC1 et DC2) annoncent le même réseau, 198.51.100.0/24.
Dans chaque site, vEdge apprend le routeur à partir du contrôleur de domaine via un protocole de routage dynamique, par exemple le protocole BGP (Border Gateway Protocol).
Chaque site DC étiquette le préfixe avec une métrique différente :
Sur le site DC1 vEdge set origine-metric 32
Sur le site DC2 vEdge setorigine-metric 52
nom de l'hôte | id-site | system-ip |
DC1 | 21 | 10.100.0.21 |
DC2 | 41 | 10.100.0.41 |
Siège | 100 | 10.100.0.100 |
vSmart | 100 | 10.100.0.20 |
Au moment du fonctionnement normal :
1. vSmart reçoit 198.51.100.0/24 de DC1 et DC2.
vsmart1# show omp routes 198.51.100.0/24 Code: C -> chosen I -> installed Red -> redistributed Rej -> rejected L -> looped R -> resolved S -> stale Ext -> extranet Inv -> invalid Stg -> staged U -> TLOC unresolved PATH ATTRIBUTE VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE -------------------------------------------------------------------------------------------------------------------------------------- 3 198.51.100.0/24 10.100.0.21 36 1003 C,R installed 10.100.0.21 biz-internet ipsec - <===== METRIC 32 (PREFERRED) 10.100.0.21 49 1003 C,R installed 10.100.0.21 private1 ipsec - <===== METRIC 32 (PREFERRED) 10.100.0.41 36 1003 R installed 10.100.0.41 biz-internet ipsec - <===== METRIC 52 10.100.0.41 49 1003 R installed 10.100.0.41 private1 ipsec - <===== METRIC 52
2. vSmart annonce à HQ la route avec la destination DC1 (via private1 et biz-internet), car elle a la métrique d'origine la plus faible selon les critères de sélection de route OMP.
vsmart1# show omp routes 198.51.100.0/24 vpn 3 detail --------------------------------------------------- omp route entries for vpn 3 route 198.51.100.0/24 --------------------------------------------------- RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "biz-internet" color peer 10.100.0.21 path-id 36 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "private1" color peer 10.100.0.21 path-id 49 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "biz-internet" color peer 10.100.0.41 path-id 36 label 1003 status R loss-reason origin-metric lost-to-peer 10.100.0.21 lost-to-path-id 49 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "private1" color peer 10.100.0.41 path-id 49 label 1003 status R loss-reason tloc-id lost-to-peer 10.100.0.41 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set ADVERTISED TO: <================= WE ADVERTISE TO HQ vEdge ONLY BEST ROUTES WITH METRIC 32 peer 10.100.0.100 Attributes: originator 10.100.0.21 label 1003 path-id 4410 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set Attributes: originator 10.100.0.21 label 1003 path-id 4439 tloc 10.100.0.21, private1, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set
3. HQ vEdge marque la route avec TLOC "biz-internet" comme "Inv,U" parce que ce vEdge n'a pas TLOC biz-internet.
4. HQ vEdge marque la route avec TLOC "private1" comme "C, I, R" et installe la route.
Scénario de défaillance DC1 :
1. Dans le scénario d'échec, la liaison ascendante vEdge de DC1 en couleur "private1" échoue (l'interface est désactivée) tandis que "biz-internet" reste active.
2. vSmart reçoit 198.51.100.0/24 de DC1 (accessible uniquement via biz-internet) et DC2 (biz-internet et private1).
3. vSmart annonce les routes vEdge de HQ vers DC1 (via biz-internet) car DC1 a la métrique la plus faible.
vsmart1# show omp routes 198.51.100.0/24 detail --------------------------------------------------- omp route entries for vpn 3 route 198.51.100.0/24 --------------------------------------------------- RECEIVED FROM: peer 10.100.0.21 path-id 36 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: peer 10.100.0.41 path-id 36 label 1003 status R loss-reason origin-metric lost-to-peer 10.100.0.21 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set RECEIVED FROM: peer 10.100.0.41 path-id 49 label 1003 status R loss-reason tloc-id lost-to-peer 10.100.0.41 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set ADVERTISED TO: peer 10.100.0.31 Attributes: originator 10.100.0.21 label 1003 path-id 5906 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set ADVERTISED TO: peer 10.100.0.41 Attributes: originator 10.100.0.21 label 1003 path-id 7689 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set ADVERTISED TO: <===== THIS IS WHAT WE ADVERTISE TO HQ SITE peer 10.100.0.100 Attributes: originator 10.100.0.21 label 1003 path-id 4410 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set
4. HQ vEdge marque la route avec TLOC « biz-internet » comme "Inv,U" parce que ce vEdge n'a pas TLOC biz-internet.
Par conséquent, HQ vEdge ne peut pas atteindre 198.51.100.0/24.
vSmart aurait pu envoyer les routes vers DC2 (avec une métrique moins élevée) et dans ce cas HQ vEdge atteindrait toujours la destination avec l'utilisation du TLOC « private1 » via DC2, qui est toujours actif :
VEDGE-HQ-1# show bfd sessions site-id 41 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 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 10.100.0.41 41 up private1 private1 192.168.11.1 192.168.41.1 12406 ipsec 7 1000 12:04:02:25 0
Mais il n'y a aucune route via "private1" TLOC via DC2 sur HQ vEdge installée car vSmart a déjà sélectionné une route biz-internet avec une métrique inférieure comme meilleur chemin. vSmart n'annonce pas les routes OMP avec différentes métriques par défaut, ce qui empêche le périphérique vEdge récepteur de décider quel chemin prendre (et de prendre en compte les TLOC disponibles et ses états). vSmart ne prend pas en compte les couleurs TLOC disponibles sur le périphérique distant (HQ vEdge dans notre cas) auquel vous annoncez la route et ne prend pas en compte son état car il n'existe aucun mécanisme de ce type pour contrôler cette route.
Il s'agit du boîtier d'angle OMP qui peut être vu dans une topologie similaire avec un réflecteur de route iBGP et l'appairage sur les adresses d'interfaces physiques.
La première solution consiste à utiliser la fonctionnalité add path like (RFC7911) disponible dans OMP et appelée « send-backup-paths » sur vSmart :
omp send-backup-paths
Il annonce tous les chemins disponibles, de sorte que HQ vEdge distant choisit le chemin en fonction de la disponibilité TLOC.
La deuxième solution consiste à supprimer l'action de stratégie de routage « set metric » pour le préfixe correspondant sur les contours DC1 et DC2, puis à appliquer la sélection centralisée de route via la stratégie de contrôle vSmart, comme illustré ici par exemple :
policy
lists
site-list site_11
site-id 11
!
prefix-list PREFIX
ip-prefix 198.51.100.0/24
!
control-policy SET_PREF
sequence 10
match route
prefix-list PREFIX
site-id 21
!
action accept
set
preference 200
!
!
!
sequence 20
match route
prefix-list PREFIX
site-id 41
!
action accept
set
preference 100
!
!
!
default-action accept
!
apply-policy
site-list site_11
control-policy SET_PREF out
!
Ici, l'id de site 11 est HQ vEdge et la liste de préfixes PREFIX contient des préfixes que vous souhaitez privilégier par rapport à une couleur TLOC ou une autre. Puisque les deux routes OMP sont sur HQ vEdge, une fois que vEdge ne peut plus accéder à biz-internet, il installera une route via private1 dans la base d'informations de routage (RIB) à partir de sa table de routes OMP.