I setup a connection between two Ethernet Subinterfaces, each on a seperate vlan.
At the other end of the trunk (on a switch), the port goes into BKN (broken) mode as bpdu's from VLANa are now appearing on VLANb (because of the connect statement on the router).
Is the correct way to fix this to enable bpdufilter on the switch? This fixes the problem and I'm guessing we shouldn't really be using spanning-tree in this sort of SP environment anyway?
If there are no physical loops and no reasonable possibility of creating them, using the BPDU Filter can be one of the solutions (or rather, workarounds).
But can you be more precise about the type of inconsistency detected on the switchport? Is it PVLAN_Inconsistent or PVST_Inconsistent, or some other type of inconsistency?
The PVLAN_Inconsistent state can be detected only if running PVST+ over these ports, and PVST+ is run only on trunk ports. Considering the fact you were talking only about two specific VLANs, you should probably be using access-mode ports, and on those, PVLAN_Inconsistent state should not occur at all (only PVST+ BPDUs carry the TLV containing their originating VLAN which forms the basis of this inconsistency detection).
Here's the message we get...
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 81 on GigabitEthernet0/32 VLAN80
We're running PVST and this is a trunk port (gi0/32) up to a router, where we split the vlans into subinterfaces (see below)
encapsulation dotq1 80
encapsulation dotq1 81
connect CONN gi0/3.80 gi0/3.81
I'm fairly sure that bpdufilter is the correct workaround, but thought I'd get another opinion.
Using the BPDU Filter is the easiest way to make this work. In fact, I am not sure if there is any other reasonable solution here. You are indeed taking PVST+ BPDUs from one VLAN and putting it into another VLAN so basically, what you are doing is illegal from the viewpoint of the PVST+. But assuming your are doing L2 Local Switching, it cannot work differently.
Use the BPDUFilter but be very cautious about possible physical or bridging loops.
indeed BPDU filtering is an option or simply disable spanning tree on vlans 80 and 81 since those 2 vlans have local significance on this router only and don't show up anywhere else in your L2 domain I suppose:
no spanning-tree vlan 80,81
Deactivating the STP for the entire VLAN would help as well but I would personally consider that to be a huge calling for trouble. Deactivating the STP using the BPDU Filter on a single link is fine if this is the only link that interconnects two components of a network, however, deactivating the STP for the entire VLAN is in my opinion an overkill.
So in my view, would it help? Yes, it would. Would that be considered a best practice? Hardly. (Well, then again, neither the BPDU Filter can be considered a best practice... )
Please do feel free to disagree with me and share your thoughts!
in general I would agree with you that disabling STP is a call for troubles.
But in this very specific case we are dealing with Layer 2 local switching feature which requires the use of locally significant dot1q tags on the subinterfaces that you want to inter-connect.
So the assumption is (as I wrote in my post) that the vlans 80 and 81 have locally significance only and that even if they are carried in the trunk up to the switch (where interface gi0/32 resides) they don't exist anywhere else.
The assumptiom comes from the other thread opened by RC on the topic (where I suggested to use L2 local switching) > https://supportforums.cisco.com/message/3450564
From my understanding after the switch we have the 2 carrier circuits with different tags and beyond that point there is no more tag significance.
If this is true the use of BPDU filter is equivalent to disabling STP for those 2 vlans.
Of course if the 2 vlans also belong to a switched network it is not safe to disable STP on the switch as the presence of actual redundant links can create lots of troubles.
In conclusion I don't think I disagree with you as I was just giving my opinion on a very specific scenario
by the way I saw a similar setup already on a Cisco TAC case where on a switch were terminated two DSLAM links with different .1q tags and a customer wanted to interconnect them using l2 local switching on a router. Connectivity was broken as the uplink switch was blocking the trunk due to inconsistent peer vlan, which is exactly what RC got.