Comware

Hi,

I have an HP ProCurve 5308 connected to a Cisco 3750 stack and am having some issues. The two pieces of equipment are connected with an etherchannel(HP trunk) for redundancy. They have been connected for a couple of months with no issues. Until this week, only two vlans had been tagged on the connection from the 5308 to the 3750 - well, tagged is not exactly accurate - one was tagged (vlan 10) and the other untagged (vlan 1) in order to match the native vlan on the Cisco. This week, I needed to start adding some of the other vlans to the 3750 stack. The vlans exist already on both devices. I went into the 5308 and set it to start tagging vlans 3-5 and 75 on the link to the 3750 stack. When I did, I got several errors on the 3750 stack regarding vlans 3 and 4 and they both went into a blocking state on the connection. They have been in that state ever since.



From my syslog server:

1731: Jan 26 05:48:32: %SPANTREE-2-BLOCK_PVID_PEER: Blocking Port-channel1 on VLAN0003. Inconsistent peer vlan.
1731: Jan 26 05:48:32: %SPANTREE-2-BLOCK_PVID_PEER: Blocking Port-channel1 on VLAN0003. Inconsistent peer vlan.
1730: Jan 26 05:48:32: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 3 on Port-channel1 VLAN4.
1730: Jan 26 05:48:32: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 3 on Port-channel1 VLAN4.



Everything I've read so far regarding this type of error point to a difference in the native vlan setup for both sides, but that's not the case here, as both sides are set for native vlan 1 and have been working that way for several months now. After playing with it some more, it appears that the issue is with VLAN 4. If I stop tagging VLAN 4 on the 3508 side, VLAN 3 comes up on the 3750. If I start tagging again, both 3 and 4 go down.


Feb 1 11:41:32: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 3 on Port-channel1 VLAN4.
Feb 1 11:41:32: %SPANTREE-2-BLOCK_PVID_PEER: Blocking Port-channel1 on VLAN0003. Inconsistent peer vlan.
Feb 1 11:41:32: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel1 on VLAN0004. Inconsistent local vlan.
Feb 1 11:41:32: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan3, changed state to down
Feb 1 11:41:32: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan4, changed state to down



Somehow it seems that the 5308 is sending a BDPU with vlan id 3 on VLAN4....

Any ideas would be appreciated.

look at your STP configuration.
Procurve will use MSTP, Cisco PVSTP

vlan 3 and 4 need to be part of the same MST instance.

did you change primary or default vlan on the procurve?

STP is not enabled on the Procurve switch.

Oh, and Primary VLAN is still the DEFAULT_VLAN (1).

>>> STP is not enabled on the Procurve switch. <<<

If STP is not active, the Procurve will not participate in STP calculation, but will still forward BPDU's as if it's a normal data-packet.

apearently the procurve is returning the BPDU's received from the Cisco, back to the Cisco!

please post configs of both switches.
also check no other link connects these switches.

There are two other links between these switches. One for VLAN 6 and one for VLAN 8. I had issues with trying to run either of these VLAN's over the trunk. The Cisco would shut down the trunk ports (not just the vlans, like it is doing for this one) if I tried. I didn't have time to investigate why at the time - I was under a time crunch. Both those links are only running their associated vlans (untagged) and those vlans are not being tagged on this trunk. I'll attach configs shortly. I've attached a network diagram.

Pieter is correct.

Unless you're willing to migrate your Cisco over to MST and allow the ProCurve to participate using MST, your other option would be to simply enable BPDU filtering on the Cisco ports that are peered to the ProCurve. This will prevent BPDUs from being broadcast to the ProCurve.

The root of the issue is that in a Per VLAN STP environment, each VLAN acts as an independent STP domain. When you introduce another device that either doesn't understand PVST or is capable of flooding the BPDUs, the Cisco side will block VLANs to protect itself. From there which VLANs get blocked gets determined by priority and cost...

So since we're only running STP on the Cisco device, there shouldn't be any issues with filtering the BPDUs? I had seen mention of doing this, but I wasn't sure if I should or not.

(Cisco switch config attached)

(Procurve config attached)

My primary consideration would be with layer 2 redundancy. Both ProCurve and Cisco have other methods of loop detection that don't involve spanning tree, but both are proprietary and I don't think they're compatible. So, as long as you know that you will only ever have just a single connection between the two devices, BPDU filtering should work just fine for you. This just means that you wouldn't be able to rely on spanning tree to block a any L2 loops between these two devices or any other possible bridge that might occur further downstream.

Note: A single connection could be a link aggregated port (802.3ad)

So if I really want to get to the root of the problem, I have to figure out how vlan 3 BPDU's are getting onto VLAN 4, correct?

trunk D15-D16 Trk1 LACP
interface D15
no lacp
exit
interface D16
no lacp
exit

you are using both "no lacp" and "lacp"
Are you sure this works as planned?
try a "show trunks" to see if the link is really operating as trunk.

same on the cisco side you are mixing commands on the trunk/etherchannel interface with commands on individual member-ports of the trunk/etherchannel.
>>>
interface Port-channel1
description Redundant Trunk to Core 5308
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-5,7,9-99
switchport mode trunk

interface GigabitEthernet2/0/24
description Uplink - 5308 D15
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-5,7,9-99
switchport mode trunk
channel-group 1 mode active
!
!
interface GigabitEthernet3/0/24
description Uplink - 5308 D16
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-5,7,9-99
switchport mode trunk
channel-group 1 mode active
<<<


=> remove redundant commands from individual ports and only apply them to the trunk/etherchannel.

With STP turned off on the ProCurve, it will simply flood the BPDUs it recieves. I'm not sure how it will treat a BPDU without a VLAN ID in it's header when flooded to a port with both native (untagged) and tagged VLANs, but this may be a contributing factor.
I think all native and untagged VLANs will get BPDUs from all other VLANs including the Dot1Q "tagged" VLANs...

Buckeye-5308xl-Core# sh trunks

Load Balancing

Port | Name Type | Group Type
---- + -------------------------------- --------- + ----- -----
D15 | 100/1000T | Trk1 LACP
D16 | 100/1000T | Trk1 LACP

From everything I've read, that's the way it works. You turn it of for the individual ports involved in the trunk and have it turned on for the trunk itself.

It's working fine, though I can see why the individual cisco ports don't need those commands - I think they get ignored anyway, but yes, I should probably pull them out.