After reading many posts about the VLAN features of the SM and AP…
I understand that you can configure the SM to add a VLAN tag to the packets which come in to the ethernet interface and go out the radio interface. To do this you need to set the “VLAN ingress ID” to the required value, e.g. 10.
So for example a normal PC sends an untagged packet. The SM attaches the VLAN tag with ID of 10 and sends it out the radio.
The AP leaves the packet unaltered so you need a device which understands VLAN tags on the AP side.
But what happens when the traffic is coming in to the radio interface of the SM? Does the SM remove the VLAN tags before sending it out the ethernet interface so that normal PCs can understand the packet or does it pass the packet unaltered?
Or… does the SM remove the tag of the configured VLAN only (10 in this case) and pass the remaining packets unaltered?
I noticed acherman seems to know alot about VLANs, your input would be appreciated…
That is a good question. My guess would be that it probably strips the VLAN portion of the Link Layer frame, but I could be wrong.
I have ran some bench tests with VLANs to get a basic understanding of their implementation in Canopy networks. Maybe my test explanation will answer your question.
I took one AP and two SM’s. I set both SM’s to tag Ingress packets with a VID of 10. I added 10 to the AP’s VLAN table. I terminated both SM’s into laptops. The NICs in the laptops were NOT VLAN capable. I sent a ping from one laptop to the other and got responses. Same results when pinging from the other laptop.
I changed the Ingress ID of one of the SM’s to 11. So I had one at 10 and one at 11. The same ping test failed.
So, I’m guessing that since I did not have VLAN capable NICs, that the SM must do some type of stripping of the VLAN ID in the Link Layer frame or else when both SM’s were on the same VLAN, the laptop would not what responded to the pings.
When acherman responds I’m sure he will have a better explanation, but I hope this helped somewhat.
Oh sure, pressure on me. It’s late, I just got back to the office, and I’m tired - these are my excuses if I say something stupid. 
haha
You are right - the radios will “untag” the packets if need be. Notice you have three options when configuring VLANs (both AP and SM) - allow all frames, untagged only, tagged only.
Assuming you have VLANs on and you are allowing all frames (default, best choice), when a packet comes into the wired interface the radio inspects the packet for the usual info (source address, destination address, QoS, etc.) and it also looks for the 802.1q VLAN tag. If this tag is present it does not alter it and proceeds based first on the rules you have set (dynamic or static VIDs) and then on bridging tables. If the tag does not exist the radio will add the tag you specify.
When a packet arrives via the wireless interface the radio does quite the same - I’m not sure if it decides using bridging tables first or VIDs first, but either way, both will be inspected and the correct action will be determined. If the VLAN tag is the same as the untagged ingress it will strip the tag and forward the packet as required. If the tag is different the radio will forward based on bridging tables (assuming it is either dynamically allowed or staic).
For example - I use VLANs all the time, today I set up a remote network. From one of my main APs I added an SM w/reflector approx. 14 miles away. On the same tower I placed an AP with azimuth about 120 degrees off, pointed in between a gas plant and a camp (2 miles LOS away from the tower and 1 km apart). The first SM and the remote AP are configured to pass 3 VIDs - management on VID 1 (untagged, more on this later), and two others for different network services to each site. At the the remote SMs they are configured for management on VID 1 and untagged ingress on other VIDs. In this application I can have the radio’s addressing on my management network while still allowing the customer data to flow on different subnets with no interaction with others.
Info on the management VLAN: It has been a while since I worked with this, but if I remember, I was not able to change the management VID of my access points - doing so would cause me to lose connectivity to them. :?: Also, I could not tag the manegement VLAN, this would also cause loss of connectivity. I’m not 100% sure on this right now, but this is the way I remember it. So I just make sure that all other traffic is tagged.
This has been really long, and I’m still tired. If I didn’t completly answer your question, or you have more, let me know. Did I make any spelling mistakes? I better proof read…
Goodnight… :?
Aaron
To make sure I understood everything correctly, consider these scenarios:
1- VLAN disabled:
The packet whether managemnent or data will traverse the SM and AP in both directions without getting changed.
2-VLAN enabled, management VLAN = 1, ingress VID = 5
-data packets coming in to the SM ethernet interface: if they are tagged pass them unaltered to the radio interface, if untagged a VLAN tag of 5 will be applied. the AP will pass the packets unchanged and transmit them out the ethernet interface
-data packets coming into the AP ethernet interface: if they are tagged forward them without change, if they are untagged add a tag of the management VID which would be 1 in this example.
-any management packets destined to either the SM or AP must be tagged with VID = 1.
===================
If what I wrote above is correct I would have another question, as far as I know VLAN1 is the native VLAN, so it should not be tagged with anything. So VLAN 1 traffic would be identified by not having any tags.
I set up the following lab:
PC1 … AP…SM … PC2
AP configured vlan enabled, allow all frames, mgmt vlan 1
SM configured ingress vlan 5, member of vlan 5, allow all frames, mgmt vlan 1
PC1 and PC2 are not vlan aware but they can capture vlan tagged packets with ethereal when running in promiscuous mode.
I pinged PC1 from PC2 and PC1 captured a packet tagged with VLAN 5–> ok
I pinged PC2 from PC1 and PC2 captured a packet tagged with vlan 1, this would mean that the AP tagged the packet with the mgmt VLAN iD of 1 which shouldn’t happen as vlan 1 is the native vlan???
1- VLAN disabled:
The packet whether managemnent or data will traverse the SM and AP in both directions without getting changed.
True, assuming the bridging tables allow it.
2-VLAN enabled, management VLAN = 1, ingress VID = 5
-data packets coming in to the SM ethernet interface: if they are tagged pass them unaltered to the radio interface, if untagged a VLAN tag of 5 will be applied. the AP will pass the packets unchanged and transmit them out the ethernet interface
Also true, assuming the bridging tables allow it and the VLAN membership table allows it.
-data packets coming into the AP ethernet interface: if they are tagged forward them without change, if they are untagged add a tag of the management VID which would be 1 in this example.
-any management packets destined to either the SM or AP must be tagged with VID = 1.
This is where I stop. I'm not sure but it seems that the management stuff won't respond to tagged packets (my experience from before) - when I tagged my packets with VID 1 I lost connectivity to my APs.
as far as I know VLAN1 is the native VLAN, so it should not be tagged with anything. So VLAN 1 traffic would be identified by not having any tags.
But wouldn't the absence of any tags make it "not a VLAN"?
I pinged PC2 from PC1 and PC2 captured a packet tagged with vlan 1, this would mean that the AP tagged the packet with the mgmt VLAN iD of 1 which shouldn't happen as vlan 1 is the native vlan??????
Ummm....... :?
Aaron
acherman, thanks for your comments.
I come from a Cisco background and there always is a native VLAN, by default VLAN 1, which is untagged.
Maybe the implementation here is a little bit different and the packets get tagged in all the VLANs
Maybe I’m complicating things too much, but wouldn’t a VLAN that is not tagged not really be a VLAN then? Dumb question. :lol:
Aaron
A VLAN does not just mean that there is a tag in the packet…
I will try to make my point more clear. You might already know this stuff.
A VLAN is normally used to limit broadcasts to selected switchports. On a switch the ports get assigned to their respective VLANs. When a broadcast packet is sent into a port the switch checks to which VLAN this port belongs and then forwards the packet out the ports which are members of this VLAN only. When a VLAN spans multiple switches and you have only one link between switches you have to configure the switches to form a trunk on the ports connected to this link. Now when a broadcast packet comes into a port the switch forwards it out all port of the same VLAn in addition to the trunk link. the switch on the other side has to know to which VLAN this packet belongs. In order to do so the sending switch adds a VLAN tag to the packet. The VLAN tag contains the VLAN ID. The receiving switch identifies the correct VLAN and then removes the tag and forwards the packet to the appropriate ports.
One exception to this is when the switch sends the packet over the trunk and that packet belongs to the native VLAN, in that case no tag is added. When the receiving switch sees a packet without the tag it assumes that it belongs to this native VLAN.
One exception to this is when the switch sends the packet over the trunk and that packet belongs to the native VLAN, in that case no tag is added. When the receiving switch sees a packet without the tag it assumes that it belongs to this native VLAN.
In this case wouldn't a legacy network with no 802.1q aware devices be a VLAN. haha :D I guess I just don't think of it that way, but thanks for making me think about it more. See, learn something new every day... 8)
Aaron
acherman wrote:
One exception to this is when the switch sends the packet over the trunk and that packet belongs to the native VLAN, in that case no tag is added. When the receiving switch sees a packet without the tag it assumes that it belongs to this native VLAN.
In this case wouldn't a legacy network with no 802.1q aware devices be a VLAN. haha :D I guess I just don't think of it that way, but thanks for making me think about it more. See, learn something new every day... 8)
Aaron
you are smart :), thats exactly the idea. The native VLAN without tag was made so you can put legacy devices in a VLAN aware network and consider them in a VLAN and they aren't aware of it.