Switching de LAN : Protocolo de árbol de expansión

Resolver problemas el Spanning-tree PVID- y las Tipo-inconsistencias

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (20 Octubre 2015) | Comentarios


Contenido


Introducción

En las redes de Capa 2 (L2), sólo puede haber una trayectoria entre dos dispositivos cualesquiera. La redundancia es soportada por el Spanning-Tree Protocol (STP), que detecta y bloquea las trayectorias redundantes y, por lo tanto, evita el reenvío de los loops. Ciertas configuraciones incorrectas pueden resultar en una falla del STP y provocar la interrupción de la red. Para prevenir el tiempo inactividad, algunas mejoras fueron implementadas para que el STP detecte ciertos casos de configuración incorrecta y el puerto relevante se coloque en un estado “incoherente”.

Pueden existir diversos tipos de inconsistencias del STP:

Este documento explica cómo solucionar la causa detrás de las últimas dos incoherencias, de PVID y de tipo. Consulte los documentos previamente mencionados para resolver problemas con otras incoherencias.

prerrequisitos

Requisitos

Los lectores de este documento deben tener conocimiento sobre los conceptos de STP.

Componentes Utilizados

Este documento no se limita a una versión específica de software o de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Teoría de incoherencias de PVID y de tipo

Los switches de Cisco Catalyst implementan PVST mediante troncales Inter-Switch Link (ISL). Con el soporte de IEEE 802.1Q y de trunking ISL, se necesitaba una forma para ejecutar el interfuncionamiento entre el PVST y el concepto de IEEE 802.1Q de un solo spanning tree para todas las VLANs. La función PVST+ fue creada para cumplir este requisito.

Nota: Desde el punto de vista de STP, IEEE 802.1D no detecta la VLAN e IEEE 802.1Q detecta la VLAN, pero utiliza una instancia STP única para todas las VLAN. Es decir, si el puerto ejerce un bloqueo, lo hace para todas las VLANs de ese puerto. Lo mismo sucede con el reenvío.

Esta lista muestra cómo el PVST+ interactúa con el IEEE 802.1Q o el IEEE 802.1D, si la VLAN nativa en un trunk de IEEE 802.1Q es VLAN1:

  • Las VLAN1 STP BPDUs se envían a la dirección MAC de IEEE STP (0180.c200.0000), sin etiqueta.

  • Las VLAN1 STP BPDUs también se envían a la dirección MAC PVST+, sin etiqueta.

  • Las STP BPDUs que no son VLAN 1 se envían a la dirección MAC PVST+ (también llamada dirección MAC del Shared Spanning Tree Protocol [SSTP], 0100.0ccc.cccd), marcada con la etiqueta IEEE 802.1Q VLAN correspondiente.

Si la VLAN nativa en un trunk IEEE 802.1Q no es VLAN1:

  • Las VLAN1 STP BPDUs se envían a la dirección MAC PVST+, marcada con la etiqueta con una etiqueta IEEE 802.1Q VLAN correspondiente.

  • Las VLAN1 STP BPDUs también se envían a la dirección MAC IEEE STP en la VLAN nativa del trunk IEEE 802.1Q, sin etiqueta.

  • Las STP BPDUs que no son VLAN 1 se envían a la dirección MAC PVST+, marcada con una etiqueta IEEE 802.1Q VLAN correspondiente.

    Nota: Las STP BPDUs VLAN nativas se envían sin etiqueta.

Así, la VLAN1 STP del PVST+ se combina con el STP de IEEE 802.1D o 802.1Q, mientras que otras VLANs son tuneladas a través de la nube IEEE 802.1D o los bridges 802.1Q. Por ejemplo, la nube IEEE 802.1D o 802.1Q parece similar a un “cable” conectado a PVST+ VLANs diferentes de 1.

Para que el STP funcione correctamente, observe ciertas reglas cuando conecta los bridges PVST+ con el IEEE 802.1D o los bridges 802.1Q. La regla principal es que los bridges PVST+ deben conectarse con los bridges IEEE 802.1D o 802.1Q a través de un trunk del IEEE 802.1Q con una VLAN nativa constante en todos los bridges que se conectan con la nube de los bridges IEEE 802.1Q o 802.1D.

