[c-nsp] STP, native VLAN and trunks

[McLean Pickett]

You need to layer 2 port in the VLAN before a STP instance is created. I
don't believe the presence of a VLAN on a trunk alone with create a STP
instance.

The native vlan on a trunk port should be allowed on trunk for CDP and
other protocols to function. Typically native vlan's are left as vlan 1
which is not used anywhere else. In recent versions of code Cisco has
introduced features that mitigate the risk of having vlan 1 trunked all
over your layer 2 network.

Native VLAN's need to be the same on both ends and they need to be
allowed over the trunk. Production VLAN's should not be used as the
native vlan on a trunk.

STP re-calcs on the native VLAN should not interrupt traffic on the
production VLAN's. However, if you are not allowing the native VLAN on a
802.1q trunk your results may vary since the BDPU's for the native VLAN
are not being passed.

Also, you may want to take a second look at your layer 2 design. If you
can stack A and B and use redundant trunks from C to (A and B) and D to
(A and B). The CB and DB links should be blocking on the C and D ends
with the stack configured as the root bridge.

McLean

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Zeng
Sent: Tuesday, December 13, 2005 1:12 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] STP, native VLAN and trunks

Hi,

today a quite interesting discussion developed here at work regarding
per-VLAN STP, native VLANs and trunking.

Given the following switch topology:

A------------B
|            |
|            |
|            |
D------------C

each switch has .1q trunks to its neighbours configured. The native VLAN
used on all trunks is the same as well as some VLANs used for
production traffic.

The discussion was about using a different native VLAN ID at least at
one trunk because otherwise a STP topology change could harm trunk
operation and affecting the production VLANs, too, even if PVSTP runs
(blocked native VLAN = trunk failure?).

At the first look, I agreed to this. Digging deeper, more questions
arised and I'm not sure if the different native VLAN will make much
sense.

Why should the recalculation of STP for the native VLAN have any effect
on forwarding frames for any other VLAN over the trunks?

Another question is: When there is a VLAN defined as "native" for a
trunk, this VLAN is excluded from the list of allowed VLANs on that
trunk and it is not used at any other place in the switch, why is there
no STP instance created?

spanning-tree vlan 800,840 priority 8192
!
interface GigabitEthernet2/5
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 840
 switchport trunk allowed vlan 800
 switchport mode trunk
     
#sh span vlan 840

Spanning tree instance(s) for vlan 840 does not exist.

Why should I include the native VLAN on the list of allowed VLANs? 

Thanks,


Christian
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/