cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
39228
Views
5
Helpful
10
Replies

Spanning Tree Issue

utawakevou
Level 4
Level 4

Got this issue spanning tree issues recently that blocks the main link between my Cisco 3750 (stacked) and a HP4204vl. Things were working okay since it was installed and somehow something must have change (unaware) that cause this. My knowledge of spanning tree there must be an alternative link that link these two equipments that must have block the main trunk and the only trunk. There is no physical connectivity I know off that provides an alternative link. The only solution that I did was to stop the propagation of the concerned VLAN on the HP switch propergating to the Cisco. This somehow fix it. Anyway, this is the console message that comes up when the link was blocked:

4d21h: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel1 on MST0. Port consistency restored.tor
4d21h: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 209 on Port-channel1 VLAN7.
4d21h: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel1 on MST0. Inconsistent local vlan.
4d21h: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel1 on MST0. Port consistency restored.
4d21h: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 209 on Port-channel1 VLAN7.
4d21h: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel1 on MST0. Inconsistent local vlan.

So what I did was remove VLAN 7 from the trunk on the HP end

Am also attaching herewith how the setup looks

Am running MSTP on both Cisco and HP at my end. At the HQ end STP is disabled on the HP

Hope someone helps

1 Accepted Solution

Accepted Solutions

No, you need to configure bpdu filter on the cisco switches because those are the one's sending bpdu's.

Configuring MST over the WAN-link is not a good idea, especially because you cannot build a contiguous region. It will be separated by the non-stp enabled hp switches. I would even find it discutable whether you should allow stp on the WAN.

Personally I would never do this, layer 3 connectivity is much more stable and reliable.

Anyway, I am curious to hear how this scenario evoloves. Keep us posted!

regards,

Leo

View solution in original post

10 Replies 10

songjs1983
Level 1
Level 1

The messages comes from inconsistencies of (Native) VLAN ID or port types between switches. Thus, you should verify that the configurations of the native VLAN ID is consistent on the interfaces on each end of the 802.1Q trunk connection. When the configurations are consistent, spanning tree would automatically unblock the interfaces.

This is the show VLAN on both the Cisco and HP

HP

Status and Counters - VLAN Information

  Maximum VLANs to support : 20
  Primary VLAN : MGNT-VLAN
  Management VLAN :

  802.1Q VLAN ID Name         Status       Voice
  -------------- ------------ ------------ -----
  1              MGNT-VLAN    Port-based   No
  2              SERVER-VLAN  Port-based   No
  3              PRINTER-VLAN Port-based   No
  4              CLIENT-VLAN  Port-based   No
  5              VoIP-VLAN    Port-based   Yes
  6              LOTUVOIPVLAN Port-based   Yes
  7              SATLINK      Port-based   No
  28             ISCSI-1      Port-based   No
  29             ISCSI-2      Port-based   No
  52             STAFF_WLS    Port-based   No
  53             HOSTING      Port-based   No
  54             STAFF_REMOTE Port-based   No
  55             GUEST_VLAN   Port-based   No
  102            RB           Port-based   No
  121            SOPAC_LINK   Port-based   No
  122            SPBEA_LINK   Port-based   No

Cisco

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/22, Gi1/0/25, Gi1/0/26, Gi1/0/27
                                                Gi1/0/28, Gi2/0/19, Gi2/0/20, Gi2/0/21
                                                Gi2/0/22, Gi2/0/25, Gi2/0/26, Gi2/0/27
                                                Gi2/0/28
2    SERVER-VLAN                      active    Gi1/0/15, Gi1/0/16, Gi1/0/17, Gi1/0/18
                                                Gi1/0/19, Gi1/0/20, Gi1/0/21, Gi2/0/15
                                                Gi2/0/16, Gi2/0/17, Gi2/0/18
3    PRINTER-VLAN                     active
4    CLIENT-VLAN                      active
5    VoIP-VLAN                        active
6    LOTUVOIPVLAN                     active
7    SATLINK                          active
28   ISCSI-1                          active    Gi1/0/1, Gi1/0/2, Gi1/0/3, Gi1/0/4
                                                Gi1/0/5, Gi1/0/6, Gi1/0/7, Gi1/0/8
29   ISCSI-2                          active    Gi2/0/1, Gi2/0/2, Gi2/0/3, Gi2/0/4
                                                Gi2/0/5, Gi2/0/6, Gi2/0/7, Gi2/0/8
30   ISCSI-3                          active
31   ISCSI-4                          active
52   STAFF_WLS                        active
53   HOSTING                          active
54   STAFF_REMOTE                     active
55   GUEST_VLAN                       active
102  RB                               active
121  SOPAC_LINK                       active
122  SPBEA_LINK                       active

Do you mean inconsistencies in naming ? Notice that my VLAN 1 on the Cisco cannot be named as the VLAN 1 on the HP

"Thus, you should verify that the configurations of the native VLAN ID is consistent on the interfaces on each end of the 802.1Q trunk connection." meant that check the NATIVE VLAN IDs on the trunk interfaces

on the cisco switch, you could check with "show interface trunk" commend

Port        Mode         Encapsulation  Status        Native vlan

Fa0/1       on           802.1q         trunking      1

"show interface trunk" result as follows


Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/9     on           802.1q         trunking      1
Gi1/0/10    on           802.1q         trunking      1
Gi1/0/11    on           802.1q         trunking      1
Gi1/0/12    on           802.1q         trunking      1
Gi1/0/13    on           802.1q         trunking      1
Gi1/0/14    on           802.1q         trunking      1
Gi2/0/9     on           802.1q         trunking      1
Gi2/0/10    on           802.1q         trunking      1
Gi2/0/11    on           802.1q         trunking      1
Gi2/0/12    on           802.1q         trunking      1
Gi2/0/13    on           802.1q         trunking      1
Gi2/0/14    on           802.1q         trunking      1
Po1         on           802.1q         trunking      1

Switch is stacked and interface Po1 is the link to the HP switch. The other interface above links to ESX servers (vmware)

then, check the other, verify the consistency, which means please check NATIVE VLAN ID whether it is same as the counterpart of the Cisco switch.

This is an interesting problem because the only place where I see an instance of vlan 209 is at HQ.

Normally it would not be possible for these bpdu's to traverse the wan-link except when it is in bridging mode.

The bpdu's you get are probably pvst+ coming from the 3750 at HQ. Because the neighbor is a non-cisco switch, the frames are sent over the non-cisco domain as multicasts which are not recognized as bpdu's by the HP switches, only by cisco switches. That is probably how they end up in the middle of your mst undetected.

The easiest way to fix this is to ask your collegues at HQ to configure spanning-tree bpdufilter on the 3750, namely on the port facing the HP switch.

This will stop the port from sending bpdu's. If this was indeed the root cause, it should stop after changing this setting.

However, I find this situation quite special because one does not expect the link from HQ to your site to forward layer2 frames.

That is something which also requires further investigation. A failed experiment with multicasting perhaps?

regards,

Leo

Thanks lgijssel. This is what we initially thought so we did configure  spanning-tree bpdufilter on the ports (on the HP end) where our sattelite modems are connected to. We did this on both HP at the remote and at the HQ end. So do we need to do it on the HQ Cisco as well ? How about changing the spanning tree protocol at the HQ end to MSTP. Notice the HP models we have doesnt support pvst

No, you need to configure bpdu filter on the cisco switches because those are the one's sending bpdu's.

Configuring MST over the WAN-link is not a good idea, especially because you cannot build a contiguous region. It will be separated by the non-stp enabled hp switches. I would even find it discutable whether you should allow stp on the WAN.

Personally I would never do this, layer 3 connectivity is much more stable and reliable.

Anyway, I am curious to hear how this scenario evoloves. Keep us posted!

regards,

Leo

Did a run sniffer and monitor the port where my sat modem is connected and found out PVST+ bpdu coming in from HQ Cisco. So it was passing through. We change the HQ switch to use MST and then apply the bpdu filters. This fix it for us. By the way, the sat modems are connected directly to the switches at each end and the smoothwall FW doing the routing for VoIP/Video only over the sat link . Which means bpdu exiting from HQ via sat modem will have nothing stopping it from landing on the switch at my end. So I think the reason why my trunk link between HP and Cisco at server room A shuts down because Cisco in HQ was running the default stp i.e PVST. I might be wrong

Thanks for all you contribution

will
Level 3
Level 3

If all other answers are coming up short, verify that the native vlan for the port-channel, or trunk is defined on both sides of the switch trunk link. for example:

vlan 999
name native

 

and that the spanning tree versions; i.e. rapid-pvst is the same on both sides.

Review Cisco Networking for a $25 gift card