Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Informazioni sulle pubblicità iBGP

Caso Nexus NX-OS

Cisco IOS Case

Uso del comando set ip next-hop redist-unchanged

Configurazione iniziale dispositivi

Introduzione

In questo documento viene descritto il comportamento dell'attributo path NEXT_HOP quando impostato per gli annunci iBGP (Interior Border Gateway Protocol) su piattaforme basate su Nexus NX-OS e Cisco IOS (incluso Cisco IOS-XE). Questa opzione è destinata agli annunci di route non originate localmente.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Border Gateway Protocol (BGP)

- Ridistribuzione dei protocolli di routing

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware:

- Nexus 7000 con NX-OS versione 7.3(0)D1(1)

- Router Cisco con Cisco IOS versione 15.6(2)T

Gli output di questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

- Nelle piattaforme Nexus basate su NX-OS, per le route non originate localmente, gli annunci iBGP modificano l'attributo NEXT_HOP e lo impostano con il proprio indirizzo IP dell'interfaccia locale.

- Sulle piattaforme Cisco IOS, per le route non originate localmente, gli annunci iBGP mantengono l'attributo NEXT_HOP della route originale invariato.

Il comportamento di Nexus NX-OS può corrispondere a quello di Cisco IOS, se lo si desidera, grazie alle modifiche del codice introdotte dal difetto CSCud20941.

Nota: applicabile solo per gli annunci iBGP e non per eBGP.

Nota: Applicabile per route non originate localmente configurate come route statiche o ricevute tramite un protocollo IGP (Interior Gateway Protocol), ad esempio EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First) o RIP (Routing Information Protocol).

Informazioni sulle pubblicità iBGP

Per comprendere il set NEXT_HOP negli annunci iBGP, prendere come esempio i diagrammi della topologia di rete mostrati nelle immagini.

Topologia per il caso Nexus NX-OS

Topologia per il caso Cisco IOS

Caso Nexus NX-OS

In Topologia per il caso Nexus NX-OS, R2 (Nexus NX-OS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo pubblicizza con l'uso di iBGP al router 3, come mostrato nell'immagine.

La tabella di routing di R2 (Nexus NX-OS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP originale dell'hop successivo della versione 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

Nella sezione di configurazione BGP è possibile visualizzare i comandi in uso per annunciare il sito 1.1.1.1/32 tramite iBGP al router 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

Sul router 3, la route 1.1.1.1/32 viene ricevuta tramite iBGP con l'hop successivo impostato sull'indirizzo IP di R2 (Nexus NX-OS), ossia 10.2.3.2

- Voce della tabella BGP del router 3 per 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

- Voce della tabella di routing del router 3 per 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 Case

In Topologia per il caso Cisco IOS, R2 (Cisco IOS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo annuncia con l'uso di iBGP al router 3, come mostrato nell'immagine.

La tabella di routing di R2 (Cisco IOS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP dell'hop successivo originale di 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

Nella sezione di configurazione BGP è possibile visualizzare i comandi in uso per annunciare il file 1.1.1.1/32 tramite iBGP al 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

Sul router 3, è possibile vedere la route 1.1.1.1/32 ricevuta tramite iBGP con l'hop successivo originale impostato sull'IP sul router 1, ossia 10.1.2.1.

- Voce della tabella BGP del router 3 per 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 questo scenario specifico, il percorso del router 3 deve essere 10.1.2.1 (l'hop successivo) in modo che BGP possa considerarlo valido. In caso contrario, BGP visualizza il percorso come (inaccessibile).

Nota: Questo è un controllo di base descritto nell'algoritmo di selezione del miglior percorso BGP per accettare le route da BGP alla tabella di routing.

Il comando debug ip bgp update mostra il motivo per cui il router 3 non installa la route: non è presente alcuna voce nella tabella di routing per l'hop successivo, in questo caso l'hop successivo è 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

Un approccio per rendere accessibile l'hop successivo è:

- Passaggio 1. Un percorso statico nella tabella di routing del router 3 viene configurato per creare una voce per l'hop successivo.

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

- Passaggio 2. Lo stesso comando debug indica che la route è ora accettata.

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#

- Passaggio 3. La tabella BGP ha rimosso lo stato (inaccessibile).

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

- Passaggio 4. La tabella di routing installa il percorso su 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

Uso del comando set ip next-hop redist-unchanged

A partire dalla versione 6.2(12), i comandi set ip next-hop redist-unchanged e set ipv6 next-hop redist-unchanged sono stati introdotti da CSCud20941 per fare in modo che Nexus NX-OS rispecchi il comportamento di Cisco IOS.

Nota: Questi comandi funzionano solo quando vengono utilizzati come parametri in una route-map e vengono utilizzati in combinazione con il comando redistribution.

In Topologia per il caso Nexus NX-OS, R2 (Nexus NX-OS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo pubblicizza con iBGP al router 3, come mostrato nell'immagine:

La tabella di routing di R2 (Nexus NX-OS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP originale dell'hop successivo della versione 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

il comando set ip next-hop redist-unchanged è disponibile nella modalità di configurazione '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 viene applicata come parametro per l'istruzione redistribute configuration in 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

A questo punto, il router 3 riceve il messaggio BGP UPDATE con il comando NEXT_HOP originale impostato su 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 ?

Questo documento descrive la differenza di modalità con cui Nexus NX-OS e Cisco IOS gestiscono gli annunci iBGP di route non generate localmente.

Il comportamento descritto in questo documento si riferisce alla maggior parte degli scenari possibili e non ha alcun impatto sulle normali operazioni di routing della rete.

I comandi opzionali set ip next-hop redist-unchanged e set ipv6 next-hop redist-unchanged sono disponibili per mantenere il routing BGP conforme alla RFC 4271 su Nexus NX-OS

Configurazione iniziale dispositivi

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

!