Avez-vous un compte?

  •   Contenu personnalisé
  •   Vos produits et votre soutien technique

Vous voulez un compte?

Créer un compte

Comprenez le prochain saut réglé en annonces d'iBGP sur le Nexus NX-OS contre le Cisco IOS

Options de téléchargement

  • PDF     (419.1 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (342.4 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (208.2 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
À propos des traductions

À 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 quand le positionnement pour les annonces intérieures de protocole BGP (iBGP) sur le Nexus NX-OS contre le Cisco IOS (ceci inclut le Cisco IOS XE) a basé des Plateformes. C'est pour des annonces des artères non localement lancées.

    Conditions préalables

    Conditions requises

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

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

    Composants utilisés

    Ce document n'est pas limité au logiciel et aux versions de matériel spécifiques :

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

    Les sorties dans ce document ont été prises des périphériques dans un environnement de travaux pratiques spécifique. Tous les périphériques utilisés dans ce document commencé par une configuration (par défaut) effacée. Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.


    Informations générales

    • Sur le Nexus NX-OS basé les Plateformes, parce que les artères non localement lancées, des annonces d'iBGP modifient l'attribut NEXT_HOP et le placent avec sa propre adresse IP d'interface locale.
    • Sur le Cisco IOS basé les Plateformes, parce que les artères non localement lancées, des annonces d'iBGP mettent à jour l'attribut NEXT_HOP de l'artère d'origine pendant qu'elle est.

    Le comportement sur le Nexus NX-OS peut apparier celui vu sur le Cisco IOS si grâce désirée aux modifications du code introduites par le défaut CSCud20941.

    Note: Ce s'applique seulement pour les annonces et pas l'eBGP d'iBGP.


    Note: Applicable pour les artères non localement lancées configurées en tant qu'artères statiques ou reçues par l'intermédiaire de tout Protocole IGP (Interior Gateway Protocol) comme le Protocole EIGPR (Enhanced Interior Gateway Routing Protocol), le Protocole OSPF (Open Shortest Path First) ou le Protocole RIP (Routing Information Protocol).


    Comprenez les annonces d'iBGP

    Afin de comprendre le NEXT_HOP a placé en annonces d'iBGP, prennent comme exemple les diagrammes de topologie du réseau affichés dans les images.

    Topologie pour le cas du Nexus NX-OS


     Topologie pour le cas de Cisco IOS


    Cas du Nexus NX-OS

    Dans la topologie pour le cas du Nexus NX-OS, R2 (Nexus NX-OS) reçoit l'artère 1.1.1.1/32 par l'intermédiaire de l'EIGRP du routeur 1 et l'annonce avec l'utilisation de l'iBGP à Routeur3 suivant les indications de l'image.


    (Nexus NX-OS) le Tableau de routage R2 affiche l'artère 1.1.1.1/32 reçue par l'intermédiaire de l'EIGRP et avec l'IP d'origine de prochain-saut de 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 de configuration BGP vous pouvez voir les commandes d'annoncer en place 1.1.1.1/32 par l'intermédiaire de l'iBGP à Routeur3.

    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 Routeur3, l'artère 1.1.1.1/32 est reçue par l'intermédiaire de l'iBGP avec le prochain-saut maintenant réglé à l'adresse IP de R2 (Nexus NX-OS) qui est 10.2.3.2

    - Routeur3 entrée de table BGP 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


    - Routeur3 acheminement de l'entrée de table 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 de Cisco IOS

    Dans la topologie pour le cas de Cisco IOS, R2 (Cisco IOS) reçoit l'artère 1.1.1.1/32 par l'intermédiaire de l'EIGRP du routeur 1 et l'annonce avec l'utilisation de l'iBGP à Routeur3 suivant les indications de l'image.

    Le Tableau de routage R2 (Cisco IOS) affiche l'artère 1.1.1.1/32 reçue par l'intermédiaire de l'EIGRP et avec l'IP d'origine de prochain-saut de 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 de configuration BGP vous pouvez voir les commandes d'annoncer en place 1.1.1.1/32 par l'intermédiaire de l'iBGP à Routeur3

    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 Routeur3, vous pouvez voir l'artère 1.1.1.1/32 reçue par l'intermédiaire de l'iBGP avec le prochain-saut d'origine réglé à l'IP sur le routeur 1 qui est 10.1.2.1.

    - Routeur3 entrée de table BGP 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, Routeur3 doit avoir un chemin à 10.1.2.1 (le Prochain-saut) ainsi le BGP peut considérer le chemin comme valide. Autrement, le BGP affiche le chemin en tant que (inaccessible).


    Note: C'est un contrôle de base décrit dans l'algorithme de sélection du meilleur chemin BGP afin de recevoir des artères de BGP dans le Tableau de routage.


    La mise à jour de debug ip bgp de commande affiche que la raison Routeur3 n'installe pas l'artère est parce qu'il n'y a aucune entrée dans son Tableau de routage pour le prochain-saut, dans ce cas le prochain-saut 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


    Une approche pour rendre le prochain-saut accessible est :

    - Étape 1. Une artère statique dans le Tableau de routage de Routeur3 est configurée afin de créer une entrée pour le prochain-saut.

    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 de débogage prouve que l'artère est maintenant reçue.

    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 enlevé 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


    - Le Tableau de routage d'étape 4. installe maintenant l'artère sur 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 commande redist-inchangée de set ip next-hop

    Depuis la version 6.2(12), le set ip next-hop de commandes redist-inchangé et le prochain-saut figé d'IPv6 redist-inchangé ont été introduits par le défaut CSCud20941 afin de faire à miroir du Nexus NX-OS le comportement du Cisco IOS.

    Note: Ces commandes seulement fonctionnent une fois utilisées comme paramètres dans un route-map et sont utilisées en combination avec la commande de redistribution.


    Dans la topologie pour le cas du Nexus NX-OS, R2 (Nexus NX-OS) reçoit l'artère 1.1.1.1/32 par l'intermédiaire de l'EIGRP du routeur 1 et l'annonce avec l'iBGP à Routeur3 suivant les indications de l'image :


    (Nexus NX-OS) le Tableau de routage R2 affiche l'artère 1.1.1.1/32 reçue par l'intermédiaire de l'EIGRP et avec l'IP d'origine de prochain-saut de 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


    Le set ip next-hop de commande redist-inchangé est disponible sous le mode de configuration de « 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


    Le route-map REDIST-UNCHANGED est appliqué comme paramètre pour la directive de configuration de redistribuer dans le 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


    Reçoit maintenant Routeur3 la MISE À JOUR BGP avec le semblable réglé de l'original NEXT_HOP au 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 de la façon dont le Nexus NX-OS et le Cisco IOS manipule des annonces d'iBGP des artères non localement générées.

    Le comportement décrit dans ce document est pour la plupart des scénarios de cas et il n'est pas un qui affectent des exécutions habituelles de routage réseau.

    Le set ip next-hop facultatif de commandes redist-inchangé et le prochain-saut figé d'IPv6 redist-inchangé sont disponibles pour mettre à jour l'acheminement BGP conforme avec RFC 4271 sur le Nexus NX-OS


    Configuration de périphériques initiale

    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
      Ingénieur TAC Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Discussions connexes de communautés de Cisco

    Suivez-nous
    Salle de presseÉvénementsBloguesCommunauté
    À propos de nous
    Communiquer Avec Nous
    Travailler Avec Nous