Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

iBGP-Werbung

Nexus NX-OS-Fall

Cisco IOS-Fall

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

Erstgerätekonfiguration

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

Topologie für Cisco IOS-Fall

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.

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.

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:

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

!