Explorer Cisco
Comment acheter

Avez-vous un compte?

  •   Contenu personnalisé
  •   Vos produits et votre soutien technique

Vous voulez un compte?

Créer un compte

Comprendre le saut suivant dans les annonces iBGP sur Nexus NX-OS par rapport à Cisco IOS

Options de téléchargement

  • PDF     (418.9 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (351.1 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (207.8 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:12 juin 2018
ID du document:213402

Langage sans préjugés

Dans la documentation de ce produit, les auteurs s‘efforcent d‘utiliser un langage exempt de préjugés. Aux fins de cet ensemble de documents, l’expression « sans préjugés » est définie comme un langage sans discrimination fondée sur l’âge, le handicap, le sexe, l’identité raciale, l’identité ethnique, l’orientation sexuelle, la situation socio-économique et l’intersectionnalité. Des exceptions peuvent être présentes dans la documentation en raison de la langue codée en dur dans les interfaces utilisateur du logiciel du produit, de la langue utilisée en fonction de la documentation de l’appel d’offres ou de la langue utilisée par un produit tiers référencé. En savoir plus sur la façon dont 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 le comportement de l'attribut de chemin NEXT_HOP lorsqu'il est défini pour les annonces iBGP (Interior Border Gateway Protocol) sur Nexus NX-OS et Cisco IOS (ceci inclut Cisco IOS-XE). Ceci est destiné aux annonces de routes non locales.

    Conditions préalables

    Conditions requises

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • BGP (Border Gateway Protocol)
    • Redistribution des protocoles de routage

    Components Used

    Ce document n’est pas limité à des versions spécifiques du logiciel et du matériel :

    • Nexus 7000 qui exécute NX-OS version 7.3(0)D1(1)
    • Routeur Cisco qui exécute Cisco IOS version 15.6(2)T

    Les résultats de ce document proviennent de périphériques situés dans un environnement de travaux pratiques spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.


    Informations générales

    • Sur les plates-formes NX-OS Nexus, pour les routes non locales, les annonces iBGP modifient l'attribut NEXT_HOP et le définissent avec sa propre adresse IP d'interface locale.
    • Sur les plates-formes Cisco IOS, pour les routes non locales, les annonces iBGP conservent l'attribut NEXT_HOP de la route d'origine telle qu'elle est.

    Le comportement de Nexus NX-OS peut correspondre à celui de Cisco IOS si vous le souhaitez grâce aux modifications de code introduites par le défaut CSCud20941.

    Remarque : ceci s'applique uniquement aux annonces iBGP et non à eBGP.


    Note: Applicable aux routes non locales configurées en tant que routes statiques ou reçues via un protocole IGP (Interior Gateway Protocol) tel que EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First) ou RIP (Routing Information Protocol).


    Comprendre les annonces iBGP

    Afin de comprendre le paramètre NEXT_HOP défini dans les annonces iBGP, prenez comme exemple les diagrammes de topologie de réseau présentés dans les images.

    Topologie du cas Nexus NX-OS


     Topologie du cas Cisco IOS


    Cas Nexus NX-OS

    Dans le cas de la topologie Nexus NX-OS, R2 (Nexus NX-OS) reçoit la route 1.1.1.1/32 via EIGRP depuis le routeur 1 et l'annonce avec l'utilisation d'iBGP vers le routeur 3, comme l'illustre l'image.


    La table de routage de R2 (Nexus NX-OS) indique la route 1.1.1.1/32 reçue via EIGRP et avec l'adresse IP de tronçon suivant d'origine 10.1.2.1

    R2 (Nexus NX-OS) 
    R2# show ip route 1.1.1.1/32
    IP Route Table for VRF "default"
    '*' denotes best ucast next-hop
    '**' denotes best mcast next-hop
    '[x/y]' denotes [preference/metric]
    '%<string>' in via output denotes VRF <string>

    1.1.1.1/32, ubest/mbest: 1/0
        *via 10.1.2.1, Eth2/1, [90/130816], 00:02:28, eigrp-1, internal


    Dans la section Configuration BGP, vous pouvez voir les commandes en place pour annoncer 1.1.1.1/32 via iBGP vers le routeur 3.

    R2 (Nexus NX-OS) 
    R2# show running-config bgp

!Command: show running-config bgp
!Time: -

version -
feature bgp

router bgp 2
  address-family ipv4 unicast
    network 1.1.1.1/32
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast


    Sur le routeur 3, la route 1.1.1.1/32 est reçue via iBGP avec le saut suivant maintenant défini sur l'adresse IP de R2 (Nexus NX-OS) qui est 10.2.3.2

    - Entrée de la table BGP du routeur 3 pour 1.1.1.1/32

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 8
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.2.3.2 from 10.2.3.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0


    - Entrée de la table de routage du routeur 3 pour 1.1.1.1/32

    R3 
    R3# show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [200/0] via 10.2.3.2, 00:07:17


    Cas Cisco IOS

    Dans le cas de la topologie de Cisco IOS, R2 (Cisco IOS) reçoit la route 1.1.1.1/32 via EIGRP depuis le routeur 1 et l'annonce avec l'utilisation d'iBGP vers le routeur 3, comme illustré dans l'image.

    La table de routage de R2 (Cisco IOS) indique la route 1.1.1.1/32 reçue via EIGRP et avec l’adresse IP de tronçon suivant d’origine 10.1.2.1.

    R2 (Cisco IOS) 
    R2# show ip route 1.1.1.1 255.255.255.255 longer-prefixes
    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
           a - application route
           + - replicated route, % - next hop override, p - overrides from PfR

    Gateway of last resort is not set

          1.0.0.0/32 is subnetted, 1 subnets
    D        1.1.1.1 [90/130816] via 10.1.2.1, 00:00:06, GigabitEthernet0/1


    Dans la section Configuration BGP, vous pouvez voir les commandes en place pour annoncer 1.1.1.1/32 via iBGP vers Router 3

    R2 (Cisco IOS) 
    R2# show running-config partition router bgp 2
    Building configuration...

    Current configuration : 210 bytes
    !
    ! Last configuration change at -
    !
    !
    !
    !
    router bgp 2
     bgp router-id 2.2.2.2
     bgp log-neighbor-changes
    network 1.1.1.1 mask 255.255.255.255
     neighbor 10.2.3.3 remote-as 2
    !
    !
    end


    Sur le routeur 3, vous pouvez voir la route 1.1.1.1/32 reçue via iBGP avec le saut suivant d'origine défini sur l'IP sur le routeur 1, qui est 10.1.2.1.

    - Entrée de la table BGP du routeur 3 pour 1.1.1.1/32

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.2.1 (inaccessible) from 10.2.3.2 (2.2.2.2)
      Origin IGP, metric 130816, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0


    Dans ce scénario spécifique, le routeur 3 doit avoir un chemin vers 10.1.2.1 (tronçon suivant) pour que BGP puisse considérer le chemin comme valide. Sinon, BGP affiche le chemin comme (inaccessible).


    Note: Il s'agit d'un contrôle de base décrit dans l'algorithme de sélection du meilleur chemin BGP afin d'accepter les routes de BGP dans la table de routage.


    La commande debug ip bgp update montre la raison pour laquelle le routeur 3 n'installe pas la route est parce qu'il n'y a aucune entrée dans sa table de routage pour le tronçon suivant, dans ce cas le tronçon suivant est 10.1.2.1

    R3 
    R3# debug ip bgp update
*-: BGP(0): 10.2.3.2 rcvd UPDATE w/ attr: nexthop 10.1.2.1, origin i, localpref 100, metric 130816
*-: BGP(0): 10.2.3.2 rcvd 1.1.1.1/32
*-: BGP(0): no valid path for 1.1.1.1/32


    Pour rendre le saut suivant accessible, procédez comme suit :

    -Étape 1. Une route statique de la table de routage du routeur 3 est configurée afin de créer une entrée pour le tronçon suivant.

    R3 
    R3# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)# ip route 10.1.2.1 255.255.255.255 10.2.3.2


    -Étape 2. La même commande debug indique que la route est maintenant acceptée.

    R3 
    R3# debug ip bgp update
R3#
*Mar 29 16:08:42.888: BGP(0): 10.2.3.2 rcvd UPDATE w/ attr: nexthop 10.1.2.1, origin i, localpref 100, metric 130816
*Mar 29 16:08:42.890: BGP(0): 10.2.3.2 rcvd 1.1.1.1/32
*Mar 29 16:08:42.892: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.1/32 -> 10.1.2.1(global) to main IP table
R3#


    -Étape 3. La table BGP a supprimé l'état (inaccessible).

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.1.2.1 from 10.2.3.2 (2.2.2.2)
      Origin IGP, metric 130816, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0


    -Étape 4. La table de routage installe maintenant la route vers 1.1.1.1/32

    R3 
    R3# show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [200/130816] via 10.1.2.1, 00:11:37


    Utilisation de la commande set ip next-hop redist-inchangée

    Depuis la version 6.2(12), les commandes set ip next-hop redist-inchangée et set ipv6 next-hop redist-inchangée ont été introduites par défaut CSCud20941 afin de rendre Nexus NX-OS miroir le comportement de Cisco IOS.

    Note: Ces commandes ne fonctionnent que lorsqu'elles sont utilisées comme paramètres dans une route-map et sont utilisées en combinaison avec la commande redistribution.


    Dans le cas de la topologie Nexus NX-OS, R2 (Nexus NX-OS) reçoit la route 1.1.1.1/32 via EIGRP depuis le routeur 1 et l'annonce avec iBGP vers le routeur 3, comme l'illustre l'image :


    La table de routage de R2 (Nexus NX-OS) indique la route 1.1.1.1/32 reçue via EIGRP et avec l'adresse IP de tronçon suivant d'origine 10.1.2.1

    R2 (Nexus NX-OS) 
    R2# show ip route 1.1.1.1/32
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

1.1.1.1/32, ubest/mbest: 1/0
    *via 10.1.2.1, Eth2/1, [90/130816], 04:38:21, eigrp-1, internal


    La commande set ip next-hop redist-inchangée est disponible en mode de configuration 'route-map'.

    R2 (Nexus NX-OS) 
    R2(config)# route-map REDIST-UNCHANGED
    R2(config-route-map)# set ip next-hop ?
      A.B.C.D              IP address of next hop
      load-share           Enables load sharing
      peer-address         Use peer address (for BGP only)
      redist-unchanged     Use unchanged address during redistribution (for BGP
                           session only) 
      unchanged            Use unchanged address (for eBGP session only)
      verify-availability  Verify the reachability of the tracked object

    R2(config-route-map)# set ip next-hop redist-unchanged


    La route-map REDIST-UNCHANGED est appliquée en tant que paramètre pour l'instruction de configuration redistribute dans BGP.

    R2 (Nexus NX-OS) 
    R2#

!
    route-map REDIST-UNCHANGED permit 10
  set ip next-hop redist-unchanged
!    

R2# show running-config bgp

!Command: show running-config bgp
!Time: -

version -
feature bgp

router bgp 2
  address-family ipv4 unicast
    redistribute eigrp 1 route-map REDIST-UNCHANGED
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast


    Le routeur 3 reçoit maintenant la MISE À JOUR BGP avec le jeu NEXT_HOP d'origine similaire à Cisco IOS.

    R3 
    R3# show ip bgp 
BGP table version is 15, local router ID is 10.2.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       10.1.2.1            130816    100      0 ?


    Ce document décrit la différence entre la façon dont Nexus NX-OS et Cisco IOS gèrent les annonces iBGP de routes non générées localement.

    Le comportement décrit dans ce document concerne la plupart des scénarios et n’a pas d’incidence sur les opérations de routage réseau habituelles.

    Les commandes facultatives set ip next-hop redist-inchangée et set ipv6 next-hop redist-inchangée sont disponibles pour maintenir le routage BGP conforme à la RFC 4271 sur Nexus NX-OS


    Configuration initiale des périphériques

    R1 
    hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/1
 ip address 10.1.2.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
router ospf 1
    !


    R2 (Nexus NX-OS) 
    hostname R2
!
feature ospf
feature bgp
!
interface Ethernet2/1
  no switchport
  ip address 10.1.2.2/24
  ip ospf network point-to-point
  ip router ospf 1 area 0.0.0.0
  no shutdown
!
interface Ethernet2/2
  no switchport
  ip address 10.2.3.2/24
  no shutdown
!
router ospf 1
!
router bgp 2
  address-family ipv4 unicast
    network 1.1.1.1/32
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast
!


    R2 (Cisco IOS) 
    hostname R2
!
interface GigabitEthernet0/1
 ip address 10.1.2.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface GigabitEthernet0/2
 ip address 10.2.3.2 255.255.255.0
!
router ospf 1
!
router bgp 2
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.2.3.3 remote-as 2
!


    R3 
    hostname R3
!
interface GigabitEthernet0/1
 ip address 10.2.3.3 255.255.255.0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 10.2.3.2 remote-as 2
!


    TAC Authored

    Contribution d’experts de Cisco

    • Hector Gustavo Serrano Gutierrez
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco