Comprender el siguiente salto establecido en los anuncios de iBGP en Nexus NX-OS frente a Cisco IOS

Opciones de descarga

  • PDF     (385.7 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (352.1 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (209.2 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:12 de junio de 2018
ID del documento:213402

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).


    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
!


    TAC Authored

    Con la colaboración de ingenieros de Cisco

    • Hector Gustavo Serrano Gutierrez
      Cisco TAC Engineer

    ¿Resultó útil este documento?

    FeedbackComentarios

    Contacte a Cisco