La PVST+ BPDU contiene un número VLAN que permite que los bridges PVST+ detecten si la regla anterior no se respetó. Cuando un switch Catalyst detecta una configuración incorrecta, los puertos correspondientes se colocan en estado “ incoherencia PVID” o “incoherencia de tipo”, que bloquea con eficacia el tráfico en la VLAN correspondiente en un puerto adecuado. Estos estados evitan el reenvío de los loops que provocan las configuraciones incorrectas o los cableados inadecuados.

Para ilustrar la necesidad de la detección de incoherencia, considere esta topología, donde los switches A y C ejecutan PVST+ STP y el switch B ejecuta 802.1Q STP:

/image/gif/paws/24063/pvid_inconsistency_24063a.gif

Si la BPDU de la raíz en la VLAN1 es mejor que la BPDU de la raíz en la VLAN2, no hay ningún puerto de bloqueo en la topología VLAN2. La BPDU de la VLAN2 nunca hace un “círculo completo” alrededor de la topología; es substituida por la VLAN1 BPDU en el link B-C, porque B ejecuta solamente un STP combinado con un VLAN1 STP de PVST+. Por lo tanto, hay un loop de reenvío. Afortunadamente, el switch A envía PVST+ BPDUs de VLAN2 (a la dirección SSTP que es inundada por el switch B) hacia el switch C. El switch C pondrá el puerto C-B en un estado de incoherencia de tipo, que previene el loop.

Nota: En algunos resultados de comandos, se hace referencia al estado STP *incoherente como “interrumpido”.

Cuando se detecta la incoherencia de STP, los switches envían estos mensajes de syslog:

%SPANTREE-2-RECV_1Q_NON_TRUNK: Received IEEE 802.1Q BPDU on non trunk
FastEthernet0/1 on vlan 1.
%SPANTREE-2-BLOCK_PORT_TYPE: Blocking FastEthernet0/1 on vlan 1.
Inconsistent port type.

%SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 3/25 vlan 1
%SPANTREE-2-RX_BLKPORTPVID: Block 3/25 on rcving vlan 1 for inc peer vlan 10
%SPANTREE-2-TX_BLKPORTPVID: Block 3/25 on xmtting vlan 10 for inc peer vlan

En ese ejemplo, la VLAN1 es el sitio en el que la BPDU fue recibida, y la VLAN10 es el sitio en el que la BPDU fue originada. Cuando se detecta la incoherencia, ambas VLANs se bloquean en el puerto en donde se recibe esta BPDU

Nota: Los mensajes pueden variar basado en el tipo y la versión del sistema operativo de la versión de software o del Catalyst OS (CatOS) de Cisco IOS� que es funcionando.

Nota: Si el puerto deja de recibir las BPDUs incoherentes, se borra el estado *incoherente y el STP cambia al estado de puerto en función de la operación STP normal. Se envía un mensaje de syslog para indicar el cambio:

%SPANTREE-SP-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on vlan 1.
Port consistency restored.

Para más detalles sobre la operación PVST+, consulte Bridging entre VLANs IEEE 802.1Q.

Resolución de problemas

Para ver la lista de puertos incoherentes, la implementación de STP basada en IOS reciente de Cisco soporta el comando show spanning-tree inconsistentports.

En la mayoría de los casos, la razón de la detección de la incoherencia de STP en el puerto es evidente:

  • El puerto de acceso recibe una SSTP BPDU etiquetada con IEEE 802.1Q.

    /image/gif/paws/24063/pvid_inconsistency_24063b.gif

    En este escenario, el puerto de acceso en el bridge A recibe, del bridge B, una PVST+ BPDU etiquetada desde el STP de una VLAN diferente de 1. El puerto en A será colocado en el estado de incoherencia de tipo.

    Nota: No es necesario conectar los switches directamente; si están conectados con uno o más switches IEEE 802.1D o IEEE 802.1Q, o incluso hubs, el efecto es el mismo.

  • El puerto de trunking IEEE 802.1Q recibe una SSTP BPDU sin etiqueta con una VLAN de tipo, longitud, valor (TLV) que no corresponde con la VLAN donde la BPDU fue recibida.

    /image/gif/paws/24063/pvid_inconsistency_24063c.gif

    En este escenario, el puerto trunk en A recibe una PVST+ BPDU desde el STP de la VLAN2 con una etiqueta de VLAN2. Esto acciona el puerto en A que se bloqueará en la VLAN1 y la VLAN2.

