IP : Open Shortest Path First (OSPF)

Nota técnica del embalaje OSPF, MTU y LSA

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe la interacción de los paquetes del Open Shortest Path First (OSPF), de la unidad máxima de la transición (MTU), de los anuncios del estado del link (LSA), y los paquetes de actualización del estado del link (LS) en el contexto del Id. de bug Cisco CSCse01519.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

Tamaños de paquete OSPF

Los links en el Routers tienen un MTU. Los paquetes de salida, tales como paquetes OSPF, no pueden ser más grandes que el MTU de interfaz.

Versión 2 de los documentos de la Solicitud de comentarios (RFC) 2328 del protocolo OSPF. El apéndice A.1 del RFC 2328 describe la encapsulación de los paquetes OSPF de este modo:

El OSPF se ejecuta directamente sobre la capa de red del protocolo de Internet. Los paquetes OSPF por lo tanto son encapsulados solamente por las encabezados IP y del link de datos local.

El OSPF no define una manera de hacer fragmentos de sus paquetes del protocolo, y depende de fragmentación de IP cuando los paquetes transmisores más grandes que la red MTU. En caso necesario, la longitud de los paquetes OSPF puede ser hasta 65,535 bytes (encabezado IP incluyendo). Los tipos del paquete OSPF que son probables ser grandes (el Database Description Packets, enlaza el pedido de estado, conecta la actualización del estado, y los paquetes de reconocimiento del estado del link) pueden estar partidos generalmente en varios paquetes del protocolo separados, sin la pérdida de funcionalidad. Se recomienda esto; Fragmentación de IP debe ser evitado siempre que sea posible.

Puede haber uno o más LSA en un paquete de actualización LS. Muchos LSA en un paquete de actualización LS se conocen como pila de discos de los LSA en un paquete de actualización LS.

MTU adentro paquete DBD

El paquete de la descripción de la base de datos (DBD), también especificado en el RFC 2328, describe el contenido de la base de datos de estado de links OSPF:

        0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Version #   |       2       |         Packet length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Router ID                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Area ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |             AuType            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Authentication                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Authentication                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Interface MTU         |    Options    |0|0|0|0|0|I|M|MS
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     DD sequence number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-                      An LSA Header                          -+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-                                                             -+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |

El apéndice A.3.3 del RFC 2328 describe el MTU de interfaz como:

Los tamaños en los bytes del IP datagram más grande que se puede enviar la interfaz asociada, sin la fragmentación.

Routers que se asocia a un intercambio del link su valor del MTU de interfaz en los paquetes del DBD cuando se inicializa la adyacencia OSPF.

Sección 10.6 de los estados del RFC 2328:

Si el campo del MTU de interfaz en el paquete de la descripción de la base de datos indica los tamaños del IP datagram que son más grandes que el router puede validar en la interfaz de recepción sin la fragmentación, se rechaza el paquete de la descripción de la base de datos.

Cuando utilizan al comando debug ip ospf adj, usted puede ver la llegada de estos paquetes del DBD.

En este ejemplo, hay una discordancía en los valores MTU entre dos vecinos OSPF. Este router tiene MTU 1600:

OSPF: Rcv DBD from 10.100.1.2 on GigabitEthernet0/1 seq 0x2124 opt 0x52 flag 0x2 
len 1452 mtu 2000 state EXSTART
OSPF: Nbr 10.100.1.2 has larger interface MTU

El otro router para OSPF tiene MTU de interfaz 2000:

OSPF: Rcv DBD from 10.100.100.1 on GigabitEthernet0/1 seq 0x89E opt 0x52 flag 0x7 
len 32 mtu 1600 state EXCHANGE
OSPF: Nbr 10.100.100.1 has smaller interface MTU

Los paquetes del DBD se retransmiten continuamente hasta que la adyacencia OSPF se derribe eventual.

OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7 
len 32
OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [10]
OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7
len 32
OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [11]
%OSPF-5-ADJCHG: Process 1, Nbr 10.100.1.2 on GigabitEthernet0/1 from EXSTART to
DOWN, Neighbor Down: Too many retransmissions

LSA del comportamiento y de la pila de discos OSPF en un paquete de actualización LS

Antes del Id. de bug Cisco CSCse01519

Antes del Id. de bug Cisco CSCse01519, el OSPF en el software del ® del Cisco IOS construyó los paquetes OSPF ningunos bytes más grandes than1500, sin importar el MTU de interfaz. Así pues, si el MTU de interfaz era más grande de 1500 bytes, el OSPF todavía pila de discos solamente hasta 1500 bytes en un paquete OSPF. Esto era algo ineficaz porque el OSPF podría enviar paquetes más grandes en el link y alcanzar la mayor producción.

Nota: Había una excepción a este escenario. Si un LSA llevó a cabo más de 1500 bytes, el OSPF construyó ese paquete, ninguna materia los tamaños, porque el OSPF no puede hacer fragmentos de un LSA. La pila IP del router entonces hizo fragmentos del paquete para caber el MTU de la interfaz saliente. Esto ocurrió típicamente cuando un router para OSPF tenía muchos links, y el LSA de router llegó a ser más grande que el link MTU.

Semejantemente, si el MTU de la interfaz saliente era más pequeño de 1500 bytes, el proceso OSPF todavía construyó o pila de discos los paquetes OSPF encima de 1500 bytes, y la pila IP del router hizo fragmentos del paquete en paquetes más pequeños IP para caber el MTU del link saliente. Esto ocurrió típicamente con un túnel IPsec entre dos Routers que ejecutaba el OSPF. Los gastos indirectos agregados de los bytes de encapsulación del túnel llevaron a un MTU que era más pequeño de 1500 bytes. El OSPF construyó los paquetes OSPF hasta 1500 bytes y los paquetes entonces fueron hechos fragmentos antes de que el router los transmitiera. Esto era una ineficacia adicional.

Después del Id. de bug Cisco CSCse01519

Después del Id. de bug Cisco CSCse01519, el OSPF en el IOS puede pila de discos los paquetes OSPF para ser más grande de 1500 bytes. Esto ocurre si el MTU de la interfaz saliente es más grande de 1500 bytes. Las transmisiones son más eficientes porque más información se puede pila de discos en un paquete más grande. Es decir si un router para OSPF necesita transmitir mucho LSA externo a un vecino OSPF, puede pila de discos más LSA externo en un paquete de actualización LS si ese router ejecuta el IOS con el Id. de bug Cisco CSCse01519 implementado.

El Id. de bug Cisco CSCse01519 también permite que el OSPF construya bytes más pequeños de los paquetes de 1500. En algunos escenarios, el MTU entre dos vecinos OSPF es más pequeño de 1500 bytes. En el ejemplo anterior con un túnel IPsec, el OSPF transmite los paquetes OSPF que son más pequeños de 1500 bytes y los evita fragmentación de IP; otra vez, la excepción es el caso de un LSA que sea más grande que el MTU de interfaz.

Id. de bug Cisco CSCse01519

Cuando usted actualiza un router para OSPF, usted puede descubrir un problema OSPF MTU causado por el Id. de bug Cisco CSCse01519.

Información general

Muchas redes tienen los vecinos OSPF que están conectados a través de una red de switch de la capa 2 (L2), o red de transporte, comprendida del servicio L2VPN o de una red /Synchronous de la red óptica de la jerarquía digital sincrónica (SDH/SONET). Estas redes de transporte pueden tener diversas configuraciones de MTU que el Routers que está ejecutando el OSPF.

Aunque la configuración de MTU deba estar correcta en todo el Routers y deba reflejar el MTU verdadero, hay a menudo los errores que van inadvertidos.

Esto es una red de muestra con dos Routers que esté ejecutando el OSPF. El router1 (r1) y el router2 (r2) están conectados a través de un Switch L2.

116119-technote-ospf-mtu-01.jpg

En este ejemplo, el Routers tiene interfaces del gigabitethernet con un MTU fijado a 2000. El MTU del Switch L2 es solamente 1500 bytes.

Si los tamaños del tráfico de datos nunca son más grandes de 1500 bytes, usted puede utilizar el IOS sin el Id. de bug Cisco CSCse01519 porque los paquetes OSPF nunca son más grandes de 1500 bytes. Sin embargo, si hay un LSA que es 1800 bytes, por ejemplo, el proceso OSPF en el r1 o el r2 construye bytes más grandes de un paquete de actualización LS de 1500 y los transmite, pero el paquete es caído por el Switch L2 entre el Routers.

Si las bases de datos OSPF en el r2 tienen bastantes redes, los LSA localmente originados son tan grandes que un paquete de actualización LS pudo ser más grande que el MTU de interfaz.

  • Si estas redes son originadas por el comando network de la cubierta, las redes aparecen en el LSA de router del r2. El r2 construye un LSA de router que sea más grande de 2000 bytes y lo transmita, pero el IP hace fragmentos de él a 2000 bytes, el MTU de interfaz. El Switch L2 sin embargo cae estos paquetes. El OSPF entonces retransmite este paquete sin fin, y el estado de la adyacencia OSPF nunca es lleno. Así pues, el problema se descubre inmediatamente, incluso cuando usted está ejecutando el IOS sin el Id. de bug Cisco CSCse01519.
  • Si estas redes son originadas por el comando redistribute connected, las redes aparecen en el LSA externo. El OSPF intenta pila de discos el LSA externo en un paquete de actualización LS que sea hasta 1500 bytes de tamaño. En este caso, porque el MTU de interfaz es 2000 bytes, la adyacencia OSPF alcanza el estado “FULL”. La aplicación un MTU subyacente inadecuado no se descubre inmediatamente. El problema será descubierto cuando actualizan a un router al IOS con el Id. de bug Cisco CSCse01519.

Situación

Asuma que ambo Routers funciona con una versión de IOS sin el Id. de bug Cisco CSCse01519.

Cuando las estructuras de la adyacencia OSFP, notan que el r1 nunca recibe bytes más grandes de un paquete OSPF de 1500, aunque el MTU de las interfaces sea 2000.

Habilite el comando packets OSPF del IP del debug.

