so with the new native vlan 50, stp and vtp will be tagged using vlan 50 vlan id instead of untagged on vlan 1?

is DTP carried in vlan 1? Vlan 1 is part of DTP /CDP right?

Only traffic belonging to vlan 50 will be untagged, while traffic of all other vlans will be tagged wih their respective vlan No.

so all control messages will be tagged with vlan 1. Yes DTP is also a part of vlan 1 traffic.

Cisco specific control protocol will be tagged with vlan 1, as they operate on vlan 1 only (VTP, DTP etc...).

IEEE protocols send their frames untagged. MSTP BPDUs will thus be sent untagged (as if they were sent on the native vlan if you want). Same for LACP, LLPD etc...

In PVST mode, vlan 1 is supposed to interact with IEEE bridges, so vlan 1's BPDUs are also always sent untagged. However, if vlan 1 is removed from the trunk, no BPDU are sent because the port will not be added to vlan 1's spanning tree instances.

Regards,

Francois

Francois,

I still dont get it:). I read recently about control protcols like DTP, STP VTP are untagged with vlan 1 as the native vlan. and even if vlan 1 is not allowed on the trunk, the control traffic can still get through!.

please correct my understanding.

Vlan 1 as the native vlan or any other vlan used as native carries cisco proprietary protocols as tagged since cisco protcols are tagged tarffic. right?

Any IEEE protcols since they are untagged are carry over the native vlan as untagged and they dont care about what native vlan is used. right?

Whatever native vlan is used, that vlan will always carry IEEE untagged traffic or will vlan 1 always be the default even when not allowed on the trunk?

Thanks.

No problem, I hope I get it;-) not sure considering the following question from Kevin.

When Cisco started vlan, there was only ISL. Vlan 1 was mandatory and could not be disabled. As a result, each time we needed a protocol between two switches, we could count on vlan 1 (and only on this one). That's why as a rule of thumb, Cisco protocols are vlan 1 protocols.

When moving to 802.1Q, those protocols have no reason to be affected and kept running on vlan 1. So if vlan 1 is the native vlan, the frames are untagged, else they are tagged.

Then we allowed vlan 1 to be disabled from trunk. Practically, vlan 1 is not really disabled. It is moved in an STP blocking so that no user traffic can go through, while control protocl are unaffected. This is not really the case for PVST of course: if you prune vlan 1, you can't run an STP instance for vlan 1 on this trunk (that could introduce black holing).

IEEE protocols have not been affected by the introduction of vlans by 802.1Q. The bridge exchange information at a layer below the definitions of the vlans if you want. BPDUs are received by a bridge before the shim that introduces the concept of vlan. And BPDUs are transmitted by the bridge directly into the link, bypassing again the laying implementing the vlan in the bridge relay. That's why there is not even the concept of vlan in the IEEE protocol exchange. Frames are sent untagged, period. Cisco call this the native vlan, but in fact, it is just no vlan at all.

HTH,

Francois

Francois,

I appreciated your explanation.

Could you answer a couple of follow up questions about this?

For example

"When moving to 802.1Q, those protocols have no reason to be affected and kept running on vlan 1. So if vlan 1 is the native vlan, the frames are untagged, else they are tagged."

Are you saying that once you make a VLAN other than 1 the native VLAN, that this VLAN becomes untagged and VLAN 1 then is tagged?

And here:

"Practically, vlan 1 is not really disabled. It is moved in an STP blocking so that no user traffic can go through, while control protocl are unaffected."

That if I create a trunk and make 999 the native VLAN, and only allow VLAN 10 and VLAN 20 on the trunk, that VLAN 1 is actually being trunked for management traffic, but not seen on the trunk?

Also:

"if you prune vlan 1, you can't run an STP instance for vlan 1 on this trunk (that could introduce black holing)."

By doing this, you create a black hole in terms of the switch not being a participant in the switch management domain?

1- Yes, in Cisco implementation only one vlan is untagged, the one configured as "native" vlan.

2- Yes, VTP for instance will still be sent on vlan 1. The port is not forwarding data traffic anyway, that's what is important. The only traffic that can go through a blocked port is going to the CPU of the next switch.

3- I don't really understand your question. What I meant is that if we were to forward BPDUs on vlan 1 but no data traffic, that would probably lead to black holing as STP would believe that the link is active, while in fact no communication is going through.

Regards,

Francois

Francois,

If I am running pvst,

the example I used before, should never be done, is this correct?:

"create a trunk and make 999 the native VLAN, and only allow VLAN 10 and VLAN 20 on the trunk"

I should allow VLANs 1 , 10 and 20?

I would recommend you enable vlan 1 if you are running MST. In particular, the interaction PVST-MST might be delicate without vlan 1.

If you are in a PVST environment only, vlan 1 is almost a vlan like all the others (excepts that it always sends its BPDUs untagged to the IEEE destination mac address). So your configuration with no vlan 1 is ok.

Regards,

Francois

François,

Won't the DTP initially be untagged, whatever the native VLAN? After all, until the DTP has done its job, you don't know yet whether you are a trunk, so you don't know whether to tag.

Kevin Dorrell

Luxembourg

Hi Kevin,

Actually, it's been some 10 years I've not thought of that, and at that time this protocol was DISL, only working on ISL trunks. And even there, I guess that there was indeed a negotiation part that must have been sending both ISL and non ISL frames. For sure, once in trunking mode, DISL was sent on vlan 1 (because the hardware was tagging *all* the frames, so you had to choose a vlan and it could only be 1). Now, this protocol has been revised for 802.1Q (unlike VTP for instance) and it became DTP. At that time, vlan 1 was mandatory even for 802.1Q trunks. However, I'm not sure if the protocol designers went for an IEEE like approach (which would be perfectly logical), using untagged frames, or whether they stick to the Cisco tradition of using vlan 1. Because the tagging of the frames in internal in 802.1Q, there would not be the same hardware problem as with ISL. Again, the tag is a layer above and the trunk port (and non trunking port) can intercept the control frame by its mac address before processing the vlan tag (that was not the case with ISL). So both approaches would be possible and I don't know which one was taken. I can investigate that if this issue has an impact on your sleep;-)

Regards,

Francois