Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Comprender los anuncios de iBGP

Caso de Nexus NX-OS

Caso de Cisco IOS

Uso del comando set ip next-hop redist-inalterado

Configuración inicial de dispositivos

Introducción

Este documento describe el comportamiento del atributo de trayectoria NEXT_HOP cuando se establece para anuncios de protocolo de gateway de borde interior (iBGP) en las plataformas basadas en Nexus NX-OS frente a Cisco IOS (esto incluye Cisco IOS-XE). Esto es para anuncios de rutas no originadas localmente.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- Border Gateway Protocol (BGP)

- Redistribución de Protocolos de Ruteo

Componentes Utilizados

La información incluida en este documento no se limita a versiones específicas de software o hardware:

- Nexus 7000 que ejecuta NX-OS versión 7.3(0)D1(1)

- Router de Cisco que ejecuta la versión 15.6(2)T del IOS de Cisco

Los resultados de este documento se tomaron de dispositivos en un entorno de laboratorio específico. Todos los dispositivos utilizados en este documento se iniciaron con una configuración (predeterminada) despejada. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

- En las plataformas basadas en Nexus NX-OS, para las rutas no originadas localmente, los anuncios iBGP modifican el atributo NEXT_HOP y lo establece con su propia dirección IP de interfaz local.

- En las plataformas basadas en Cisco IOS, para las rutas no originadas localmente, los anuncios iBGP mantienen el atributo NEXT_HOP de la ruta original tal como está.

El comportamiento en Nexus NX-OS puede coincidir con el observado en Cisco IOS si lo desea, gracias a los cambios de código introducidos por el defecto CSCud20941.

Nota: Esto sólo se aplica a los anuncios iBGP y no a eBGP.

Nota: Aplicable a las rutas no originadas localmente configuradas como rutas estáticas o recibidas a través de cualquier protocolo de gateway interior (IGP), como el protocolo de routing de gateway interior mejorado (EIGRP), el protocolo de ruta de acceso más corta primero (OSPF) o el protocolo de información de routing (RIP).

Comprender los anuncios de iBGP

Para comprender el conjunto NEXT_HOP en los anuncios iBGP, tome como ejemplo los diagramas de topología de red mostrados en las imágenes.

Topología para el caso Nexus NX-OS

Topología para el caso de Cisco IOS

Caso de Nexus NX-OS

En el caso Topology for Nexus NX-OS, R2 (Nexus NX-OS) recibe la ruta 1.1.1.1/32 a través de EIGRP desde el router 1 y la anuncia con el uso de iBGP al router 3 como se muestra en la imagen.

La tabla de routing R2 (Nexus NX-OS) muestra la ruta 1.1.1.1/32 recibida a través de EIGRP y con la IP de siguiente salto original 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

En la sección de configuración de BGP puede ver los comandos implementados para anunciar 1.1.1.1/32 vía 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

En el Router 3, la ruta 1.1.1.1/32 se recibe a través de iBGP con el salto siguiente ahora configurado en la dirección IP de R2 (Nexus NX-OS) que es 10.2.3.2

- Entrada de tabla BGP del Router 3 para 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

- Entrada de la Tabla de Ruteo del Router 3 para 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

Caso de Cisco IOS

En el caso Topology for Cisco IOS, R2 (Cisco IOS) recibe la ruta 1.1.1.1/32 a través de EIGRP del Router 1 y la anuncia con el uso de iBGP al Router 3 como se muestra en la imagen.

La tabla de routing R2 (Cisco IOS) muestra la ruta 1.1.1.1/32 recibida a través de EIGRP y con la IP de siguiente salto original 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

En la sección de configuración de BGP puede ver los comandos implementados para anunciar 1.1.1.1/32 vía 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

En el Router 3, puede ver la ruta 1.1.1.1/32 recibida a través de iBGP con el siguiente salto original configurado a la IP en el Router 1 que es 10.1.2.1.

- Entrada de tabla BGP del Router 3 para 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

En este escenario específico, el Router 3 debe tener una trayectoria a 10.1.2.1 (el Siguiente Salto) para que BGP pueda considerar la trayectoria como válida. De lo contrario, BGP muestra la ruta como (inaccesible).

Nota: Esta es una verificación básica descrita en Algoritmo de Selección de la Mejor Trayectoria de BGP para aceptar las rutas de BGP a la Tabla de Ruteo.

El comando debug ip bgp update muestra la razón por la que el Router 3 no instala la ruta porque no hay entrada en su tabla de ruteo para el salto siguiente, en este caso el salto siguiente es 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 enfoque para hacer accesible el salto siguiente es:

-Paso 1. Se configura una ruta estática en la tabla de ruteo del router 3 para crear una entrada para el salto siguiente.

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

-Paso 2. El mismo comando debug muestra que la ruta ahora se acepta.

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#

-Paso 3. La tabla BGP ha eliminado el estado (inaccesible).

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

-Paso 4. La tabla de ruteo instala ahora la ruta a 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-inalterado

Desde la versión 6.2(12), los comandos set ip next-hop redist-inalterado y set ipv6 next-hop redist-inalterado fueron introducidos por defecto CSCud20941 para hacer que Nexus NX-OS refleje el comportamiento de Cisco IOS.

Nota: Estos comandos sólo funcionan cuando se utilizan como parámetros en un route-map y se utilizan en combinación con el comando redistribution.

En el caso Topology for Nexus NX-OS, R2 (Nexus NX-OS) recibe la ruta 1.1.1.1/32 a través de EIGRP desde el router 1 y la anuncia con iBGP al router 3 como se muestra en la imagen:

La tabla de routing R2 (Nexus NX-OS) muestra la ruta 1.1.1.1/32 recibida a través de EIGRP y con la IP de siguiente salto original 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

El comando set ip next-hop redist-inalterado está disponible en el modo de configuración '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

route-map REDIST-UNCHANGED se aplica como parámetro para la instrucción de configuración redistribute en 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

Ahora el Router 3 recibe la ACTUALIZACIÓN BGP con el conjunto NEXT_HOP original similar al IOS de Cisco.

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 ?

Este documento describe la diferencia de cómo Nexus NX-OS y Cisco IOS manejan los anuncios iBGP de rutas no generadas localmente.

El comportamiento descrito en este documento se aplica a la mayoría de los escenarios y no afecta a las operaciones de ruteo de red habituales.

Los comandos opcionales set ip next-hop redist-inalterado y set ipv6 next-hop redist-inalterado están disponibles para mantener el ruteo BGP conforme con RFC 4271 en Nexus NX-OS

Configuración inicial de dispositivos

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

!