OSPF: rcv. v:2 t:1 l:48 rid:10.100.1.2
      aid:0.0.0.0 chk:72CF aut:0 auk: from GigabitEthernet0/1
...
OSPF: rcv. v:2 t:4 l:1468 rid:10.100.1.2
      aid:0.0.0.0 chk:8389 aut:0 auk: from GigabitEthernet0/1
OSPF: rcv. v:2 t:4 l:136 rid:10.100.1.2
...

En esta salida de los debugs, 'l:1468 es la longitud del paquete OSPF, así que usted puede ver que el paquete OSPF más grande era 1468 bytes. 't:4 indica que el paquete OSPF es el tipo 4, que es un paquete de actualización de estado del link. Esta tabla de la sección 4.3 del RFC 2328 define los diversos tipos del paquete OSPF:

TipoNombre del paqueteFunción del protocolo
1HelloDescubra/mantenga a los vecinos
2Descripción de la base de datosResuma el contenido de la base de datos
3Petición de estado de linkDescarga de la base de datos
4Actualización del estado de los linksActualización de base de datos
5Estado Ack del linkInundar el acuse de recibo

La adyacencia OSPF alcanza el estado “FULL”.

R1#show ip ospf neighbor gigabitEthernet 0/1

Neighbor ID    Pri   State         Dead Time   Address       Interface
10.100.1.2       0   FULL/  -      00:00:34    10.1.1.2      GigabitEthernet0/1

R2#show ip ospf neighbor gigabitEthernet 0/1

Neighbor ID    Pri   State         Dead Time   Address       Interface
10.100.100.1     0   FULL/  -      00:00:34    10.1.1.1      GigabitEthernet0/1

Después, IOS de la actualización en el r2 a una versión de IOS con el Id. de bug Cisco CSCse01519.

R2#show ip ospf neighbor gigabitEthernet 0/1

Neighbor ID    Pri   State         Dead Time   Address       Interface
10.100.100.1     0   LOADING/  -   00:00:33    10.1.1.1      GigabitEthernet0/1

R2#show ip ospf neighbor gigabitEthernet 0/1 detail
Neighbor 10.100.100.1, interface address 10.1.1.1
    In the area 0 via interface GigabitEthernet0/1
    Neighbor priority is 0, State is LOADING, 5 state changes
    DR is 0.0.0.0 BDR is 0.0.0.0
    Options is 0x12 in Hello (E-bit L-bit )
    Options is 0x52 in DBD (E-bit L-bit O-bit)
    LLS Options is 0x1 (LR)
    Dead timer due in 00:00:39
    Neighbor is up for 00:00:49
    Index 1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
    Number of retransmissions for last link state request packet 9
    Poll due in 00:00:00

R2#show ip ospf neighbor gigabitEthernet 0/1 detail
Neighbor 10.100.100.1, interface address 10.1.1.1
    In the area 0 via interface GigabitEthernet0/1
    Neighbor priority is 0, State is LOADING, 5 state changes
    DR is 0.0.0.0 BDR is 0.0.0.0
    Options is 0x12 in Hello (E-bit L-bit )
    Options is 0x52 in DBD (E-bit L-bit O-bit)
    LLS Options is 0x1 (LR)
    Dead timer due in 00:00:33
    Neighbor is up for 00:02:06
    Index 1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
    Number of retransmissions for last link state request packet 25
    Poll due in 00:00:03

%OSPF-5-ADJCHG: Process 1, Nbr 10.100.100.1 on GigabitEthernet0/1 from LOADING
to DOWN, Neighbor Down: Too many retransmissions

La adyacencia OSPF se pega en el estado del “CARGAMENTO” y no alcanza el estado “FULL”. Las retransmisiones ocurren hasta que el OSPF alcance su límite de 25 retransmisiones. El OSPF intenta establecer la adyacencia otra vez, el mismo problema ocurre de nuevo, y el loop continúa sin fin.

Así, la actualización en el r2 destapa un problema previamente ocultado: el MTU subyacente es más pequeño que el que está usado por los routeres para OSPF.

Cuando el Switch cambia el MTU a 2000, bytes más grandes de un paquete OSPF de 1500 ('l:1980) se transmiten sin el problema.

R1#
OSPF: rcv. v:2 t:3 l:1980 rid:10.100.1.2
      aid:0.0.0.0 chk:AC5B aut:0 auk: from GigabitEthernet0/1

Para marcar los problemas MTU que son la base, haga ping siempre la dirección IP del vecino OSPF con los tamaños iguales al MTU y al conjunto de bits DF (Don't Fragment).

Para descubrir el valor del MTU subyacente, realizar un ping, y barrer los tamaños. Cuente el número de signos de exclamación (!) en la salida para determinar el MTU correcto. En este ejemplo, la Respuesta de eco más reciente del comando ping tiene bytes de la talla 1500.

R2#ping
Protocol [ip]:
Target IP address: 10.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: yes
Sweep min size [36]: 1460
Sweep max size [18024]: 1540
Sweep interval [1]:
Type escape sequence to abort.
Sending 81, [1460..1540]-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.............................
...........
Success rate is 49 percent (40/81), round-trip min/avg/max = 1/1/4 ms

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116119