Etherchannels and use of native VLANs

mwaterhouse · ‎12-15-2009

Hi,

We are currently migrating our network to RFC1918 (private address ranges).

A precursor for this is to create the new networks and obviously maintain routing between the old and new.

I have elected to use etherchannels between the major networks (old 89.0.0.0/8 ranges and the new 192.168.x.0/24 ranges (4 Vlans)) not for throughputs sake alone as traffic is expected to be minimal but more for resiliency and throughput in the event of a large transfer since the endpoints are gig. See diagram below)

Normally vlanning the traffic down (with support for vlans and 802.1q at remote ends) wouldnt be an issue but unfortunately we are not blessed with decent switches throughout (many being dumb switches) the first switches that form the etherchannel do support trunking though (static and LACP supported)

I am using the following config on the core 3560G,

ip routing

~~~~~~SNIP~~~~~~~~~~~~~~~

interface GigabitEthernet0/1
description Port Channel to Legacy Network (VLAN 89) (89.0.0.0/8)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/2
description Port Channel to Legacy Network (VLAN 89) (89.0.0.0/8)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/3
description Port Channel to Server Network (VLAN 10) (192.168.10.0/24)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode on
!
interface GigabitEthernet0/4
description Port Channel to Server Network (VLAN 10) (192.168.10.0/24)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode on

~~~~~~SNIP~~~~~~~~~~~~~~~

interface Vlan10
description vlan10 server core network
ip address 89.0.0.0 255.0.0.0
ip helper-address 192.168.10.1
ip helper-address 192.168.10.2
!

interface Vlan40
description Sales vlan
ip address 192.168.40.254 255.255.255.0
ip helper-address 192.168.10.1
ip helper-address 192.168.10.2
!

~~~~~~SNIP~~~~~~~~~~~~~~~

interface Port-channel1
description Layer2 Trunk to legacy
switchport trunk encapsulation dot1q
Switchport trunk allow vlan 89

switchport mode trunk
!
interface Port-channel2
description Layer2 Trunk to server network
switchport trunk encapsulation dot1q
Switchport trunk allow vlan 10
switchport mode trunk
!

Obviously the traffic will not route as the frames ingressing/egressing the dumb switches arent tagged.

If I specify the native vlan with,

switchport trunk native vlan x (where x is the vlan for the give IP range)

The traffic is routed as expected.

Obviously this is not strictly using dot1q to retag the frames as they stay in the native vlan. We only need the single vlan on each of the dumb switches. Vlans will not be propogated out to the switches.

My question is will this config cause problems or is there a better way of doing it without upgrading the switches (which we are doing in about 10 months however cannot yet)? What do I have to watch out for if i do use this config?

Please be gentle as I am not that familiar with trunks/etherchannels etc.

Thanks VERY much in advance for any replies.

Jon Marshall · ‎12-15-2009

mwaterhouse wrote:
Hi,
We are currently migrating our network to RFC1918 (private address ranges).
A precursor for this is to create the new networks and obviously maintain routing between the old and new.
I have elected to use etherchannels between the major networks (old 89.0.0.0/8 ranges and the new 192.168.x.0/24 ranges (4 Vlans)) not for throughputs sake alone as traffic is expected to be minimal but more for resiliency and throughput in the event of a large transfer since the endpoints are gig. See diagram below)
Normally vlanning the traffic down (with support for vlans and 802.1q at remote ends) wouldnt be an issue but unfortunately we are not blessed with decent switches throughout (many being dumb switches) the first switches that form the etherchannel do support trunking though (static and LACP supported)
I am using the following config on the core 3560G,
ip routing
~~~~~~SNIP~~~~~~~~~~~~~~~
interface GigabitEthernet0/1
description Port Channel to Legacy Network (VLAN 89) (89.0.0.0/8)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/2
description Port Channel to Legacy Network (VLAN 89) (89.0.0.0/8)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/3
description Port Channel to Server Network (VLAN 10) (192.168.10.0/24)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode on
!
interface GigabitEthernet0/4
description Port Channel to Server Network (VLAN 10) (192.168.10.0/24)
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode on
~~~~~~SNIP~~~~~~~~~~~~~~~
interface Vlan10
 description vlan10 server core network
 ip address 89.0.0.0 255.0.0.0
 ip helper-address 192.168.10.1
 ip helper-address 192.168.10.2
