Can someone explain what a native VLAN is and how exactly does it work? Thanks HD
Harley, In a trunk, which is either ISL or Dot1q, traffic belonging to the native vlan does not get a trunk encapsulation. Its frames travel as they would on a native ethernet - hence native vlan. Traffic in the non-native vlans have the additional trunk encapsulations on them which identify which vlan the traffic belongs to. Jerry
In effect, it sounds like assigning a native vlan allows the switchport can operate both in trunk mode and access mode concurrently. Does anyone have an application that takes advantage of this? I think one application is with Cisco IP phones which themselves contain a 3-port mini switch which allows a PC to be plugged into them. When setting up the 3550 switchport for the IP phone, the voice and data traffic can be kept segregated for separate QoS treatment by configuring a voice vlan that is part of an 802.1q trunk (to handle the 802.1q encapsulated voice traffic from the phone) and leaving a native vlan for data from the PC. My understanding may be a little weak on this, but this is the impression I got from reading the 3550 User Reference. Robert
I wouldn't explain it this way. You also have to consider that "trunk port" and "access port" are strictly Cisco nomenclature, they don't exist in 802.1pQ and may even have another meaning in the outside world (like "trunk" is used by other vendors to name the construct that Cisco names a Portchannel/Etherchannel). The question is simply: If I have a tagged link, what do I do with frames that I receive on that link, but untagged? The (always existing) native VLAN names the VID to which these frames are mapped. And if it is this way, why should I transmit frames of this VLAN with a tag? So, the native VLAN names the VID that, when leaving a port, is sent untagged. There is some potential for interoperability problems here (some vendors allow *only* tagged frames on trunks, others [like Cisco with the XLs] always wanted to transmit some VID untagged), but besides that, it is actually a nice idea, because it allows for limited VID translation. The original intention is likely that a factory reset switch behaves as expected, what you can achieve by defining that initially, Default VLAN == Native VLAN == Untagged. In this setup, having all ports access ports in the default VLAN is actually the same as having them all be trunk ports with just the default VLAN on the trunks. Allows for easier deployment of additional VLANs, automated trunk/access negotiations and so forth. The basic application of that is simply the collection of protocols that run on a trunk untagged: VTP, CDP... I haven't groked voice VLANs completely yet, but they appear to be some- thing special, as they have to be explicitely configured. But maybe this is just so that the phone has a way to learn the actual VID to use from the switch. In general, the vast majority (at least that I've seen yet) of imple- mentations of tagged links between switches in inter vendor land uses the scheme of "default VLAN untagged, all other VLANs tagged". So does Cisco (by default), and that's what the "native VLAN" setting of a switchport is all about: It sets the "port VLAN ID" as well as the "untagged egress VID" as known from other 802.1Q implementations. Indeed this is a mixture of "access port" and "trunk port" behavior, but that's just because these two are just names, while 802.1Q in practice is a little bit more flexible.
[Andre Beck] | In general, the vast majority (at least that I've seen yet) of imple- | mentations of tagged links between switches in inter vendor land uses | the scheme of "default VLAN untagged, all other VLANs tagged". So does | Cisco (by default), and that's what the "native VLAN" setting of a | switchport is all about: It sets the "port VLAN ID" as well as the | "untagged egress VID" as known from other 802.1Q implementations. Fortunately, Cisco lets you do away with the untagged VLAN completely with the "vlan dot1q tag native" - not available on the 3500XL series, but works nicely on newer switches. With "vlan dot1q tag native" all outgoing frames are tagged, and any incoming frames without a tag are discarded. Steinar Haug, Nethelp consulting,
We setup our switches with all ports in the Default VLAN and the uplink fiber port in 802.1q trunk mode. The trunk carries untagged default VLAN traffic and also tagged traffic for our management VLAN (tag 100). Is this the best way to set things up? I often hear people saying that you should move all the ports off the default VLAN but I don't understand why? Cheers, Dan
You'll know why, when you connect a network of switches administered by someone else to one of the ports on your switch. Suddenly, all your VLANs will disappear and VLANs from the other switches will appear instead. Of course only if you have VTP active and set to "slave" mode. It happened to us and believe me, it was painful. VTP runs over VLAN 1. Since then, I turn off VTP on any switch I come across. The person at Cisco making this the default should be shot :-(
Ouch. But that shouldn't happen with a decent VTP domain and password unless you almost intend to break it, should it? It is actually irrelevant whether your boxes are VTP Client or VTP Server. Both will happily overwrite their vlan.dat when someone announces a higher revision. There is no way to freeze your VTP domain (except from setting all switches to VTP tranmsparent, but that breaks convenience). Instead of shooting him, he should be locked into a room until he comes out with an implementation in the tradition of "no cdp enable" that allows you to do int GiX/Y switchport mode trunk switchport nonegotiate switchport trunk allowed-vlan [...] no cdp enable no vtp enable so you can define a decent administrative border of VTP domains. And if he is locked there, I'd also like a VID map that allows you to map the VID tags of the other domain to your own tags. If it's possible in hardware to map DSCPs to 802.1p precedences, it shouldn't be any harder to do a table based VID tag rewriting. TCAM is plenty...