Si los dispositivos en ambos extremos de un link punto a punto son switches de Cisco Catalyst, un examen de la configuración del puerto local y remoto revela habitualmente la discrepancia de configuración:

  • El puerto se configura para el trunking IEEE 802.1Q en un lado pero el otro lado es puerto de acceso.

  • Los troncos IEEE 802.1Q están en ambos lados, pero las VLAN nativas son diferentes.

En estos casos, repare la discrepancia de configuración para resolver la incoherencia de STP.

En algunos casos, posiblemente no sea fácil identificar la razón:

  • Una BPDU se recibe de un medio compartido con dispositivos múltiples.

  • Se recibe una BPDU, de la nube del switch, que implementa un IEEE 802.1D o el modelo 802.1Q STP mientras que los switches PVST+ están conectados con la nube.

  • Una BPDU proviene de la parte posterior de un túnel (por ejemplo, nube Data Link Switch Plus [DLSw+], tunelización de protocolo L2, EoMPLS, Links de Trayectoria Virtual [VPLs] LAN Emulation [[LANE] y otros).

/image/gif/paws/24063/pvid_inconsistency_24063d.gif

En este ejemplo, el switch B se configura de forma incorrecta e inserta una SSTP BPDU en la nube. Esto hace que los puertos en los switches A, C, y D presenten una incoherencia de tipo. El problema es que el dispositivo que origina la BPDU “infractora” no está conectado directamente con los switches afectados. Por lo tanto, si hay muchos dispositivos en el trunk, puede llevar mucho tiempo resolver los problemas de todos ellos.

Afortunadamente, hay un enfoque sistemático para resolver problemas en estos casos:

  1. Establezca la dirección MAC de origen e ID del puente de envío de la BPDU. Esto debe realizarse mientras se produce el problema.

  2. Busque el bridge que origina la BPDU “infractora”. Esto se puede hacer después de un tiempo, no necesariamente cuando ocurre el problema.

Para el Paso 1, normalmente existen dos opciones: utilice un analizador de paquete o habilite el debug para ver el vaciado de las BPDU recibidas.

Para más detalles sobre el uso de un debug para vaciar STP BPDUs, consulte la sección Comandos de Debugging STP de Troubleshooting STP en el Catalyst Switch que ejecuta Cisco Integrated IOS (Modo Nativo).

Éste es un ejemplo de salida de debug que muestra la BPDU recibida:

*Mar 14 19:33:27: STP SW: PROC RX: 0100.0ccc.cccd<-0030.9617.4f08 type/len 0032
*Mar 14 19:33:27:     encap SNAP linktype sstp vlan 10 len 64 on v10 Fa0/14
*Mar 14 19:33:27:     AA AA 03 00000C 010B SSTP
*Mar 14 19:33:27:     CFG P:0000 V:00 T:00 F:00 R:8000 0050.0f2d.4000 00000000
*Mar 14 19:33:27:     B:8000 0050.0f2d.4000 80.99 A:0000 M:1400 H:0200 F:0F00
*Mar 14 19:33:27:     T:0000 L:0002 D:0001

Una vez que conozca la dirección MAC de origen y la ID del bridge del envío, debe buscar el dispositivo al cual pertenece esta dirección MAC. Esto se puede complicar por el hecho de que los switches típicamente no conocen las direcciones MAC de origen de las tramas BPDU. Si publica el comando show mac-address-table address BPDU_mac_address (para los switches basados en Cisco IOS) o el comando show cam mac_address (para los switches basados en CatOS), típicamente, no se encuentra ninguna entrada.

Una manera de encontrar la dirección MAC “infractora” es recoger, de todos los switches que estén conectados con la nube, la salida del show spanning-tree (para Cisco IOS) o el comando show spantree (para CatOS). Los resultados de estos comandos incluyen información acerca del ID de puente de cada puente.

Boris# show spanning-tree

!--- Use with Cisco IOS.

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    0
             Address     0007.4f1c.e847
             Cost        131
             Port        136 (GigabitEthernet3/8)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     00d0.003f.8800

!--- Output suppressed.

Doris (enable) show spantree

!--- Use with CatOS.

VLAN 1
Spanning tree mode          RAPID-PVST+
Spanning tree type          ieee
Spanning tree enabled
Designated Root             00-07-4f-1c-e8-47
Designated Root Priority    0
Designated Root Cost        123
Designated Root Port        9/7                     
Root Max Age   20 sec   Hello Time 2  sec   Forward Delay 15 sec
Bridge ID MAC ADDR          00-d0-03-ef-4c-00

!--- Output suppressed.

Nota: Según el modelo, la versión de software y la configuración, un switch puede tener múltiples direcciones MAC de ID de bridge. Afortunadamente, todas las direcciones se encontrarán, por lo general, dentro de cierto rango (por ejemplo, a partir de 0001.1234.5600 a 0001.1234.5640). Si usted conoce una dirección MAC de la ID de bridge puede verificar si la dirección MAC de envío de la ID de bridge (ubicada en el Paso 1) está dentro del rango de las direcciones MAC de ID de bridge determinadas.

Puede también utilizar las herramientas de administración de red para recoger las IDs de todos los bridges.

Una vez que haya encontrado el bridge que está enviando la BPDU “infractora”, debe verificar la configuración del puerto que está asociado a la nube: asegúrese de que sea coherente (trunking frente a no trunking y la VLAN nativa) con otros switches que se conecten a la misma nube.

Podría suceder que el bridge envíe las BPDU adecuadas, pero se modifican de forma incorrecta dentro de la nube de tunelización. En ese caso, puede ver que la BPDU “infractora” que ingresa a la nube es coherente con la configuración de los otros bridges, pero la misma BPDU se vuelve incoherente cuando sale de la nube (por ejemplo, la BPDU sale de la nube en una VLAN diferente, o se vuelve etiquetada o sin etiqueta). En tal caso, puede ayudar a verificar si la dirección MAC de origen de la BPDU “infractora” pertenece al mismo bridge que la ID del bridge de envío. En caso contrario, puede intentar localizar el bridge que posee la dirección MAC de origen de la BPDU y verificar su configuración.

Para localizar el switch que posee la dirección MAC de origen de la BPDU, ahora puede seguir el mismo enfoque que se utiliza para encontrar la ID de bridge, excepto el resultado del comando show module que se examina (para Catalyst 4000, 5000, y 6000). Para Catalyst 2900XL, 3500XL, 2950 y 3550, debe examinar el resultado del comando show interface para determinar las direcciones MAC que pertenecen a los puertos.

Cat4000-IOS# show module

!--- Use for Catalyst 4000,5000,6000

Mod  Ports Card Type                              Model             Serial No.
----+-----+--------------------------------------+-----------------+-----------
 1      2  1000BaseX (GBIC) Supervisor(active)    WS-X4515          ZZZ00000001
 5     14  1000BaseT (RJ45), 1000BaseX (GBIC)     WS-X4412-2GB-T    ZZZ00000002

 M MAC addresses                    Hw  Fw           Sw               Status
--+--------------------------------+---+------------+----------------+---------
 1 000a.4172.ea40 to 000a.4172.ea41 1.2 12.1(12r)EW  12.1(14)E1, EARL Ok
 5 0001.4230.d800 to 0001.4230.d80d 1.0                               Ok

!--- Output suppressed.

cat3550# show interface | i bia

  Hardware is Gigabit Ethernet, address is 0002.4b28.da80 (bia 0002.4b28.da80)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da83 (bia 0002.4b28.da83)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da86 (bia 0002.4b28.da86)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da88 (bia 0002.4b28.da88)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da89 (bia 0002.4b28.da89)

!--- Output suppressed.

Nota: Si la nube es DLSw+, consulte Cómo Comprender y Configurar DLSw y 802.1Q.

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.


Información Relacionada


Document ID: 24063