Résoudre la boucle de routage BGP-OMP lorsque le routage BGP et SoO sont utilisés

Options de téléchargement

  • PDF     (653.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (500.3 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (307.5 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:17 mai 2024
ID du document:215992

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 comment éviter une boucle de routage dans le fabric SD-WAN lorsque le routage BGP (Border Gateway Protocol) et le SoO (Site of Origin) sont utilisés.

    Conditions préalables

    Exigences

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • Compréhension de base du protocole OMP (Overlay Management Protocol)
    • Compréhension de base du protocole BGP
    • Composants SD-WAN et interaction entre eux

    Composants utilisés

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

    • 3 routeurs Cisco IOS® XE CSR1000v avec la version logicielle 17.2.1v qui fonctionnent en mode contrôleur (SD-WAN)
    • 2 routeurs Cisco IOS XE CSR1000v avec la version logicielle 16.7.3

    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 en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Informations générales

    Pour les besoins de ce document, cette topologie est utilisée :

    Topologie de démonstrationTopologie

    R1 et R2 sont des routeurs Cisco IOS XE génériques (ou tout autre routeur capable d'exécuter BGPv4). cE1, cE2 et cE3 exécutent Cisco IOS XE en mode contrôleur (SD-WAN). Vous trouverez ici un résumé des paramètres site-id et system-ip attribués à chaque routeur SD-WAN :

    Routeur SD-WAN

    site-id

    system-ip
    cE1 214 192.168.30.214
    cE2 215 192.168.30.215
    cE3 216 192.168.30.216

    Voici un ensemble d'événements qui se sont déroulés au départ :

    1. R1 et R2 établissent l'appairage eBGP de manière correspondante avec cE1, cE2 et cE3. cE1 et cE2 établissent l'appairage iBGP.
    2. R2 crée la route BGP 10.1.1.0/24 et l'annonce via eBGP à cE3.
    3. cE3 reçoit cette route BGP côté service dans la famille d'adresses VRF 1, puis redistribue cette route dans OMP.
    4. cE3 annonce la route OMP 10.1.1.0/24 à la superposition SD-WAN (les contrôleurs vSmart sont responsables de la diffusion des informations de routage via le protocole OMP vers tous les autres routeurs Edge associés à la superposition SD-WAN).
    5. cE1 et cE2 reçoivent la route OMP et la redistribuent via eBGP dans VRF 1 vers R1.

    Configuration

    Voici la configuration appropriée de cE1. Notez que n' send-comminity est pas configuré pour le voisin 192.168.160.215 :

    router bgp 65401
 bgp log-neighbor-changes
 distance bgp 20 200 20
 !
 address-family ipv4 vrf 1
  redistribute omp
  propagate-aspath
  neighbor 192.168.140.10 remote-as 65300
  neighbor 192.168.140.10 activate
  neighbor 192.168.140.10 send-community both
  neighbor 192.168.160.215 remote-as 65400
  neighbor 192.168.160.215 activate
 exit-address-family
 !
sdwan
 omp
  no shutdown
  send-path-limit  4
  ecmp-limit       4
  graceful-restart
  no as-dot-notation
  timers
   holdtime               60
   advertisement-interval 1
   graceful-restart-timer 43200
   eor-timer              300
  exit
  address-family ipv4 vrf 1
   advertise bgp
  !
  address-family ipv4
   advertise connected
   advertise static
  !
  address-family ipv6
   advertise connected
   advertise static

    cE2 :

    router bgp 65401
 bgp log-neighbor-changes
 distance bgp 20 200 20
 !
 address-family ipv4 vrf 1
  redistribute omp
  propagate-aspath
  neighbor 192.168.150.10 remote-as 65300
  neighbor 192.168.150.10 activate
  neighbor 192.168.150.10 send-community both
  neighbor 192.168.160.214 remote-as 65401
  neighbor 192.168.160.214 activate
  neighbor 192.168.160.214 send-community both
 exit-address-family
 !
sdwan
 omp
  no shutdown
  send-path-limit  4
  ecmp-limit       4
  graceful-restart
  no as-dot-notation
  timers
   holdtime               60
   advertisement-interval 1
   graceful-restart-timer 43200
   eor-timer              300
  exit
  address-family ipv4 vrf 1
   advertise bgp
  !
  address-family ipv4
   advertise connected
   advertise static
  !
  address-family ipv6
   advertise connected
   advertise static

    cE3 :

    router bgp 65401
 bgp log-neighbor-changes
 timers bgp 5 15
 !
 address-family ipv4 vrf 1
  redistribute omp
  propagate-aspath
  neighbor 192.168.60.11 remote-as 65500
  neighbor 192.168.60.11 activate
 exit-address-family
!
sdwan
 omp
  no shutdown
  send-path-limit  4
  ecmp-limit       4
  graceful-restart
  no as-dot-notation
  timers
   holdtime               60
   advertisement-interval 1
   graceful-restart-timer 43200
   eor-timer              300
  exit
  address-family ipv4 vrf 1
   advertise bgp
  !
  address-family ipv4
   advertise connected
   advertise static
  !
  address-family ipv6
   advertise connected
   advertise static
  !

    Vérifier

    1. Dans l’état initial, la route est annoncée depuis cE3 et apprise par cE1 et cE2 via OMP. Les deux redistribuent la route vers BGP et s’annoncent mutuellement et vers R1 :

    cE1#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 342041
Paths: (2 available, best #2, table 1)
  Advertised to update-groups:
     4          5
  Refresh Epoch 1
  65500
    192.168.160.215 (via vrf 1) from 192.168.160.215 (192.168.109.215)
      Origin incomplete, metric 1000, localpref 50, valid, internal
      Extended Community: SoO:0:215 RT:1:1
      rx pathid: 0, tx pathid: 0
      Updated on Aug 21 2020 11:23:32 GMT
  Refresh Epoch 1
  65500
    192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, sourced, best
      Extended Community: SoO:0:214 RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 11:23:32 GMT

    cE2#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 327810
Paths: (2 available, best #2, table 1)
  Advertised to update-groups:
     5          6
  Refresh Epoch 1
  65500
    192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, internal
      Extended Community: RT:1:1
      rx pathid: 0, tx pathid: 0
      Updated on Aug 21 2020 11:23:32 GMT
  Refresh Epoch 1
  65500
    192.168.30.216 (via default) from 0.0.0.0 (192.168.109.215)
      Origin incomplete, metric 1000, localpref 50, valid, sourced, best
      Extended Community: SoO:0:215 RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 11:23:32 GMT

    2. L'interface WAN est déconnectée ou la connectivité à la structure SD-WAN est perdue sur cE2, d'où la panne des homologues OMP (connexions vSmart). Une seule route reste acquise à partir d'iBGP :

    ce2(config)#
    interface GigabitEthernet 2
    ce2(config-if)#
    shutdown
    ce2(config-if)#
    end
    Uncommitted changes found, commit them? [yes/no/CANCEL] yes
Commit complete.

    ce2#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 345276
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     6
  Refresh Epoch 1
  65500
    192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, internal, best
      Extended Community: RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 11:23:32 GMT 

    cE1 still prefers the route via OMP (this is the only route that remains) originated by cE3:

    ce1#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 342041
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     4          5
  Refresh Epoch 1
  65500
    192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, sourced, best
      Extended Community: SoO:0:214 RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 11:23:32 GMT

    3. La connectivité sur l’interface WAN de cE2 est rétablie. La route est toujours préférée à partir de cE1 via iBGP en raison d'une meilleure distance administrative (AD).

    ce2(config)#
    interface GigabitEthernet 2
    ce2(config-if)#
    no shutdown
    ce2(config-if)#
    end
    Uncommitted changes found, commit them? [yes/no/CANCEL] yes 
    Commit complete.

    ce2#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 345276
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     6
  Refresh Epoch 1
  65500
    192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, internal, best
      Extended Community: RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 11:23:32 GMT

    cE1 préfère toujours la route via OMP provenant de cE3. Gardez à l'esprit que cE1 redistribue OMP dans BGP :

    ce1#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 569358
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     4          5
  Refresh Epoch 1
  65500
    192.168.30.216 (via default) from 0.0.0.0 (192.168.109.214)
      Origin incomplete, metric 1000, localpref 50, valid, sourced, best
      Extended Community: SoO:0:214 RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 15:13:09 GMT

    4. Quelque chose se produit avec la connectivité cE3 à R2. Pour tester, l'interface est arrêtée et l'homologue BGP R2 est perdu :

    ce3(config)#
    interface GigabitEthernet 6
    ce3(config-if)#
    shutdown
    ce3(config-if)#
    commit

    5. Par conséquent, la boucle de routage est formée entre cE1 et cE2 (cE2 redistribue la route depuis OMP et annonce à cE1 via BGP, cE1 redistribue BGP à OMP et annonce à cE2) :

    ce1#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 732548
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     5
  Refresh Epoch 1
  65500
    192.168.160.215 (via vrf 1) from 192.168.160.215 (192.168.109.215)
      Origin incomplete, metric 1000, localpref 50, valid, internal, best
      Extended Community: SoO:0:215 RT:1:1
      rx pathid: 0, tx pathid: 0x0
      Updated on Aug 21 2020 15:38:47 GMT

    ce2#

    show bgp vpnv4 unicast vrf 1 10.1.1.1/24

    BGP routing table entry for 1:1:10.1.1.1/24, version 639650
Paths: (1 available, best #1, table 1)
  Advertised to update-groups:
     5          6
  Refresh Epoch 1
  65500
    192.168.30.214 (via default) from 0.0.0.0 (192.168.109.215)
      Origin incomplete, metric 1000, localpref 50, valid, sourced, best
      Extended Community: SoO:0:215 RT:1:1
      rx pathid: 1, tx pathid: 0x0
      Updated on Aug 21 2020 15:38:47 GMT

    Dépannage

    Il existe deux solutions possibles.

    Solution 1

    Configurez overlay-as pour OMP. Un numéro de système autonome (AS) est ensuite attribué à la superposition OMP elle-même. Exemple :

    config-transaction
 sdwan
  omp
   overlay-as 64512
   exit

    Par défaut, OMP est transparent pour BGP même si propagate-aspath est configuré. overlay-as est une fonctionnalité qui précède AS spécifié comme paramètre de cette commande à l'attribut BGP AS_PATH des routes exportées d'OMP vers BGP. Si vous configurez le même numéro de système autonome de superposition sur plusieurs périphériques du réseau de superposition, tous ces périphériques sont considérés comme faisant partie du même système autonome. Par conséquent, ils ne transfèrent aucune route contenant le numéro de système autonome de superposition, ce qui empêche la boucle de routage.

    Gardez à l'esprit que overlay-as et propagate-aspath sont dépendants l'un de l'autre. Cette fonction est traitée en détail.

    Il y a deux cas qui existent.

    Superposition - Cas AS 1

    overlay-as configuré au niveau global sous sdwan omp section et n' propagate-aspath est pas configuré (la configuration de repos est la même que celle décrite initialement : advertise bgp est activée sous omp address-family ipv4 vrf 1 section, redistribute omp configurée sous router bgp <AS> address-family ipv4 vrf 1 section).

    overlay-as 64512, configuré sur cE1/cE2 et cE3.

    Topologie pour la démonstration de superpositionTopologie pour la démonstration de la superposition

    Pour les besoins de la démonstration, BGP AS sur cE1, cE2 et cE3 a changé.

    R1 - cE1/cE2 toujours homologue via eBGP, AS 65300 et 65401 sont utilisés respectivement.

    cE3 - R2 toujours homologue via eBGP, AS 65402 et 65500 sont utilisés respectivement.

    R1 envoie une route (par exemple, 192.168.41.11/32) à cE1/cE2. cE1/cE2 redistribue cette route dans OMP, sans attribut AS_PATH.

    cE3 le reçoit et l'annonce dans BGP vers R2, uniquement avec son propre AS (comportement normal de eBGP).

    La route route 1 sur R2 a AS_PATH : 65402.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 ?

    Superposition - Cas AS 2

    propagate-aspath configuré dans la router bgp section pour le VPN côté service (address-family ipv4 vrf 1) particulier. Voici aussi des sous-cas.

    Cas 2.1 . Avec overlay-as activé sur cE3, propagate-aspath est également activé sous router bgp 65401 address-family ipv4 vrf 1 sur cE1/cE2.

    R1 envoie route route1 à cE1/cE2. cE1/cE2 redistribue cette route dans OMP avec un as-path provenant du site R1.

    La route OMP sur vSmart a AS-Path : 65300.

    vsmart1#

    show omp routes vpn 1 192.168.41.11/32 | nomore | exclude not\ set

    --------------------------------------------------- omp route entries for vpn 1 route 192.168.41.11/32 --------------------------------------------------- RECEIVED FROM: peer 192.168.30.214 path-id 81 label 1001 status C,R Attributes: originator 192.168.30.214 type installed tloc 192.168.30.214, biz-internet, ipsec overlay-id 1 site-id 25 origin-proto eBGP origin-metric 0 as-path "65300" RECEIVED FROM: peer 192.168.30.215 path-id 68 label 1002 status C,R Attributes: originator 192.168.30.215 type installed tloc 192.168.30.215, biz-internet, ipsec overlay-id 1 site-id 25 origin-proto eBGP origin-metric 0 as-path "65300"

    Cas 2.1.a. Avec propagate-aspath disabled sur cE3, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ignore tout attribut as-path, superpose as, vers R2, et ajoute seulement son propre AS BGP (comportement normal de eBGP).

    Route route1 sur R2 AS-path : 65402.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 ?

    Cas 2.1.b. Lorsque cette option est propagate-aspath activée sur cE3, cE3 la reçoit en tant que route OMP et l'annonce dans BGP, ajoute l'attribut as-path reçu en préfixe, vers R2, puis ajoute l'AS de superposition suivi de son propre AS BGP.

    Route route1 sur R2 AS-path : 65402 64512 65300.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 64512 65300 ?

    Cas 2.1.c. Avec propagate-aspath désactivé sur cE1/cE2, cE3 le reçoit en tant que route OMP sans attribut as-path et l'annonce dans BGP, vers R2, pré-ajoute l'AS de superposition et ajoute uniquement son propre AS BGP.

    Route route1 sur R2 AS-path : 6540264512.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 64512 ?

    Cas 2.2 . Sans overlay-as configuré sur cE3, propagate-aspath est activé sous router bgp 65401 address-family ipv4 vrf 1 sur cE1/cE2.

    Cas 2.2.a. Avec propagate-aspath disabled sur cE3 seulement, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ignorant tout attribut AS_PATH, vers R2, ajoute son propre AS BGP (comportement normal d'eBGP).

    Route route1 sur R2 AS-path : 65402.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 ?

    Cas 2.2.b. Lorsque propagate-aspath est activé sur cE3, cE3 le reçoit en tant que route OMP et l'annonce dans BGP, ajoute l'attribut AS_PATH reçu avant l'attribut AS_PATH reçu, vers R2, puis ajoute son propre AS.

    Route route1 sur R2 AS-path : 6540265300.

    R2#

    sh ip bgp | i 192.168.41.11/32

     *> 192.168.41.11/32 192.168.60.216 1000 0 65402 65300 ?
    note-icon

    Remarque : lorsque vous envoyez l'attribut AS-Path dans OMP, le routeur Edge n'ajoute pas son propre AS (comme démontré dans l'article vEdge Does Not Advertise Its Own AS When BGP Routes Are Advertised In OMP). Si le routeur de périphérie distant reçoit une route OMP avec son propre AS dans l'attribut AS_PATH, il n'effectue pas de détection de boucle et envoie la route avec le chemin AS reçu au routeur côté service.

    Solution 2

    Configurez le même site-id sur les routeurs cE1 et cE2. Bien que le vSmart annonce les routes au site avec le même ID de site que dans la route elle-même, puisque l'attribut d'origine de la route est différent, la prévention de boucle n'est pas déclenchée, mais la boucle de routage du plan de contrôle ne se forme pas car la route OMP n'est pas installée dans le RIB. Cela est dû au fait que la route OMP reste à l'état Inv, U (non valide, non résolu). Par défaut, les tunnels de plan de données ne peuvent pas être établis entre des sites qui ont le même ID de site, sauf si allow-same-site-tunnels est configuré. Si la session BFD du tunnel du plan de données est à l'état down, TLOC reste non résolu. Dans l’exemple ci-dessous, a site-id 214215 été configuré sur les deux routeurs ce1 et ce2. La route 10.0.0.2/32 annoncée par cE2 et cE1 ne l'installe pas dans la table de routage car aucune session de plan de données n'existe entre cE1 et cE2 :

    ce1#

    show sdwan omp route 10.0.0.2/32 det | exc not set

    --------------------------------------------------- omp route entries for vpn 3 route 10.0.0.2/32 --------------------------------------------------- RECEIVED FROM: peer 192.168.30.113 path-id 3 label 1004 status Inv,U Attributes: originator 192.168.30.215 type installed tloc 192.168.30.215, mpls, ipsec overlay-id 1 site-id 214215 origin-proto connected origin-metric 0 RECEIVED FROM: peer 192.168.30.113 path-id 4 label 1004 status Inv,U loss-reason tloc-id lost-to-peer 192.168.30.113 lost-to-path-id 3 Attributes: originator 192.168.30.215 type installed tloc 192.168.30.215, biz-internet, ipsec overlay-id 1 site-id 214215 origin-proto connected origin-metric 0

    ce1#

    show sdwan omp tlocs "ip 192.168.30.215" | exclude not set

    --------------------------------------------------- tloc entries for 192.168.30.215 mpls ipsec --------------------------------------------------- RECEIVED FROM: peer 192.168.30.113 status C,I,R Attributes: attribute-type installed encap-proto 0 encap-spi 256 encap-auth sha1-hmac,ah-sha1-hmac encap-encrypt aes256 public-ip 192.168.110.215 public-port 12347 private-ip 192.168.110.215 private-port 12347 public-ip :: public-port 0 private-ip :: private-port 0 bfd-status down site-id 214215 preference 0 weight 1 version 3 gen-id 0x80000026 carrier default restrict 0 groups [ 0 ] bandwidth 0 qos-group default-group --------------------------------------------------- tloc entries for 192.168.30.215 biz-internet ipsec --------------------------------------------------- RECEIVED FROM: peer 192.168.30.113 status C,I,R Attributes: attribute-type installed encap-proto 0 encap-spi 256 encap-auth sha1-hmac,ah-sha1-hmac encap-encrypt aes256 public-ip 192.168.109.215 public-port 12347 private-ip 192.168.109.215 private-port 12347 public-ip :: public-port 0 private-ip :: private-port 0 bfd-status down site-id 214215 preference 0 weight 1 version 3 gen-id 0x80000026 carrier default restrict 0 groups [ 0 ] bandwidth 0 qos-group default-group

    ce1#

    Vous pouvez vérifier cette commande sur le contrôleur vSmart afin de comprendre quelles routes reçoivent le préfixe particulier (voir la section « ANNONCÉ À ») :

    vsmart1#

    show omp routes 10.1.1.0/24 detail | nomore | exclude not\ set

    --------------------------------------------------- omp route entries for vpn 1 route 10.1.1.0/24 --------------------------------------------------- RECEIVED FROM: peer 192.168.30.216 path-id 68 label 1002 status C,R Attributes: originator 192.168.30.216 type installed tloc 192.168.30.216, biz-internet, ipsec overlay-id 1 site-id 216 origin-proto eBGP origin-metric 0 as-path 65500 ADVERTISED TO: peer 192.168.30.214 Attributes: originator 192.168.30.216 label 1002 path-id 5525 tloc 192.168.30.216, biz-internet, ipsec site-id 216 overlay-id 1 origin-proto eBGP origin-metric 0 as-path 65500 ADVERTISED TO: peer 192.168.30.215 Attributes: originator 192.168.30.216 label 1002 path-id 5287 tloc 192.168.30.216, biz-internet, ipsec site-id 216 overlay-id 1 origin-proto eBGP origin-metric 0 as-path 65500

    site-id Elles sont également conservées en tant qu'attribut étendu de communauté du site d'origine BGP (SoO) (vous pouvez remarquer SoO:0:<site-id> dans les résultats précédents). Utilisé pour identifier les routes qui proviennent d'un site afin d'empêcher la nouvelle annonce de ce préfixe. Pour que cela fonctionne correctement, les routeurs doivent envoyer des communautés étendues. Configurez cE1 pour envoyer des communautés étendues au routeur cE2 :

    router bgp 65401 address-family ipv4 vrf 1 neighbor 192.168.160.215 send-community both

    Explication de la prévention de boucle SoO

    Pour le cas où deux routeurs sur le même site sont des voisins iBGP, SD-WAN a un mécanisme de prévention de boucle intégré afin d'empêcher une boucle de routage d'OMP à BGP et de retour de BGP à OMP. Afin de démontrer cela, la topologie a été légèrement mise à jour et le même site-id 214215 a été configuré sur les deux routeurs qui exécutent BGP AS65400 (cE1/cE2). Dans cet exemple, un préfixe 10.1.1.0/24 est annoncé dans OMP à partir du site distant (cE3) et appris dans OMP au site 214215 (cE1-cE2).

    Topologie pour la démonstration SoOTopologie pour la démonstration SoO

    Afin d'accomplir la prévention des boucles, le SoO de la communauté étendue BGP est utilisé pour montrer quel site est à l'origine du préfixe. Cette communauté est ajoutée à un préfixe lorsqu'elle est redistribuée d'OMP dans BGP.

    La send-community <both|extended> commande doit être configurée sur l'instruction neighbor dans les deux périphériques, comme illustré, pour que cette fonctionnalité fonctionne correctement.

    cEdge1#

    show run | sec router bgp

    router bgp 65400 bgp log-neighbor-changes ! address-family ipv4 vrf 1 redistribute omp neighbor 192.168.160.215 remote-as 65400 neighbor 192.168.160.215 activate neighbor 192.168.160.215 send-community both exit-address-family

    cEdge2#

    show run | sec router bgp

    router bgp 65400 bgp log-neighbor-changes ! address-family ipv4 vrf 1 neighbor 192.168.160.214 remote-as 65400 neighbor 192.168.160.214 activate neighbor 192.168.160.214 send-community both exit-address-family

    La communauté étendue peut être vue avec la sortie show bgp vpnv4 unicast vrf 1 <prefix> du site de publicité ou de réception.

    Exemple

    cEdge1#

    show bgp vpnv4 unicast vrf 1 10.1.1.1

    BGP routing table entry for 1:10:10.1.1.1/24, version 4 Paths: (1 available, best #1, table 1) Advertised to update-groups: 1 Refresh Epoch 1 Local 192.168.30.215 (via default) from 0.0.0.0 (192.168.109.215) Origin incomplete, metric 1000, localpref 50, valid, sourced, best Extended Community: SoO:0:214215 RT:1:1 rx pathid: 0, tx pathid: 0x0 Updated on Jul 5 2152 23:30:55 UTC

    Sur le routeur qui annonce le préfixe d'OMP dans BGP (cEdge1 dans cet exemple), seule la route OMP doit être présente dans le RIB.

    Exemple

    cEdge1#

    show ip route vrf 1 10.1.1.1

    Routing Table: 1
    Routing entry for 10.1.1.1/32
      Known via "omp", distance 251, metric 0, type omp
      Redistributing via bgp 65400
      Advertised by bgp 65400
      Last update from 192.168.30.215 on Sdwan-system-intf, 15:59:54 ago
      Routing Descriptor Blocks:
      * 192.168.30.215 (default), from 192.168.30.215, 15:59:54 ago, via Sdwan-system-intf
          Route metric is 0, traffic share count is 1

    Cependant, il peut arriver qu'une condition de concurrence se produise sur le second routeur qui reçoit le préfixe annoncé et entraîne l'installation de la route BGP dans le RIB avant l'apprentissage de la route OMP.

    Sur cEdge2, la sortie de sh bpg vpnv4 unicast vrf 1 <prefix> affiche les éléments suivants :

    1. Non annoncé à un homologue.
    2. La communauté étendue inclut l'ID de site 214215, qui est le même site que celui sur lequel se trouve ce routeur.
      3.

    Exemple

    cEdge2#

    show bgp vpnv4 unicast vrf 1 10.1.1.1

    BGP routing table entry for 1:1:10.1.1.1/24, version 32
    Paths: (1 available, best #1, table 1)
      Not advertised to any peer
      Refresh Epoch 1
      Local
        192.168.160.214 (via vrf 1) from 192.168.160.214 (192.168.54.11)
          Origin incomplete, metric 1000, localpref 50, valid, internal, best
          Extended Community: SoO:0:214215 RT:65512:10
          rx pathid: 0, tx pathid: 0x0
          Updated on Jul 6 2152 17:26:19 UTC

    Sur cEdge2, la sortie de sh ip route vrf <vrf_number> <prefix> affiche les éléments suivants :

    1. L'indicateur « SDWAN Down » indique que ce problème provient du même site et qu'il a été détecté.
    2. La distance administrative de la route est 252 (supérieure à OMP et différente de la distance administrative iBGP attendue de 200).
      3.

    Exemple

    cEdge2#

    show ip route vrf 1 10.1.1.1
    Routing Table: 1
    Routing entry for 10.1.1.0/24
    Known via "bgp 65400",

    distance 252
    , metric 1000, type internal
    Redistributing via omp
    Last update from 192.168.160.214 00:15:13 ago
    Routing Descriptor Blocks:
    * 192.168.160.214, from 192.168.160.214, 00:15:13 ago
    opaque_ptr 0x7F9DD0B86818 

    SDWAN Down
    Route metric is 1000, traffic share count is 1
    AS Hops 0
    MPLS label: none

    Lorsqu'un routeur de site détecte qu'une route apprise BGP provient du même site-id, la route n'est pas annoncée à nouveau dans OMP.

    Informations connexes

    Historique de révision

    Révision Date de publication Commentaires
    5.0
    17-May-2024
    Recertification
    4.0
    10-Nov-2022
    Première publication
    3.0
    16-Aug-2022
    La section « Explication de la prévention de la boucle SoO » a été ajoutée.
    2.0
    04-Nov-2021
    Solution 2 mise à jour dans la section Dépannage.
    1.0
    01-Sep-2020
    Première publication

    Contribution de

    • Eugene Khabarov
      Ingénieur de remontée SD-WAN Cisco
    • Andy Rook
      Ingénieur technique de la prestation client Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits