trunk with default native vlan question

paul amaral · ‎02-08-2012

hi all,

I havea cisco 6500 that is connected to a cisco 3500 over an access port. The access port connects to vlan 105 only on the 6500 and to vlan 1 on the 3500. Because this is an access port and not a trunk no traffic gets tagged, i believe therefore all comnunications from/to vlan 105 to vlan 1 are working. (correct me if im wrong)

However i have an issue where i want to separate some subnets on my routed vlan 105 and create an additional routed vlan, lets say vlan 107. So on the 6500 i would now have vlan 105 and 107. I reliaze i would now need to change the link between the switches to a trunk to carry multiple vlans ids.

So on the 3500 i would create certain ports on vlan 105/107. However on the 3500 i'm not able to change all ports to be part of vlan 105/107 and some traffic with go down the trunk untagged as vlan1 traffic. ( i have other switches connected to the 3500 all on vlan 1)

My question is what will happen to traffic bound for the 6500 from the 3500 that is not tagged, note that on the 6500 i do have VLAN1. Will untagged traffic for ip address 1.1.1.1 that is on vlan 105 make it to that vlan or will it look at vlan1 on the 6500 and drop that packet.

Basically im trying to see if untagged ip traffic will make it to the correct vlan interface if the destination ip is on vlan 105 or 107 and not get dropped by vlan1.

Also will it be a problem when thr 6500 send traffic to the 3500 tagged as 105/107 destined for a vlan1 port?

thanks for yout time, Paul

phiharri · ‎02-13-2012

Greetings Paul,

Untagged traffic on a dot1Q trunk will be handled as though it was traffic ingressing an access port in the native VLAN, by default 1.

You could set the native VLAN on the 6500 side to your existing VLAN 105 using the command 'switchport trunk native vlan 105' and leave the 3500 with the default native config to effectively 'translate' traffic entering VLAN 1 ports on the 3500 into VLAN 105 on the 6500 and vice versa.

I'm a bit puzzled by you saying "on the 3500 i'm not able to change all ports to be part of vlan 105/107", why exactly is that? The preferable solution would be to have consistent VLAN numbering on the whole network and avoid incongruent access or native VLANs at either end of a link, which may cause confusion down the road.

Cheers,

/Phil

paul amaral · ‎02-13-2012

Phillip, thanks for your reply.

I do know about the option to select the native vlan and i thought about using it like you stated above.

What i meant was on 3500 switch i have many customers that traverse this switch, there are several 3500s connected together via STP actually, because of this and the associated down time reconfiguring all the switches to set each customer traffic to their own vlan it's just not possible right now and this should of been done from day one .

The thing is im now going to be forced on the 3500 connected directly to the 6500 to bring in some tagged, vlan105/107 traffic along with untagged traffic vlan1 because i got only one physical link back to the 6500. Im concerned as to what could go wrong because on the 6500 i will have vlans 1,105 ,107 at the end of the trunk and with tagged and untagged traffic coming in to the 6500 i wanted to make sure that vlan1 on the 6500 doesnt mess things up.

So i could probably do what you suggested but i dont think its going to make a difference. If I make vlan 105 the native vlan on the 6500 end of the trunk it would send all vlan 105 traffic untagged to the 3500 side but send tags for vlan 107 etc.

On the 3500 the access ports for vlan 105 and vlan 107 would be able to accept untagged traffic from the 6500 (from my lab tests all non native vlans accept untagged traffic) and all native vlan access ports (vlan1 on the 3500) would also be able to accept the untagged vlan 105 traffic along with the tagged traffic for vlan 107 to the vlan 107 access ports on the 3500 (again from my lab tests native vlan ports accept all tagged and untagged traffic and all non native vlan ports will accept untagged traffic as well)

I guess i just didnt want vlan1 on the 6500 to be involved with traffic from the 3500 but this is going to be impossible if i configure a trunk as it looks like all vlans on the 6500 with listen to this incoming traffic on the trunk and i just wanted to make sure that vlan1 on the 6500 ( which is seperate from vlan1 on the 3500) doesnt cause an issue although i dont think it will since there is no vlan1 ip subnets on the 6500 associated with the ips in vlan1 on the 3500.

When i originaly asked this questing i didnt know how tagged traffic was handled by ports on the native vlan which again seems to be accepted.

paul

bridgepartners · ‎02-14-2012

Paul

I understand your reluctance to change the whole 3500 network to meet your current needs but I would urge you to consider fixing it in a downtime window.

If you really cannot do this then you are heading into territory where VLAN number mean different things on different groups of switches. The native VLAN on a trunk is one way of doing this (and is usually considered to be a misconfiguration). You will need to make sure that it is very well documented and communicated to other administrators. If you set native VLAN x on the 3500 and native VLAN y on the 6500 then one will be translated into the other and vice versa. The switches will not 'know' that you have done this.

If you do not want VLAN 1 on the 6500 to travel to the 3500, have you though of creating a new VLAN on the 6500 which would be 'VLAN 1 on the 3500' - let's call it VLAN 101? It can live on the 6500 and not interact with any of the other existing VLANs. You can then use this VLAN 101 as the native VLAN on the 6500 end of the trunk and VLAN 1 on the 3500 end.

Sorry if I have misunderstood your problem.

Daniel

paul amaral · ‎02-14-2012

Daniel, i agree with you i think the key is documentation as this will not your normal setup but again i been testing this on a lab setup and i think i can pull it off without issues. You make very good points though.

paul

ebarticel · ‎02-14-2012

Hi Paul,

What type of encapsulation are you using, or planning to use on trunks? If you consider dot1q the native vlans have to be the same on both end of the links.

Hope this helps

Eugen

paul amaral · ‎02-14-2012

I'm using dot1q, which you can specify any vlan as the native, untagged vlan. I believe dot1q will also omit any native vlan info from the header unlike ISL.

bridgepartners · ‎02-20-2012

If you consider dot1q the native vlans have to be the same on both end of the links.

I am not sure they have to be, although certain problems may arise. There is a good discussion on it here:

https://learningnetwork.cisco.com/thread/6543.

Daniel

paul amaral · ‎03-30-2012

I wanted to update on this for a description read the original post.

So on my 3500 switch once I turned the connecting interface to the 6500 to a trunk on both switches I lost communications with the 3500 switch. This was because on the 3500 all ports and management ip were on vlan 1 coming in to the 6500 on access vlan 105 which was working when there was no trunk due to "switch port access vlan 105" on the 6500 incoming interface.

However once you put a dot1q trunk in place between the two switches you will lose the ability to have different number vlans talk to the final destination vlan because you are removing the destination port's "switchport access vlan xxx" statement so when a packet comes in untagged it will switch it to vlan 1 (native vlan) and in my case the 3500 was using an ip from vlan 105 on the 6500 but the packets were leaving the 3500 untagged and were ending up on vlan 1 on the 6500 where there was no such ip/subnet and it dropped all packets.

What i ended up doing was change the interface on the 3500 that connects to the 6500 and put that on vlan 105 so now all packets leaving the 3500 get tagged into 105 and will be switched to the correct vlan interface on the 6500.

So switch ports dont care about incoming untagged frames and will switch everything according to the destination port "switchport access vlan xx" statement because the receive frames have no tag.

Trunks on the other hand get tagged on the outgoing interface from switch to switch and that frame once it hits the destination switch is switched based on that tag.

hope this helps/makes sense.

paul