cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13499
Views
0
Helpful
7
Replies

Native VLAN not allowed on trunk port

johnnylingo
Level 5
Level 5

Let's say I have this configuration on an interface:

spanning-tree mode rapid-pvst

!

interface GigabitEthernet0/1
switchport trunk native vlan 100
switchport trunk allowed vlan 20,30,40
switchport mode trunk
speed nonegotiate
spanning-tree portfast trunk
spanning-tree bpdufilter enable
!

#show int trunk                

Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      100


Port      Vlans allowed on trunk
Gi0/1       20,30,40

Two Questions:

1) What will happen if the port receives an untagged frame?   Will it stick it in VLAN 100, or just discard it?

2) BPDUFilter operatate on a per-VLAN basis.  Will it look for BPDUs on VLAN 100 and take the port out of portfast mode accordingly?

1 Accepted Solution

Accepted Solutions

Hi John,

The difference between global vs port level is documented on configuration guide. Just use 3750's as an example

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_44_se/configuration/guide/swstpopt.html#wp1095752

Actually there is little difference applying bpduguard global vs port level as well, see the documentation for detail.

HTH,

Lei Tian

View solution in original post

7 Replies 7

lamav
Level 8
Level 8

John:

Traffic on the native vlan does not get tagged as it crosses a trunk, so you dont need to allow the native vlan. There is no dot1q tag in the first place to be filtered. If the trunk port stops trunking and turns into an access port, the port will be placed in vlan 100, as opposed to the default vlan 1.

Lei Tian
Cisco Employee
Cisco Employee

Hi John,

1) What will happen if the port receives an untagged frame?   Will it stick it in VLAN 100, or just discard it?

2) BPDUFilter operatate on a per-VLAN basis.  Will it look for BPDUs on VLAN 100 and take the port out of portfast mode accordingly?

1, It will discard it.

2, You are enabling bpdufilter on the interface, which will disable spanning tree. Depends on your physical topology, you might create a loop. The feature you were looking for is enable bpdufilter on global, and also put trunk in portfast is not recommended unless you have a loop free topology.

HTH,

Lei Tian

Hi Lei,

Yes, that was my guess on #1.  Just confused because the switch still said 100 was the Native VLAN

You are correct on #2.  I just confirmed this in my lab and was able to create a loop.  Do you know why bpdufilter works as expected in global mode, but not in per-interface mode?   bpduguard works the same global vs. per-interface, so I was surprised to find bpdufilter does not.

Hi John,

The difference between global vs port level is documented on configuration guide. Just use 3750's as an example

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_44_se/configuration/guide/swstpopt.html#wp1095752

Actually there is little difference applying bpduguard global vs port level as well, see the documentation for detail.

HTH,

Lei Tian

That link explains things a little better, thanks.  I tested them in lab and agree that is the behavior.

So basically the command break down is like this:

spanning-tree portfast bpduguard default (global) - If a portfast interface receives a BPDU, the port is put in to err-disable

spanning-tree bpduguard enable (interface) - If the interface receives a BPDU, the port is put in to err-disable, regardless of portfast config

spanning-tree portfast bpdufilter default (global) - If a portfast interface receives a BPDU, it is brought out of portfast mode

spanning-tree bpdufilter enable (interface) - Prevents the interface from sending/receiving BPDUs entirely, effectly causing that port to not partipate in STP

I guess I'm just having trouble understanding the logic on Cisco's part.  BPDU guard and BPDU filter are designed to prevent loops.   Why would have bpdufilter at the interface level behave this way?   Seems a recipe for disaster.

I guess initially the BU or developer thought that might be a useful feature, but it turns out causing lot misconfigurations. If it is not useful at all, maybe in the future it will be removed. Just like the "no auto-summary" becomes default for EIGRP in 15.0 code.

I stand corrected. I should have tested in my lab first, but it seemed pretty straightforward.

Anyway, sorry I gave you incorrect information.

Victor

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: