Procurve and Cisco 3750 interoperability - inconsistent peer vlan

[Grodech]

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?

[Pieter 't Hart]

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.

[DaGuru]

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...

[Grodech]

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.