!
interface Vlan40
 description Sales vlan
 ip address 192.168.40.254 255.255.255.0
 ip helper-address 192.168.10.1
 ip helper-address 192.168.10.2
!
~~~~~~SNIP~~~~~~~~~~~~~~~
interface Port-channel1
 description Layer2 Trunk to legacy
 switchport trunk encapsulation dot1q
 Switchport trunk allow vlan 89
 switchport mode trunk
!
interface Port-channel2
 description Layer2 Trunk to server network
 switchport trunk encapsulation dot1q    
 Switchport trunk allow vlan 10
 switchport mode trunk
!
Obviously the traffic will not route as the frames ingressing/egressing the dumb switches arent tagged.
If I specify the native vlan with,
switchport trunk native vlan x (where x is the vlan for the give IP range)
The traffic is routed as expected.
Obviously this is not strictly using dot1q to retag the frames as they stay in the native vlan. We only need the single vlan on each of the dumb switches. Vlans will not be propogated out to the switches.
My question is will this config cause problems or is there a better way of doing it without upgrading the switches (which we are doing in about 10 months however cannot yet)? What do I have to watch out for if i do use this config?
Please be gentle as I am not that familiar with trunks/etherchannels etc.
Thanks VERY much in advance for any replies.

If you have switches that do not understand 802.1q tagging then yes the only way to get the traffic to work would be to not tag the vlan that is present on the switch. So you are doing the correct thing. However it's not clear how the topology works.

Are the dumb switches each connected to the non-dumb switches or are they chained off each other.

A simpler solution if i understand your topology would simply be to use L3 etherchannels to connect the 2 networks together and then you do not have to worry about native vlans etc.

However it's very difficult to be more precise at the moment. Couple of things need clarifying

1) How are the dumb switches connected up

2) Does each dumb switch only support one vlan. If you have chained dumb switches is it safe to assume that any chained switches use the same vlan

3) What are the switches at the other end of the etherchannel on the 3560G.

Jon

mwaterhouse · ‎12-15-2009

Thanks very much for your reply,

In response to your questions,

If you have switches that do not understand 802.1q tagging then yes the only way to get the traffic to work would be to not tag the vlan that is present on the switch. So you are doing the correct thing. However it's not clear how the topology works.

Are the dumb switches each connected to the non-dumb switches or are they chained off each other.

The majority of the switches that will be connected to the ether channel are "smart" switches however one or two may be dumb. Off these single switches may be chained of which a few are totally dumb. Ive attached a diagram which may be helpful to more understand the setup.

A simpler solution if i understand your topology would simply be to use L3 etherchannels to connect the 2 networks together and then you do not have to worry about native vlans etc.

THANKYOU!! Exactly my thoughts. My first config actually used L3 ECs however our managed wan provider thought that L2s with VLANs would be more appropriate. I dont fully understand their reasoning for this. True they do intend to bring two different VLANs over a leased line to us but they wont be routed to any of the networks/vlans on the dumb switches. We dont need any of the security between the vlans or to trunk multiple vlans so I dont really se the necessity to vlan throughout. I need to contact them to get further info.

However it's very difficult to be more precise at the moment. Couple of things need clarifying

1) How are the dumb switches connected up

See diagram, please shout if you need further clarification

2) Does each dumb switch only support one vlan. If you have chained dumb switches is it safe to assume that any chained switches use the same vlan

I assume so

3) What are the switches at the other end of the etherchannel on the 3560G.

Some of them are NetGear smart switches, some are 3com

mwaterhouse · ‎12-16-2009

Sorry, another quick question in case you reply back to this thread..

If we do go L3 etherchannels I read somewhere that vlan1 is switched in software where others are in hardware. Ive never heard of anything like that before, is there any truth in that statement and if so i assume its best practice to use a different vlan (as discussed, security to management vlan is not an issue here).

Thanks again.

Jon Marshall · ‎12-16-2009

mwaterhouse wrote:

Sorry, another quick question in case you reply back to this thread..

If we do go L3 etherchannels I read somewhere that vlan1 is switched in software where others are in hardware. Ive never heard of anything like that before, is there any truth in that statement and if so i assume its best practice to use a different vlan (as discussed, security to management vlan is not an issue here).

Thanks again.

Mike

Apologies for the delay in getting back.

Did you manage to talk to the provider as to why they recommended a L2 trunk etherchannel ?. Do the switches connecting directly to the 3560G support L3 etherchannel because it's still not entirely clear what exactly connects to what. If you are simply temporarily connecting 2 networks and the vlans in the new network do not need to exist on the old network then i would go L3 and route between.

The only thing that occurs if is your provider WAN link needs to carry vlans for both the old and the new networks in which case you would need to look at L2.

** Edit - and even if the WAN link needs to carry vlans for both networks it still depends where that WAN link terminates.

As for vlan 1, i have never heard of it being switched in software. In fact as the default vlan is vlan 1 on all switches and a lot of people leave all the client ports in vlan 1 by default then it wouldn't be a very good advertisement for the speed of switches if all data traffic was being software switched

What it may be referring to is that vlan 1 is also used for control protocols such as CDP/PaGP/DTP and with the exception of DTP still is even if you change the native vlan. I suspect that this control traffic needs to be processed by the main CPU of the switch ie. software rather than a dedicated ASIC. But this traffic is negligible compared to the data traffic going through the switch.

Jon

mwaterhouse · ‎01-05-2010

Jon, Sorry for the delay, I cant thank you enough for your input! Much appreciated.

I havent heard back from the WAN providers yet on their plans, probably due to xmas and the like.

My best guess is that they will be bringing the traffic in for the new and old networks in on different VLANs which will then be connected directly into the layer 3 3560.

In response to your questions,

Apologies for the delay in getting back.

Did you manage to talk to the provider as to why they recommended a L2 trunk etherchannel ?. Do the switches connecting directly to the 3560G support L3 etherchannel because it's still not entirely clear what exactly connects to what. If you are simply temporarily connecting 2 networks and the vlans in the new network do not need to exist on the old network then i would go L3 and route between.

The switches do indeed support L3 etherchannel. I have two configs, the one using L3 etherchannels and the one using L2s and both work, it just depends on the WAN providers design of which would be best to deploy. The second part of your assumption is correct however as discussed I need clarification from the providers.

The only thing that occurs if is your provider WAN link needs to carry vlans for both the old and the new networks in which case you would need to look at L2.

** Edit - and even if the WAN link needs to carry vlans for both networks it still depends where that WAN link terminates.

The WAN link will terminate directly into the layer3 switch as the firewall will be hosted off site.

Just a quick question that I have been trying to get my head around. If the WAN providers bring in the traffic for the two networks on two VLANs that terminate on the L3 switch. Does the traffic have to stay on the VLANs throughout the link from source to destination or can they be routed via the layer 3 etherchannens once ingressed into the 3560?

As for vlan 1, i have never heard of it being switched in software. In fact as the default vlan is vlan 1 on all switches and a lot of people leave all the client ports in vlan 1 by default then it wouldn't be a very good advertisement for the speed of switches if all data traffic was being software switched

What it may be referring to is that vlan 1 is also used for control protocols such as CDP/PaGP/DTP and with the exception of DTP still is even if you change the native vlan. I suspect that this control traffic needs to be processed by the main CPU of the switch ie. software rather than a dedicated ASIC. But this traffic is negligible compared to the data traffic going through the switch.

Thanks very much for that. Makes perfect sense and I would have normally dismissed the comment however the source actually said that it was told to him by his instructor!!! As you so rightly pointed out, with vlan1 being the default which I presume many people use through lack of knowledge it would be insanity to switch it in software.

Thanks again for your comments and ongoing help.