Passing vlan across unmanaged switch

[ryan.memmott]

Hello CSC,

     I am trying to figure this out. I have two vlans I am trying to run to a trailer. One is for our wireless network(vlan2) and one for our wired(vlan3). Unfortunately I have only one physical link back to the main network, an unmananged SR2024C, and a WAP4410N. So, I came up with this solution to keep my networks seperate.

     I configured the port on my Cisco 3560 that runs out to the trailer as trunking with native vlan3. This connects to the unmanaged SR2024C switch in the trailer. All the wired devices that connect should and are being put on vlan3. I then configured the WAP4410N to use a default vlan2, with the SSID of my wireless network on vlan2 as well. My wireless device connect and are able to communicate back to the network, but are on vlan3. Also, I cannot connect to the WAP4410N from the main network, but if I configure my laptop with a static IP on from vlan2, I can connect to the WAP while plugged into the SR2024C.

Diagram below shows the config on the C3560G for int gi1/1 and the WAP4410N vlan info.

Thank you in advance for any help!

[Richard Burts · Accepted solution]

This is a creative solution and it results in connectivity. But it does not accomplish part of what you want, and I think that there is not any solution that will accomplish what you want other than changing switch hardware.

The reason that we create two vlans is so that we can separate their traffic. If vlan 2 is for wireless and vlan 3 is for wired then we want any broadcast traffic from the wireless vlan 2 to not be received by any device in wired vlan 3. Unfortunately your switch does not understand vlans. It has all of its ports in the same broadcast domain. So if there is a broadcast sent by a wireless device (thinking that it is in vlan 2) that broadcast will be received by all of the wired devices connected to the switch.

The wireless controller thinks it is in vlan 2 and uses addressing based on vlan 2. But when you configure the wireless controller to use vlan 2 as the default vlan then it sends its Ethernet frames as untagged frames. And the unmanaged switch is sending those frames over its access port to the 3560 which treats them all as belonging to vlan 3.

The good news in this is that you have basic connectivity. The bad news is that you do not have any separation between the wired network and the wireless network. The only way that I see that you can achieve the separation between the networks is to replace the unmanaged switch.

HTH

Rick

[ryan.memmott]

Rick,

      Thank you for the reply. It does make alot of sense. I read that devices that don't understand vlan tags will ignore them, which is why I thought this would work. But only if the tags for vlan2 are inplace when they leave the WAP. But because the default vlan is 2, then when they pass the interface the tags are dropped. I tried using an option to have SSID MyWAP use vlan2 as tagged, but that resulted in no connectivity. What I might try now that you mentioned what the default vlan is doing, is changing the default vlan to 1, and see if those tags remain in place. It may end up doing the same thing as the tagged setting, but it is worth a shot. If all else fails, I'll jave to run a second line or get a managed switch. I'll post here the results of the default vlan change. Thanks for the information!

[Martin Carr]

You have two options, either connect the AP directly to the 3560, or buy a managed switch, as said.

What happens is when a 'trunk' is confgured, a header (aka tag) which varies in size depending on what encapsulation is used, is added to the front of the a frame, by doing this the destination knows which VLAN it belongs when it arrives.

You don't have a trunk, and the uplink port needs to be an access port, and should be in VLAN 3 if you plan on keeping it like that.

Martin

[glen.grant]

  You could even get something used or older like a 2950 or a low end 2960 to do what you need it to do .

[ryan.memmott]

Results are negitive. Configuring a different default VLAN than the SSID's vlan is the same as using the tagged option. Still, I am curious as to why this doesn't work. From what I have learned about VLAN tagging, VLAN tags are transparent to device that do not reconize dot1q. This is because dot1q encapsulation is not a true encapsulation. The length of the frame is increased, and field is added after the addressing fields. Perhaps my current switch is filtering jumbo frames or frames with an invalid ethertype field. And perhaps if I had a dumber device, this would work.

For now the plan is to buy a manageable device. Thank you all.

[Richard Burts]

You are mistaken in believing that a tagged frame is completely transparent to a device that does not recognize dot1q. Here is what the configuration guide for a Catalyst switch says about this " If an access port receives a tagged packet (Inter-Switch Link [ISL] or IEEE 802.1Q tagged), the packet is dropped, and the source address is not learned." You can use this link if you would like more details about this.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swint.html

HTH

Rick

[ryan.memmott]

You are right in that an access port on the Cisco 3560 will drop tagged frames. But the port on the Cisco 3560 is a Trunk. The problem I suspect is on the middle-man, the Cisco SR2024C. I've done some research and think I found two possible answers. 

1. The IEEE 802.3 Ethernet standard calls for a maximum limit of 1500 bytes to frames. The Dot1Q standard allows for 1522 byte frames. So when the vlan 4byte tag is insterted into a 1500-byte from, the Cisco SR2024C will drop the Jumbo frame.

2. The IEEE 802.3 Ethernet standard calls for a EtherType/Length at the 21 and 22 byte. With Dot1Q encapsulation, four bytes are inserted into the 21-24 postion and the EtherType/Len is now at the 25/26th byte. The frame is then dropped by the Cisco SR2024C due to an invalid EtherType/Len.

Both may be true. If I had a dumber device that simply rebroadcasted the frames or a switch that is only concerned with the Destination (and maybe source) MAC address, this would work. Unfortunately, the SR2024C seem just smart enough to break this.

[Richard Burts · Accepted solution]

I agree with you that the issue is on the SR2024C. It does seem that it has a problem with the tagged frames. My guess is that it is caused by the EtherType/Length, but it could also be a factor of the frame length. Whatever the cause I think that the solution is to replace that switch, hopefully with a managed switch that does support trunking and tagged frames.

HTH

Rick

[Martin Carr]

But it's only working for the native VLAN, whose frames are untagged, that why I said it could be an access port.

Martin

[ryan.memmott]

I guess I don't understand what port you are referring to. But I think I do know what you mean. Essentially, all I have is an access port on both the Cisco 3560 and WAP4410N because I don't have the capabilty to transmit tagged frames between them.

[Martin Carr]

The port that you have uplinked your SR does not need to be a trunk port, seen as that is not possible. It just needs to be an access port in VLAN 3, what you have done is over complicated as you have to specify the native VLAN to get it working, in addition it also creates security concerns, i.e. 'VLAN hopping'.

Martin

[ryan.memmott]

You are right, it is over complicated considering the current capabilities. I appreciate the help.

[Martin Carr]

As I say, it adds a 'tag' to the front of the frame, which is then decapsulated and forwarded to the respective VLAN, the consensus is it depends on the hardware, if you are defiently tagging then it will just be switching the frame out, otherwise it will drop it.

Are you are defiently tagging? If so then I have thought of a theory, but even if it worked, the two LANs will never physically be seperate. 

Martin