在vlab看到有人在問這問題
想起三年前回答過一樣的東西
當時還勞煩到在Cisco工作的MM兄補充了一些東西
今日回頭來看仍深具意義
故收錄如下
allen:
native vlan的用途在於當trunk link起不來時，會以哪個vlan去跑....
我們知道在interface下設定switch port trunk這個指令
如無其它command，會carry所有的vlan traffic.
也就是說這個port不屬於特定任何一個VLAN
但萬一trunk起不來(有可能一邊的vlan trunk有問題，或是中間串一個hub)
則會造成兩邊所有的VLAN無法互通，為了避免這個情形
我們可以下switchport trunk native vlan xx 這個指令告訴switch
萬一trunk link fail的時候，這個port是屬於哪一個vlan
通常我們會設for 管理用的vlan 1
以便即使trunk link failed，我們仍然可以透過vlan 1的management ip
到達另一台switch來做調整設定之類的動作
MM:
For Cisco devices, all proprietary control protocols are always carried over VLAN 1 instead of Native VLAN. Therefore, even when you changed Native VLAN to some non-default one, or purged VLAN 1 from a trunk, they will still run over VLAN 1.
As to Native VLAN, it was originally used for backward compatibility like Allen mentioned. This has always been how IEEE design a new protocol. This way we can assure devices that are not 802.1q aware can still communicate to newer device over a hub, which was the most dominant network device back when 802.1q was designed.
For inter-operability across vendor, it is actually more than just Native VLAN. As the original IEEE 802.1q spec did specify that Native VLAN must be untagged, there were lots of issue when dealing w/ devices among vendors as everyone interpret the standard differently, thus choose different default behavior. Some choose to tag the frame (e.g. Cisco), while others choose not to (e.g. Foundry). Fortunately, due to the reason mention by Chun (VLAN hopping), most vendors notadays give users options to turn Native taggeing on/off. However, due to terminology difference, it is still confusing when referring to configuration guide from different vendors.
想起三年前回答過一樣的東西
當時還勞煩到在Cisco工作的MM兄補充了一些東西
今日回頭來看仍深具意義
故收錄如下
allen:
native vlan的用途在於當trunk link起不來時，會以哪個vlan去跑....
我們知道在interface下設定switch port trunk這個指令
如無其它command，會carry所有的vlan traffic.
也就是說這個port不屬於特定任何一個VLAN
但萬一trunk起不來(有可能一邊的vlan trunk有問題，或是中間串一個hub)
則會造成兩邊所有的VLAN無法互通，為了避免這個情形
我們可以下switchport trunk native vlan xx 這個指令告訴switch
萬一trunk link fail的時候，這個port是屬於哪一個vlan
通常我們會設for 管理用的vlan 1
以便即使trunk link failed，我們仍然可以透過vlan 1的management ip
到達另一台switch來做調整設定之類的動作
MM:
For Cisco devices, all proprietary control protocols are always carried over VLAN 1 instead of Native VLAN. Therefore, even when you changed Native VLAN to some non-default one, or purged VLAN 1 from a trunk, they will still run over VLAN 1.
As to Native VLAN, it was originally used for backward compatibility like Allen mentioned. This has always been how IEEE design a new protocol. This way we can assure devices that are not 802.1q aware can still communicate to newer device over a hub, which was the most dominant network device back when 802.1q was designed.
For inter-operability across vendor, it is actually more than just Native VLAN. As the original IEEE 802.1q spec did specify that Native VLAN must be untagged, there were lots of issue when dealing w/ devices among vendors as everyone interpret the standard differently, thus choose different default behavior. Some choose to tag the frame (e.g. Cisco), while others choose not to (e.g. Foundry). Fortunately, due to the reason mention by Chun (VLAN hopping), most vendors notadays give users options to turn Native taggeing on/off. However, due to terminology difference, it is still confusing when referring to configuration guide from different vendors.
文章標籤
全站熱搜
網路技術 (3)