native vlan question

Here are some good posts on this topic. Probably better than one of us typing up several paragraphs. The second article explains native vlan / vlan 1, and management interface concerns.

Still confuse something.

cisco didnt invent this - it is part of 802.1Q.

i suggest you try to find the standard and read around that, maybe start at

AFAIR some of the standards docs are without charge for Ethernet.

there are 2 Qs to think about.

1. set a port to be tagged - what do you do with a packet that arrives with no tag?

the 2 common answers are to throw it away, or to put it into some sort of "default VLAN" - that is what untagged means for incoming packets.

not putting a tag on outbound packets form that VLAN on that port allows 2 way comms.

this sounds silly - but it is what often needs to happen when you hook up an unconfigured device to set it up.

1. what happens when you want to split up 2 streams of packets on a port?

sometimes you have a device that will add its own stream of packets to a set it gets from elsewhere

- the classic case is an IP phone where there is a plug on the phone to connect a PC.

- Pcs dont normally send tagged frames, and the 3 port bridge in the phone doesnt have the horsepower to wrap a tag around every packet. - but you want the phone traffic kept separate from PC (security, QoS and so on).

So - pass the PC packet thru untagged, and tag the phone traffic. At the switch the PC "stuff" is untagged and goes into the native VLAN, phone traffic is tagged and goes into a different VLAN.

Thanks, For "Some article say because of backward compatible with 802.3" they may think far end is Hub or switch/bridge which does not support

802.3, right? One more question, when a access port receive a untag frame, does it add a 802.1q tag or some other tag to make sure it can go same vlan inside of this switch?

I have read something somewhere that stated that the Tags are stripped off when frames enter the switch however clearly equivalent information is carried 'with' the frame 'through' the switch.

So as far as we the Users are concerned I think that you would have a good way of thinking about it if you assumed that such a tag was used.

When you configure a port-based VLAN on a switch, you are telling the switch which ports are to be grouped into a common broadcast domain (VLAN). Therefore when a switch receives a tagged frame on a trunk port, it knows which ports it is permitted to forward too based on the separation of broadcast domains (VLANs). Of course, if the switch has learned the port that the destination host resides on, it will only forward it out that port within the appropriate VLAN (assuming a unicast packet). Broadcast packets may be flooded to all ports within a VLAN.

Best Regards, News Reader

..

let me clear the second question up: when a access port receive a untag frame from a host, does it add a 802.1q tag or some other tag to make sure it can go same vlan inside of switch?

I would "assume" that an untagged frame (the norm) sent by a host, and received on a switch port that is assigned a non-native VLAN ID, would get tagged at the ingress port; would remain so on its journey through the switch, and get stripped on the egress port if the port was configured for "access mode".

However, I would think that a programmer could (if desired) use some other construct for segregating frames within the switch, and tag frames as necessary as they egress onto a trunk port.

I think your answer is likely implementation dependent, and up to the whims of the programmer.

Why get hung up on such an esoteric matter, when there are so many practical issues to deal with?

Best Regards, News Reader

Thanks, To raise this question is that I try to have a good understand mechanism of switch. Still have some questions here:

1. Based on what you explain it. For "a non-native VLAN ID" which you mentioned, this ID may be or may be not 802.1q tag, it depends on vender how to implement it. I think it is 802.1q tag,since port can also add 802.1p if it need it (3 bit for CoS). make sense? (maybe venders have diff. way to do it.)
2. Let's go back practical issues, from a switch config point of view, the native vlan we have is because of trunk port. only trunk port can assign native Vlan. true? if other port is assign to as same as native Vlan ID, then we say it is native vlan port. right? (assume all we talked here is access port)
3. We know for a trunk (assume two switch connected)should assgin same native vlan ID on both side. otherwise some vlan can not talk for some case or may have loop. The most of switch default native vlan is vlan 1. What is purpose to assgin it to other than vlan 1 when config trunk port?
4. Some article also say one benifit of native vlan is if this trunk failed, the native vlan (untagged message) can still work. What is trunk failed definition over here? What falure cause tagged frame cannot go through only untagged frame can.
5. Is it valid that a switch trunk port to connect to a host NIC? (assume NIC is not 802.1q aware) if it is ok, it means that that server can only send/receive native vlan frame (untagged). right? what is purpose? it is just because of backward compatible?
6. I remember (intel and broadcom) support 802.1q aware sever NIC. For somecase, say a small company that no need hosts talk bewteen vlans, only allow all vlans hosts talk to a server. then we can config a trunk port on switch and connect to that server. We dont need any routing protocol. Is that right? anyone use this way? (i know it has diff solution such as Pvlan)

TIA, st

Although I offered an opinion, I don't really care what mechanism the programmer uses to segregate VLAN traffic as it passes through the switch, as long as separate broadcast domains are honored. I care about implementing functionality.

The "switchport access" command on our switches permit us to assign a VLAN only, no reference to "native". The "switchport trunk" command permits defining a VLAN as 802.1Q native.

The two switches should agree to tag or not to tag a given VLAN. There is no requirement to use a native VLAN though. More on this below.

Personal preferences most likely.

Perhaps, if you used a native VLAN as an administrative VLAN (device administration), it might give you some immunity from some configuration errors, but I'm not aware of any such failure mode.

If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a trunk port on the switch, you'd connect it to an access port.

If a server NIC was 802.1Q aware, you could connect it to a trunk port on the switch, enabling hosts from different VLANs to access the server. Without a routing function, hosts in different VLANs would be isolated from each other.

There is generally no need to use a native VLAN on a trunk. In fact it is preferable from a security standpoint that you not use native VLANs due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1) as the native, and then refrain from assigning any ports to the VLAN. The trunk is then configured to permit specific VLANs only (excluding the native, and excluding VLAN1). All traffic on our trunks are non-native.

We assign all unused (shutdown) ports to a specific VLAN (again, not VLAN1). The default VLAN1 is not used at all.

Best Regards, News Reader

Thanks, For "Some article say because of backward compatible with 802.3" they may think far end is Hub or switch/bridge which does not support

802.3, right?

SPH - possibly, depends on where you found this.

One more question, when a access port receive a untag frame, does it add a 802.1q tag or some other tag to make sure it can go same vlan inside of this switch?

SH - the standard doesnt care.

802.x is all about what happens on network links between devices - what a manufacturer chooses to do inside the box is private / implementation dependent.

Now - on a cisco switch it any untagged frame is either thrown away or associated with a VLAN (the VLAN is configured against the port, or you inherit the default VLAN 1). Once "in" a VLAN it stays there through the box, and may actually get wrapped in a tag once it goes onto a link to the outside world.

Very good feedback! How about management vlan? So you use Vlan1 for managment only or use others?

The last sentence of my post - "The default VLAN1 is not used at all." ;>)

We use a specific VLAN for management purposes. No user traffic is permitted into the administrative VLAN.

One issue with VLAN1 is inheritance (for lack of a better word). If you were to delete a VLAN (intentionally, or otherwise) that had ports assigned to it, where would they go? They would end up in the default VLAN; VLAN1. If you were using VLANs to enforce security policy, would you want ports that were supposed to be isolated, to be grouped into a common VLAN, even for a short period of time, until you remedied the situation? No.

Best Regards, News Reader

Still have a couple of things not sure,

1. if no vlan1 go through trunk port, how about some L2 protocol such as VTP,CDP,PAgP etc. cisco say those protocols must be run vlan1 only.
2. Also no vlan1 go to trunk, does it impect spanning tree protocol. or you don't care them. (maybe stp is okay, use rstp or mstp I am not sure about it)
3. Any special config to enable a management vlan which can do snmp and telnet to switch to do configuration on cisco switch?. What i know some vender assign one or two dedicate port for this purpose.

TIA, st

On 4=D4=C216=C8=D5, =CF=C2=CE=E74=CA=B103=B7=D6, snipped-for-privacy@hotmail.com wrote:=

