Ejemplo de Configuración de Loop de Ruteo OSPF/Ruteo Sub-Óptimo entre Cisco IOS y NXOS para Rutas Externas

Opciones de descarga

  • PDF     (181.2 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (135.7 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (127.0 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:2 de julio de 2014
ID del documento:117824

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 cómo se implementa el protocolo Open Shortest Path First (OSPF) entre la función Nexus y Cisco IOS® en Cisco IOS y Nexus Operating System (NXOS).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento del protocolo OSPF.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Versión 6.2(6a) de NXOS
  • Cisco IOS versión 15.1(4)M1

Antecedentes

Los dispositivos Cisco IOS admiten RFC 1583. Sin embargo, NXOS admite RFC 2328 y hay diseños en los que esta diferencia puede crear loops de ruteo en la red cuando hay rutas OSPF externas en la red.

Información importante

En esta sección se analiza la diferencia entre RFC 1583 y RFC 2328 en lo que respecta a cómo elegir la mejor ruta entre varias rutas externas.

Resumen de RFC 1583, sección 16.4.6

Para comparar trayectorias externas de tipo 1, observe la suma de la distancia a la dirección de reenvío y la métrica de tipo 1 anunciada (X+Y).  Para comparar trayectorias externas de Tipo 2, observe las métricas de Tipo 2 anunciadas y, si es necesario, la distancia a las direcciones de reenvío.

Si la nueva trayectoria es más corta, reemplaza las trayectorias actuales en la entrada de la tabla de ruteo.  Si la nueva trayectoria es del mismo costo, se agrega a la lista de trayectorias de la entrada de la tabla de ruteo.

Nota: Si la dirección de reenvío es de coste cero, se utiliza el router de límite del sistema autónomo (ASBR) para elegir la mejor ruta.

Resumen de RFC 2328 Sección 16.4.1

Los trayectos dentro del área que utilizan áreas no troncales siempre son los preferidos. Las otras trayectorias, trayectos de estructura básica dentro del área y trayectos entre áreas son de igual preferencia.

Configurar

Escenario 1

Diagrama de la red

R3 y R4 redistribuyen la misma red 172.16.1.0/24 con la misma métrica que la ruta externa tipo E2 OSPF. R6 prefiere la ruta anunciada por R3 porque la métrica de reenvío al ASBR R3 es menor que a R4 y el salto siguiente para 172.16.1.0/24 es R1. (Según RFC 1583, la selección de la ruta se basa únicamente en el costo.)

R6#sh ip ospf border-routers

OSPF Router with ID (192.168.6.6) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 192.168.4.4 [51] via 192.168.56.5, GigabitEthernet0/0, ASBR, Area 2, SPF 17 
 >>>> Cost is 51 to reach R4 ASBR.
i 192.168.1.1 [1] via 192.168.16.1, GigabitEthernet0/1, ABR, Area 2, SPF 17
I 192.168.3.3 [42] via 192.168.16.1, GigabitEthernet0/1, ASBR, Area 2, SPF 17
 >>>> Cost is 42 to reach R3 ASBR

R6#sh ip route 172.16.1.0
Routing entry for 172.16.1.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 42
Last update from 192.168.16.1 on GigabitEthernet0/1, 00:02:13 ago
Routing Descriptor Blocks:
* 192.168.16.1, from 192.168.3.3, 00:02:13 ago, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1

R1 prefiere la ruta anunciada por R4 a pesar del mayor costo porque es una ruta dentro del área a ASBR. La ruta no pasa a través del área de estructura básica y el salto siguiente es R6 (según RFC 2328).

R1-NXOS# sh ip ospf border-routers
OSPF Process ID 1 VRF default, Internal Routing Table
Codes: i - Intra-area route, I - Inter-area route

intra 192.168.2.2 [40], ABR, Area 0.0.0.0, SPF 18
via 192.168.12.2, Eth4/43
inter 192.168.3.3 [41], ASBR, Area 0.0.0.0, SPF 18 >>>> Cost is 41
via 192.168.12.2, Eth4/43
intra 192.168.4.4 [91], ASBR, Area 0.0.0.2, SPF 18 >>>> Cost is 91
via 192.168.16.6, Eth4/44

switch-R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.1.0/24, ubest/mbest: 1/0
*via 192.168.16.6, Eth4/44, [110/20], 00:10:41, ospf-1, type-2

Esto provoca un loop en la red ya que R6 envía los paquetes a R1 y R1 los envía de vuelta a R6.

R5#traceroute 172.16.1.1 numeric
 Type escape sequence to abort.
Tracing the route to 172.16.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.56.6 4 msec 0 msec 0 msec
2 192.168.16.1 4 msec 0 msec 4 msec
3 192.168.16.6 0 msec 4 msec 0 msec
4 192.168.16.1 4 msec 0 msec 4 msec
5 192.168.16.6 0 msec 4 msec 0 msec

Como puede ver, el paquete se mueve entre R1 y R6. Para resolver este problema, debe cambiar la compatibilidad RFC en el NXOS.

R1-NXOS(config)# router ospf 1
R1-NXOS(config-router)# rfc1583compatibility

switch-R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.1.0/24, ubest/mbest: 1/0
*via 192.168.12.2, Eth4/43, [110/20], 00:00:40, ospf-1, type-2

Ahora, R1 lo señala correctamente a R2 y el loop se elimina de la red.

R5#traceroute 172.16.1.1 numeric
Type escape sequence to abort.
Tracing the route to 172.16.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.56.6 0 msec 4 msec 0 msec
2 192.168.16.1 0 msec 0 msec 0 msec
3 192.168.12.2 4 msec 0 msec 0 msec
4 192.168.23.3 4 msec 0 msec 4 msec
5 192.168.23.3 4 msec 0 msec 4 msec

Escenario 2

Diagrama de la red

R1 recibe una ruta NSSA-Externa (Tipo 7) de R6 y una ruta externa (Tipo 5) de R2 para el mismo prefijo 172.16.1.0/24. R1 prefiere el Tipo 7, aunque normalmente en OSPF Tipo 5 se prefiere sobre el Tipo 7.

R1-NXOS# sh ip ospf database nssa-external 172.16.1.0 detail
OSPF Router with ID (192.168.1.1) (Process ID 1 VRF default)

Type-7 AS External Link States (Area 0.0.0.2)

   LS age: 914
   Options: 0x28 (No TOS-capability, Type 7/5 translation, DC)
   LS Type: Type-7 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.4.4                 >>>>> Type 7 originated by R4
 and installed in the RIB.
   LS Seq Number: 0x80000001
   Checksum: 0x3696
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)
         TOS: 0
         Metric: 20
         Forward Address: 192.168.45.4
         External Route Tag: 0>


R1-NXOS# sh ip ospf database external 172.16.1.0 detail
 OSPF Router with ID (192.168.1.1) (Process ID 1 VRF default)


Type-5 AS External Link States

    LS age: 853
   Options: 0x2 (No TOS-capability, No DC)
   LS Type: Type-5 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.1.1         >>>>> Since Type 7 is installed
 in the RIB, it was converted to type 5
   LS Seq Number: 0x80000001
   Checksum: 0xb545
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)
         TOS: 0<
         Metric: 20
         Forward Address: 192.168.45.4
         External Route Tag: 0<

   LS age: 596
   Options: 0x20 (No TOS-capability, DC)
   LS Type: Type-5 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.3.3              >>>>>>  Type 5 is also received from R3
   LS Seq Number: 0x80000002
   Checksum: 0x2250
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)>
         TOS: 0
         Metric: 20<>
         Forward Address: 0.0.0.0
         External Route Tag: 0


