Next-Hop-Set in iBGP-Anzeigen für Nexus NX-OS und Cisco IOS

Download-Optionen

  • PDF     (386.3 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (347.2 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (202.9 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:12. Juni 2018
Dokument-ID:213402

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.


    Einführung

    Dieses Dokument beschreibt das Verhalten des NEXT_HOP path-Attributs, wenn es für interne Border Gateway Protocol (iBGP)-Anzeigen auf Nexus NX-OS- und Cisco IOS-basierten Plattformen (einschließlich Cisco IOS-XE) festgelegt wird. Dies gilt für Werbung für nicht lokal generierte Routen.

    Voraussetzungen

    Anforderungen

    Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

    • Border Gateway Protocol (BGP)
    • Neuverteilung von Routing-Protokollen

    Verwendete Komponenten

    Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt:

    • Nexus 7000 mit NX-OS Version 7.3(0)D1(1)
    • Cisco Router mit Cisco IOS Version 15.6(2)T

    Die Ergebnisse in diesem Dokument stammen von Geräten in einer bestimmten Laborumgebung. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.


    Hintergrundinformationen

    • Auf Nexus NX-OS-basierten Plattformen ändert iBGP bei Routen ohne lokalen Ursprung das Attribut NEXT_HOP und legt es mit seiner eigenen IP-Adresse für die lokale Schnittstelle fest.
    • Auf IOS-basierten Plattformen von Cisco wird in iBGP-Meldungen bei Routen ohne lokalen Ursprung das NEXT_HOP-Attribut der ursprünglichen Route beibehalten.

    Das Verhalten auf Nexus NX-OS kann mit dem Verhalten auf Cisco IOS übereinstimmen, wenn es gewünscht wird. Dies ist auf die Codeänderungen zurückzuführen, die durch den Fehler CSCud20941 eingeführt wurden.

    Hinweis: Dies gilt nur für iBGP-Werbung und nicht für eBGP.


    Hinweis: Gilt für nicht lokal generierte Routen, die als statische Routen konfiguriert sind oder über ein Interior Gateway Protocol (IGP) wie EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First) oder RIP (Routing Information Protocol) empfangen werden.


    iBGP-Werbung

    Um das NEXT_HOP-Set in iBGP-Werbeanzeigen zu verstehen, nehmen Sie als Beispiel die in den Bildern gezeigten Netzwerktopologiediagramme.

    Topologie für Nexus NX-OS-Gehäuse
    213402-understand-next-hop-set-in-ibgp-advertis-00.png


     Topologie für Cisco IOS-Fall
    213402-understand-next-hop-set-in-ibgp-advertis-01.png


    Nexus NX-OS-Fall

    In der Topologie für Nexus NX-OS empfängt R2 (Nexus NX-OS) die 1.1.1.1/32-Route über EIGRP von Router 1 und kündigt sie mit der Verwendung von iBGP für Router 3 an, wie im Bild gezeigt.

    213402-understand-next-hop-set-in-ibgp-advertis-02.png


    Die R2-Routing-Tabelle (Nexus NX-OS) zeigt die Route 1.1.1.1/32, die über EIGRP empfangen wurde, mit der ursprünglichen Next-Hop-IP von 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


    Im Abschnitt zur BGP-Konfiguration werden die Befehle angezeigt, mit denen Router 3 über iBGP 1.1.1.1/32 angekündigt wird.

    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


    Auf Router 3 wird die 1.1.1.1/32-Route über iBGP empfangen, wobei der Next-Hop jetzt auf die IP-Adresse von R2 (Nexus NX-OS) eingestellt ist, die 10.2.3.2 lautet.

    - Router 3 BGP-Tabelleneintrag für 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


    - Router 3 Routing Table-Eintrag für 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


    Cisco IOS-Fall

    In der Topologie für Cisco IOS empfängt R2 (Cisco IOS) die 1.1.1.1/32-Route über EIGRP von Router 1 und kündigt sie mit der Verwendung von iBGP an Router 3 an, wie im Bild gezeigt.

    213402-understand-next-hop-set-in-ibgp-advertis-03.png

    Die Routing-Tabelle für R2 (Cisco IOS) zeigt die Route 1.1.1.1/32, die über EIGRP empfangen wurde, mit der ursprünglichen Next-Hop-IP von 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


    Im Abschnitt zur BGP-Konfiguration werden die Befehle angezeigt, mit denen Router 3 über iBGP 1.1.1.1/32 angekündigt wird.

    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


    Auf Router 3 sehen Sie die 1.1.1.1/32-Route, die über iBGP empfangen wurde, wobei der ursprüngliche Next-Hop auf die IP auf Router 1 (10.1.2.1) gesetzt ist.

    - Router 3 BGP-Tabelleneintrag für 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


    In diesem speziellen Szenario muss Router 3 über einen Pfad zu 10.1.2.1 (Next-Hop) verfügen, damit das BGP den Pfad als gültig ansieht. Andernfalls zeigt das BGP den Pfad als (nicht zugänglich) an.


    Hinweis: Dies ist eine grundlegende Überprüfung, die im BGP Best Path Selection Algorithm beschrieben wird, um Routen vom BGP in die Routing-Tabelle zu akzeptieren.


    Der Befehl debug ip bgp update zeigt an, dass Router 3 die Route nicht installiert, weil es in seiner Routing-Tabelle keinen Eintrag für den nächsten Hop gibt, in diesem Fall ist der Next-Hop 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


    Ein Ansatz, um den Next-Hop zugänglich zu machen, ist:

    - Schritt 1. Eine statische Route in der Routing-Tabelle von Router 3 wird konfiguriert, um einen Eintrag für den nächsten Hop zu erstellen.

    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


    - Schritt 2. Der gleiche Debugbefehl zeigt, dass die Route jetzt akzeptiert wird.

    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#


    - Schritt 3. Die BGP-Tabelle hat den Status (nicht zugänglich) entfernt.

    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


    - Schritt 4. Die Routing-Tabelle installiert jetzt die Route zu 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


    Verwendung des Befehls set ip next-hop redist-unverändertes

    Seit Version 6.2(12) wurden die Befehle set ip next-hop redist unverändertes und set ipv6 next-hop redist-unverändertes durch den Fehler CSCud20941 eingeführt, um Nexus NX-OS dem Verhalten von Cisco IOS anzupassen.

    Hinweis: Diese Befehle funktionieren nur, wenn sie als Parameter in einer Routenübersicht verwendet werden. Sie werden zusammen mit dem Befehl redistribution verwendet.


    In der Topologie für Nexus NX-OS empfängt R2 (Nexus NX-OS) die 1.1.1.1/32-Route über EIGRP von Router 1 und kündigt sie mit iBGP an Router 3 an, wie im Bild gezeigt:

    213402-understand-next-hop-set-in-ibgp-advertis-04.png


    Die R2-Routing-Tabelle (Nexus NX-OS) zeigt die Route 1.1.1.1/32, die über EIGRP empfangen wurde, mit der ursprünglichen Next-Hop-IP von 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


    Der Befehl set ip next-hop redist-ohne ist im Konfigurationsmodus 'route-map' verfügbar.

    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


    Die route-map REDIST-UNCHANGED wird als Parameter für das Redistribution-Konfigurationsanweisung im BGP angewendet.

    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


    Router 3 empfängt das BGP-UPDATE mit dem ursprünglichen NEXT_HOP-Set, das dem Cisco IOS ähnelt.

    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 ?


    In diesem Dokument wird der Unterschied beschrieben, wie Nexus NX-OS und Cisco IOS iBGP-Meldungen für nicht lokal generierte Routen verarbeitet.

    Das in diesem Dokument beschriebene Verhalten wirkt sich in den meisten Fällen nicht auf die üblichen Routingvorgänge im Netzwerk aus.

    Die optionalen Befehle set ip next-hop redist unverändertes und set ipv6 next-hop redist-unverändertes sind verfügbar, um BGP-Routing gemäß RFC 4271 auf Nexus NX-OS beizubehalten


    Erstgerätekonfiguration

    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

    Beiträge von Cisco Ingenieuren

    • Hector Gustavo Serrano Gutierrez
      Cisco TAC-Techniker

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren