Native VLAN vs trunk vs Default VLAN understanding

[SJ K]

Hi all,

Default VLAN as it is , is the defaulted VLAN in every switch setup which is 1.

Native VLAN is the VLAN that frames will not be tagged when transverse through a trunk link, and by default , it is 1  as well.

Assuming now i have a point to point connection setup between Switch 1 and 2 as a trunk.

q1) Does the above means that for management frames such as (VTP, STP, CDP) are all flowing through the trunk link untagged ?

q2) Does it also means that if I have done no explicit VLAN creation (default VLAN = 1), all traffic from devices connected to the switches are flowing through the trunk untagged ?

q3) If i change the native VLAN on switch 1 trunk port to e.g 10 -> does it means that now all traffic will be tagged as VLAN1 when flowing through the trunk ?

q4) and it will be dropped by the receiving trunk port at Switch 2 because the native vlan is still 1 over there and it should recieve the frame untagged.

q5) can default vlan be change from 1 to another number ? or can management frames be send using another VLAN number other then 1 ?

q6) i see in show ip int br that there is a default vlan 1 interface being shown. Is it created by default ?

With it being down, does it only means that I cannot access the management interface via IP, but whatever management frames and activities (cdp, stp, vtp etc) are still ongoing ?

Regards,
Noob

[SJ K]

Hi Rick,

Thanks for the reply and clarification.

By default the untagged frames in the native vlan would be processed by the physical interface of the router.

q1) In that case, can i say that there is a default vlan and native vlan in the router too ?

What will be the command to check and set the native vlan on the router ?

There is an optional configuration parameter as you configure the subinterfaces to set some other VLAN as the native VLAN.

If your router config does not have a subinterface for tagged frames in VKAN 1 then I would expect that the router would not process the CDP frames from the switch.

q2) Rick, as you mentioned, untagged frame are handled by the physical interface of the router and tagged frame are handled by their respective vlan subinterfaces.

In that case, what would be the use/ or scenario for the 1st sentence "There is an optional configuration parameter as you configure the subinterfaces to set some other VLAN as the native VLAN." ?

Regards,
Noob

[Richard Burts]

Noob

q1) Yes you could say that there is a default VLAN when you configure router subinterfaces to process tagged frames on a connection to a switch where the switch port is a trunk port. The command to set the native VLAN is the optional command that I mentioned.

q2) Handling untagged frames on the physical interface is the default behavior. Some people when they are configuring subinterfaces prefer that all VLANs be configured as subinterfaces, including the native VLAN rather than having most VLANs as subinterfaces but one VLAN on the physical. They believe that it makes the config more consistent.

Both approaches work. Some people prefer one and some people prefer the other.

HTH

Rick

[SJ K]

Hi Rick,

Thanks for the reply and sorry for the slow response.

q1) If my switch native vlan now is 1, i will be sending untagged frames of vlan1 over to the router through the trunk and it will be handle by the router's physical interface.

How do i set native vlan then on the physical interface of the trunk on the router's end?

q2) I have a router on a stick setup, with 2 vlans created 10 and 20. I left my native vlan untouched.  By right, i thought CDP frames belong to the management vlan, which is the default vlan of 1 -> which is also the native vlan set currently. And as per according to our discussion, it will be send untagged via the trunk link up to be handle by the router's interface.

However, in my packet trace, i found that the CDP frames that are

a) send from switch to trunk, are untagged as we have discussed.

b) send from router to switch have a total of 3 cdp frames

   1) untagged

    2) tagged with vlan10

    3) tagged with vlan20

Why is this so ?

Regards,
Noob

[Richard Burts]

Noob

q1) You do not set this on the router interface. It is automatically set up this way. If you think about it there is really quite simple logic for this. The router Ethernet interface understands normal Ethernet (untagged) frames and processes them. That is how the router interface will process the native VLAN because an untagged frame in the native VLAN is a simple plain Ethernet frame and the router interface already knows how to process that.

The router interface does not understand tagged frames and can not process them without special configuration (subinterfaces and the encapsulation dot1q commands). But untagged frames was what the router interface was built to process.

q2) This is an interesting observation and I believe has a pretty simple explanation. In router IOS when you enable CDP it will default to sending CDP frames out each of its interfaces that are in the up state. So on your router on a stick interface fa0/0 generates a CDP frame and sends it untagged. Interface fa0/0.10 is a separate interface and generates a CDP frame and since that interface used the encapsulation dot1q command then that frame will be sent tagged as part of VLAN10. And the same logic for the subinterface for VLAN 20 getting its own CDP frame.

HTH

Rick

[SJ K]

Hi Rick,

Sorry for the late reply and thank you for the response.

Hope you are still on this thread. I took sometime to re-digest everything and have 1 question.

q1) Lets assume on the router itself, it is sending out untagged frame while on the switch, its default management vlan is 1, but native vlan is 20.

When the switch received the router's CDP untagged frame, it will assume that it is for vlan20.   But there isn't any switchports assigned to vlan20.

Will the switch drop the frame ? or will it still process the CDP frame ?

q2) I am asking the above, because on the previous example, router sub-interfaces are sending CDP frames with vlan tags, but on the switch itself, there are no switch ports assigned for those respective vlans, and yet the switch still process the CDP frame and record the information down.

Regards,
Noob

[Richard Burts]

Noob

To be sure that I have a correct understanding, you are asking about an environment in which the router is sending untagged frames, including CDP, presumably from its physical interface. The switch is connected and has configured the port connecting to the router as a trunk, and has configured the trunk with native vlan to be vlan 20.

Your first point is correct that the CDP frame sent by the router as an untagged frame will be received by the switch and associated with vlan 20.

Your question is whether the switch will drop the frame or will process the frame. This is perhaps more complicated than you had originally thought and the answer depends somewhat on whether the frame is directed to a unicast host or is a multicast. The switch will do some processing on the frame whether it is unicast or is multicast.  If the frame is directed to a specific unicast host mac address then the switch will search its forwarding table. If it finds no match it will attempt to forward the frame out all access ports in that VLAN and out any other trunk that carries that VLAN. If it finds no access ports in that VLAN and no trunk carrying the VLAN then the switch will indeed drop the frame. But if the frame is a multicast then the switch figures out what it should do with the frame. And since the CDP frame is a multicast the switch will recognize that the multicast address is one that it should process and it will process the CDP frame.

HTH

Rick

[edited to correct an erroneous statement about switch behavior]  

[SJ K]

Hi Rick,

Yes, you are right. Thanks for the info.

q1) In that case, can we say that switches will look at the vlan as well as the dst mac address, before making a decision to drop or process the packet. 

If there is a tagged frame (with no associated ports in that particular tagged vlan), but with a multicast address, it will still be process by the switch as well - am i right ?

I am thinking in the line that, when a frame is received, tagged or untagged, the switch itself will look into the vlan/native vlan that the frame belongs to and then check the mac address table for all associated ports/members in that vlan to match the designated mac address against with.

Isn't then the above sort of "bypassing" the vlan tagging , since the frame will be process irregardless of the vlan tagged if it is a cisco multicast address / somehow its like the cisco device "itself" belongs to every vlan..

======================================================================

If the frame is directed to a specific host mac address then the switch will search its forwarding table and finding no matching entry in the forwarding table the switch will indeed drop the frame

q2) could there be any scenario, whereby a frame is designated to a unicast mac address, only to reach the other end of the switch whereby it has no matching entries in that vlan ?  (just wondering how it got the designated mac address in the 1st place).

- could it be caused by outdated arp cache ? and outdated mac address table ?
- how does cisco prevent such scenario from happening  ?

Regards,
Noob

[Richard Burts]

Noob

I must correct something that I said in my previous post. I said that if the switch receives a frame and if the switch does not find the destination MAC address in the MAC address table that the switch drops the frame. That is not the case and I wonder what caused me to write that. If we were talking about a layer 3 router or a layer 3 switch in its routing logic then it is true that if they receive a packet and can not find the destination address in their forwarding table then they will drop the packet. But for a switch at layer 2 that is not the case at all. The behavior of a switch doing layer 2 forwarding is that if the switch can not find the destination MAC address then the switch will forward the frame to all ports in the VLAN except the port on which the frame was received.

q1) Yes we can say that the switch uses information about the vlan as well as about the MAC address as it decides what to do with a frame. I do not follow your logic about how that becomes a "bypass" of vlan tagging.

q2) There certainly are valid scenarios in which a frame arrives at a switch and the switch does not have the MAC address in the MAC address table. One of the most common scenarios is the scenario where there is asymmetric traffic. Think of this situation  where we have 4 switches. SwitchA connects to SwitchB and to SwitchC and they connect to SwitchD (so it is a 4 sided figure). Host1 is connected to SwitchA and Host2 is connected to SwitchD. Then let us assume that Host1 sends traffic which goes from SwitchA through SwitchB to SwitchD. So SwitchB has learned the MAC address and put it into its tables but SwitchC has not learned the MAC address. Then let us assume that Host2 sends traffic to Host1 and that the frame from Host2 goes through SwitchD, to SwitchC. Now we have the situation where SwitchC has received a frame and does not have the MAC address in its table.

The other common scenario where a switch receives a frame and the destination MAC address is not in the table is based on a mismatch between the content of the ARP table and the content of the MAC address table. The ARP table in an IOS router ages out in 4 hours while the MAC address table in most Cisco switches ages out in 5 minutes. So we could easily have a router forward a frame with a MAC address from its ARP table but the switch no longer has that MAC address in its MAC address table.

You ask how Cisco prevents this and the answer is that Cisco gives you the option to configure the router with a shorter ARP timeout or to configure the switch with a longer MAC address timeout. There are good reasons why the default aging time for ARP on router is long and why the default aging time for MAC on switch is short. And if the mismatch is something that you want to fix then Cisco gives you an option to change one or the other timer.

HTH

Rick

[SJ K]

Hi  Rick,

No actually you are right. You did mentioned that the switch will broadcast and that the switch will drop the frame if it cannot find ports or trunks that can carries that particular VLAN.

Your question is whether the switch will drop the frame or will process the frame. This is perhaps more complicated than you had originally thought and the answer depends somewhat on whether the frame is directed to a unicast host or is a multicast. The switch will do some processing on the frame whether it is unicast or is multicast.  If the frame is directed to a specific unicast host mac address then the switch will search its forwarding table. If it finds no match it will attempt to forward the frame out all access ports in that VLAN and out any other trunk that carries that VLAN. If it finds no access ports in that VLAN and no trunk carrying the VLAN then the switch will indeed drop the frame

So my initial question is that when an untagged frame reaches a switch and is handled as a native vlan.  Why isn't it dropped but processed by the switch instead as there are no associated access ports with that vlan (20)

Your answer is that because it has a multicast address

=======================================================

In a normal unicast tagged frame, if there are no associated ports with the vlan of that tagged frame, the frame is dropped and not processed any further. The destination mac of the frame is not even put into consideration.

In a multicast tagged frame (being handled as native vlan), even if there are no associated ports of that vlan, it is still being handled by the switch itself.

Hence in this manner, its seems like the "switch" or the "multicast mac address" seems to be a member of that vlan (even though there are no physical ports).

Therefore, even if the multicast frame is tagged with whatever vlan, it will still be processed by the switch.  (by passing the need of having a vlan tag - which is to segregate traffic base that belong to a particular vlan from other vlan)

let say the multicast frame is tag with vlan50, even though there no associate ports with vlan50, it is still being processed
and if the multicast frame is tag with vlan40, even though there no associate ports with vlan40, it is still being processed

So what i meant is, the multicast frame is for cisco CDP and it will be handled by the switch itself irregardless of whatever vlan the frame is in;

Regards,
Noob

[Richard Burts]

Noob

Perhaps part of the way to resolve this question is to recognize that in some sense a switch is a participant in every vlan that is configured on the switch and sent through a trunk port. or is configured on an access port. So as it processes a frame arriving on the trunk port and having a vlan tag the switch can recognize that the destination MAC address (in this case a multicast MAC) is addresses to the switch itself and so is processed by the switch.

HTH

Rick

[SJ K]

Hats off Rick,

That's what i actually meant. Even i have difficulty trying to understand myself ;)

Regards,

Noob

[Richard Burts]

Noob

I am glad that we have been able to clarify this aspect of switch operation.

HTH

Rick