[c-nsp] unblocking port on 3750

Blake Pfankuch blake at pfankuch.me
Thu Aug 2 09:35:00 EDT 2012

Peter/Bouazza, I haven't worked a huge amount with HP switches in the past 4 years but I would agree.  There is some configuration which can be done with their link ag stuff to force it to load the config in less than 15 seconds, but its not always best practice.

Traditionally it is best practice has been to load the ag port config to the physical interfaces as well so you don't have this same issue, even though its not technically a requirement.  Also means that the ports work correctly in an instance where there are not enough active ports to bring up the ag group.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: Thursday, August 02, 2012 4:41 AM
To: Bouazza Djamel
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] unblocking port on 3750

On Thu, 2012-08-02 at 10:09 +0000, Bouazza Djamel wrote:
> Thank you for your swift reply. Hereunder the errors messages on switch 3750.
> Aug  2 06:06:07 CET: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 2062 on Port-channel4 VLAN1.
> Aug  2 06:06:07 CET: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel4 on VLAN0001. Inconsistent local vlan.
> Aug  2 06:06:22 CET: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel4 on VLAN0001. Port consistency restored.

This means that the Cisco switch, which by default assumes untagged frames belong to VLAN 1 ("native vlan"), received a PVST BPDU belonging to VLAN 2062 untagged. That's an inconsistency.

If this were between two Ciscos switches it could be caused by having different native VLANs on each side. That shouldn't correct itself automatically though.

Since the problem corrected itself I must assume that the neighboring HP switch starts out with VLAN 2062 as untagged but switches to VLAN 1 after 15 seconds, thus restoring consistency.

> On switch 3750 :
> nterface Port-channel4
>  description *** to  CORE SWITCH  HP ***  switchport trunk 
> encapsulation dot1q  switchport trunk allowed vlan 
> 1-999,2010,2014,2026-2055,2060-2067,2069
>  switchport mode trunk
> On Core switch HP 12508
> interface Bridge-Aggregation2
>  description *** to 3750 DATACENTER ***  port link-type trunk  port 
> trunk permit vlan 1 to 255 257 to 999 2010 2014 2027 to 2055 2060 to 
> 2067 2069  link-aggregation mode dynamic

What does the physical member links look like? I'm unfamiliar with HP swithes, but maybe the physical links have VLAN 2062 as untagged. When they become regular members of the port-channel (LACP? Unconditional?) they inherit the configuration from the "Bridge-Aggregation2" interface.

Maybe the configuration from the physical interfaces can shed some light on it.

All in all I'd say that this isn't a problem as such. I just seems to mean that the links takes 15 seconds to actually start working, but from then it is consistent.


cisco-nsp mailing list  cisco-nsp at puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list