Friday, December 10, 2010

Native VLAN Horror - Can you solve the puzzle ?

Around 2 years back there was section called "Resources" on NMC Website. Actually plenty of good documents were out there on different R&S blueprint topics. Some of them were my favorite one. They created some scenarios based on few simple things like "Native VLAN", "SPAN/RSPAN" etc which most of you might be thinking about...ehhh...that's easy stuff and I can do even in sleep :-)


But there is always major difference between "knowing about things" Vs "Knowing things inside out". Though it's quite a lot of hard work one needs to do to achieve "Perfection" but still it's doable.


Without saying anything further let me share on of those interesting scenarios to challenge your understandings :-)


Or what Scott Morris call is "abusing people technically and in exiting new ways" hehehe :-)


Here you go:



HTH...
Deepak Arora
CCIE - 0::0/0 Null0

5 comments:

sushil menon said...

Hi Deepak,

As per my understanding the ping will work between R1 and R5. The below explanation hope so is correct.

1) R1 sends the ping packet out of sub-interface f0/0.10 which belongs to vlan 20 which is native on the router. f0/0 on R1 is trunk.

2) When the layer-2 frames are sent out of f0/0.10 they are untagged in the 802.1q header in which there is no VID mentioned. In fact for these frames there will be no 802.1q tag attached to the frames.

3) CAT1 receives the untagged frame on F0/1 which is a trunk port with vlan 10 configured as the native vlan on the trunk port.

4) CAT1 reads the frame as a regular frame since there is no 802.1q tag and treats this frame part of the same native vlan configured on CAT1 trunk port connected to R1 which is vlan 10. Frames received untagged on a 802.1q trunk port are forwarded to the native vlan 10.

5) CAT1 sends the frame through the another trunk port on fa0/13 in which native vlan is 20. Since these frames on CAT1 are originated on the native vlan 10 they will be tagged as they cross the trunk towards CAT2 since this trunk port is configured with native vlan as 20.

6)CAT2 on receiving this frame on fa0/13 will read the 802.1q tag in which the VID is vlan 10 and remove the tag and will forward the frame in vlan 10.

7) Only other port in vlan 10 in CAT2 is fa0/6 to which R5 is connected. the frame will be sent out of fa0/6.

8) On the return packet from R5 on fa0/6 CAT2 will forward the frames out of trunk port connecting to CAT1. While the frame enter the trunk port on fa0/13 on CAT2 they will be 802.1q tagged with VID of vlan 10 since the frames are originated in vlan 10.

9) CAT1 when receiving the frame will read the 802.1q tag of vlan 10 and remove the tag and forward the frame in vlan 10.

10) CAT1 will send the frame out of fa0/1 to R1, while doing so though fa0/1 being a trunk port it will not add the 802.1q tag to the frame since the native vlan configured on the trunk is vlan 10.

11) when R1 receives the frame it sees that it's a untagged frame and a untagged frame received on a 802.1q trunk port should be forwarded to the native vlan.

12) Hence the frame is forwarded to int fa0/0.10.

The ping works successfully.

I hope this helps.

Regards

Sushil

HEMANTH RAJ said...

It will surely ping from R1 to R5
because when R1 starts ping to R5 it send a packet with a native vlan id of 20 and when switch receives it ,it sees a untagged traffic with a native vlan id of 20 and it has its own native vlan id of 10.hmmm Is there a native vlan id mismatch between router and switch . hmmm No is the answer

Since the router port fa 0/0 is not a trunk port,there is no concept of native vlan mismatch,native vlan mismatch comes only in trunk links.

So when the frame arrives on the switch it is just a untagged frame.
Now it updates the source mac and its corresponding vlan in its mac table.

Ok now the frame is in CAT 1 fa 0/1
and it is a untagged traffic so untagged traffic should be flooded to all ports and the native vlan in CAT 1's fa 0/1 is vlan 10 so it gets flooded to all ports with a vlan tag of 10

So now the traffic gets into cat1's fa 0/13 , now native vlan id should match on both the sides because the traffic should pass a trunk link.

The native vlan is vlan 20
so the traffic with a vlan id of vlan 10 is passed through cat 2 fa 0/13

Now when CAT 2 receives it,it updates the source mac ,its vlan id in its mac table and checks for the destination mac,if it is present in its mac table, then it will send it to the particular port.if it is not there,so now it checks for the vlan number in the frame

It is vlan 10 so it gets forwarded to all ports which belong to vlan 10 and fa 0/6 is the port which belongs to vlan 10 and so the traffic reaches R5

So now when R5 sends a reply back to R1 it will send back to CAT2's fa 0/6 and CAT 2 will add a tag of vlan 10 and updates the source mac and its corresponding vlan in its mac table and checks for destination mac

The destination mac is R1's mac and it has been already known which is learnt via fa 0/13 it sends the frame to port fa 0/13 and the frame reaches CAT 1 with destination mac of R1's mac and a vlan tag of 10 and now CAT 1 forwards it to port fa 0/1

and now the ping gets successfull

The important gotchaa is vlan 20 that is configured in R1's fa0/0.10 which will not be carried since it is not a trunk link and it carries only a untagged frame

Hope sumone corrects me if i am wrong

Anonymous said...

Agreed, it will work. Traffic exists within VLAN 10 once it hits the switch. The native VLAN on the trunk between switches is irrelevant.

Anonymous said...

it will work..

- Since packet leave the R1 as untagged which will be assign to vlan10 since the port connected to the router has set vlan 10 as the native meaning all untagged traffic will be assign to vlan 10 as it get inside to this port.

Manar said...

Hi all,

I don't know if anybody is still waiting for the answer, I just reached here by chance, but I'll contribute any way :)

Assuming the switches are using the default settings, the ping will fail!!!

because the diagram says that: f0/7 on CAT2 is in vlan 10 but nothing about f0/6 where R5 is connected,
and by default f0/6 will be in vlan 1. However, if f0/6 was only a "typo" and f0/6 is configured in access mode and in vlan 10 then I think the ping will be successful.