R1-NXOS# sh ip route 172.16.1.0
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>

172.16.1.0/24, ubest/mbest: 1/0
    *via 192.168.16.6, Eth4/44, [110/20], 00:16:54, ospf-1, nssa type-2     >>>> Type 7
 route is installed in RIB.

Dado que R1 no tiene el comando rfc1583Compatibility configurado bajo el proceso del router OSPF y que el anuncio de estado de link de tipo 5 (LSA) adv-router-id de la ruta es alcanzable en el área 0 (router de estructura básica), OSPF siempre toma la ruta para la ruta a través del área de estructura no básica. En este caso, el salto siguiente se elige en el área 2 (según RFC 2328).

R1-NXOS(config)# router ospf 1
R1-NXOS(config-router)# rfc1583compatibility

R1-NXOS# sh ip route 172.16.1.0
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>

172.16.1.0/24, ubest/mbest: 1/0
    *via 192.168.12.2, Eth4/43, [110/20], 00:00:04, ospf-1, type-2     >>>> Type 5
 route is installed in RIB.

Recomendación

Hay otros escenarios de diseño o de red donde este problema de compatibilidad puede causar loops o ruteo subóptimo en la red si la red tiene NXOS y Cisco IOS que se ejecutan junto con OSPFv2.

Cisco recomienda utilizar el comando de compatibilidad RFC 1583 en el modo de configuración del router OSPF NXOS si la red incluye dispositivos que solamente soportan RFC1583, es decir, Cisco IOS.

Verificación

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

TAC Authored

Con la colaboración de ingenieros de Cisco

  • Sumit Kothiyal and Vinod Sharma
    Cisco TAC Engineers.

¿Resultó útil este documento?

FeedbackComentarios

Contacte a Cisco

Este documento se aplica a estos productos