can anyone tell what happens is a native vlan mismatch occures across 802.1q trunk??
1.some docs says loop occurs...(how??)2.some says the trunk partial operates,ie,only vlans that are misconfiured on either end will not forward traffic,but rest vlans works,
3.and some says the trunk itself will not work??
now i have one more doubt here...if case 2 happens,i have learned that dtp messages are sent via native vlan,so if the mismatch itself occurs how will a trunking method be negotiated first for it to partialy operate for rest of vlans...??
arun .. :)
Its the number 2 that I would agree upon. If the native VLAN on one end of the trunk is different from the native VLAN on the other end, the traffic of the native VLANs on both sides can not be transmitted correctly on the trunk. This may imply some connectivity issues in your network.
DTP messages are not send on native vlan they are send via Vlan1. Vlan1 on the trunk ports carries the control traffic like DTP,VTP,STP,PagP and other control traffic.
HTH,Please rate if it does.
Suppose switch 1 have native vlan 2 and switch 2 have native vlan 5 ,if switch 2 receive frame from switch 1 (i am talking about native frame only),since it is untagged switch 2 will think it is for native vlan ,
(which is vlan 5 on switch 2) and it will forward it on all the ports for vlan 5,this is not the ideal scenario and its called as frame leaking,but it will work.that is why you should always make unused vlan as native (for secutity reason)
Now DTP messages are sent using vlan 1 and they will be tagged and it will not make any difference.
if you use PVST+ as spanning tree mode, then it will block the ports with inconsistent VLAN configuration.
next if the ports with inconsistent VLAN configuration will be not block (eg, you use MST), then there is the possibility to get a loop and if you didn't disable the loopback keepalives on uplinks, they will be put in errdisable mode.
how the loop can happaned see the very good explanation from ftallet;
thanks you all,..but all are again pointing to different opinion.... :(
my understanding is when your native vlan is other than vlan 1 dtp messages are still
sent via the configured native vlan configured on 802.1q as untagged,but other protocols
like cdp,PAgP,VTP messages are still sent via vlan 1 as tagged.
so if method 2 is adopted and the misconfigured vlan doesnt forward how will negogiation of
but vishwanth says those misconfigured vlan traffic will also work(ie,will be forwarded).
and how looping occurs as some docs states...???
which is right???.... :(
Your understanding of native vlan and control traffic is a little different.DTP messages are always sent using the Vlan1.They are never sent using the native vlan on the trunk port. Even if you remove vlan1 from the allowed Vlan list on the trunkports still all the control traffic will be sent using the Vlan1 only.
To reduce the risk of spanning-tree loops or storms, you can disable VLAN 1 on any individual VLAN trunk port by removing VLAN 1 from the allowed list. When you remove VLAN 1 from a trunk port, the interface continues to send and receive management traffic, for example, Cisco Discovery Protocol (CDP), Port aggregation Protocol (PAgP), Link Aggregation control Protocol (LACP), Dynamic Trunking protocol (DTP), and VLAN Trunking Protocol (VTP) in VLAN 1.
HTH,Please rate if it does.
here is the good document about VLAN inconsistency:
i think we are diverting from the topic ,but still its interesting to
share new things.... :)
pls go through the below mensioned link....
read the topic "Vlan 1 Consideration"
It clearly states that when your native vlan is not vlan 1,the DTP messages are sent
on native vlans in 802.1q,ie,it sents the DTP messages as untagged on native vlan
and other control messages(like cdp,pgap,vtp etc ) in vlan 1 as tagged.so only i pointed
and put a doubt that how negotiation happens in case of native vlan mismatch???
Although VLAN 1 user traffic can be pruned from a trunk, it is not the case with control plane traffic. In fact, in older Cisco Catalyst Software versions (5.4 or earlier), VLAN 1 could not be removed at all from a trunk. Control plane traffic such as VTP, CDP, and PAgP protocols are tagged with VLAN 1 information and are forwarded on a trunk regardless if the trunk has pruned VLAN 1 and regardless what is the native VLAN.
The point is that i think that even if the Native VLAN is unmatched the trunk will be negotiated as DTP (which uses the Native VLAN not VLAN1) uses untagged frames between the switches regardless what is the Native VLAN on each switch (the DTP frames are exchanged untagged), but this can have severe results on the STP as per the Cisco statement:
"Make sure the native VLAN for an 802.1Q trunk is the same on both ends of the trunk link. If the VLAN on one end of the trunk is different from the VLAN on the other end, spanning tree loops might result."
I got a little confused between the Cisco's DTP implementation on ISL trunk and 802.1q trunk. On ISL trunks DTP packets are always sent on Vlan1 whether Vlan1 is allowed or removed from the trunk port. On a 802.1q trunk port the DTP packets are sent on the native vlan so you were right on that part. I agree with mohammed that even you have a different native vlan on the trunk port the DTP frames will still be able to negotiate the trunk.
thanks to both of u.... :)
so what conclution i can make on what happens when the native vlan mismatch occurs;
1. only vlans that are misconfigured will not forward traffic and rest will work properly....
2.all will forward ,but some looping occurs????