you hook up an

ckets to a set

Still have a couple of questions to discuss with you.

1.Does it need any special config to make a management vlan on cisco switch? or any vlan can do? I know some vender assign one or two dedicate physical port to do it.

1. If no vlan1 go through trunk prot, how about some L2 protocol such as VTP,CDP and PAgP etc., how do they work between switches if they need it?
2. If no vlan1 go through trunk port, how spanning tree protocl? any impact? all above assume switch to switch trunk connection (use 802.1q.)

TIA, st

When answering or replying to a post WHY don't up cut down the size (number of lines) in the message. It makes reading and replying a lot easer...

The VLAN interface is a logical interface used for administration. If we wanted to use VLAN20 for administrative purposes we'd create a VLAN interface with the result being:

interface Vlan1 description Not to be used, for security reasons. no ip address shutdown ! interface Vlan20 description Management VLAN ip address 192.168.20.6 255.255.255.0

Thank you for asking that question. It reminds me that I need to think beyond the environment (bubble) in which I work. The environment in which I work is not large enough to force us to use VTP, DTP, CDP etc. Each has it's own security implications, and we choose not to use these protocols.

I did do some investigation though, so I can offer the following:

I temporarily enable switchport negotiation on a trunk and observed that three DTP packets were immediately placed on the trunk with VLAN ID = 1. Thereafter, all DTP packets were sent with the native VLAN ID (not 1 in our case). This is despite the fact that neither of these VLANs are defined as permissible by the "switchport trunk allowed vlan x-y" command configured on the trunk.

When I enabled CDP on the trunk interface the resulting packets used VLAN ID = 1.

I don't have a network tap on the trunk port and am forced to use a SPAN port on the switch. If I set the encapsulation mode of the SPAN destination port to 802.1q, all packets are seen with 802.1q headers, even those that would not have a header (native) when placed on the wire. Therefore, I can not say conclusively whether the VLAN1 packets were sent with or without a header (I suspect they would be).

There are different spanning tree modes. We're using PVST (per VLAN Spanning Tree).

spanning-tree mode pvst

STP packets are sent in each of the VLANs on the trunk.

Best Regards, News Reader

ote:

port allows 2

you hook up an

ackets to a set

in the phone

rity, QoS and

"interface Vlan20 description Management VLAN ip address 192.168.20.6 255.255.255.0"

Looks your management vlan has not special config. Does any Vlan assign ip addr. to be a management vlan? I think every vlan wants to routing must be assign a ip addr.

The switch I was referencing is a Layer 2 switch. I believe it permits assignment of a single IP address only (on a single logical VLAN interface). We didn't want to use the default VLAN interface (VLAN1), so we created another with a name that matched the VLAN ID of the VLAN that we wanted to use for that purpose.

It is the administrative VLAN by virtue of it having a Layer 3 address that we can access (SSH, SNMP, etc.); ensuring no user devices are connected to ports assigned to this VLAN, and ensuring that interVLAN routing prohibits user traffic from accessing the administrative VLAN.

With a Layer 2 switch, a trunk port is connected to a router to facilitate interVLAN routing. The router is configured with sub-interfaces; each configured in unique address space (e.g.:

192.168.16.0 /24, 192.168.17.0 /24, etc) matching the VLAN that it serves (as the VLAN's default gateway).

E.g.:

Hosts in VLAN 16 configured with addresses 192.168.16.0 /24, and a default gateway of 192.168.16.1 (perhaps sub-interface 16 (f0.16) on the interVLAN router). When a host on VLAN 16 sends a ping to a host on VLAN

17, it sends it to its default gateway (f0.16). The router (if permitted by security policy) would send it out the sub-interface that serves as the default gateway for VLAN 17 (f0.17 perhaps). The host on VLAN 17 would use its default gateway (f0.17) to return a response.

The ping traverses the trunk twice (host 16 > router > host 17), and the reply traverses the trunk twice (host 17 > router > host 16).

Best Regards, News Reader