Will the Canopy product (AP, SM, or BH) transparently pass any existing 802.1q tags?
We have a customer with an existing Cisco bridge application which we may replace with Canopy. We were going to replace the Cisco devices with another 802.11 based product, but the 802.11 based product we were going to use stripped off the 802.1q VLAN tags, which would break the customer’s topology.
Thanks,
Matt
Yes, the BH units will transparently pass 802.1q tags, I run trunk links between switches across BH units.
Far as AP/SM, I will enable VLANs on the AP so that it (and the connected SMs) run 802.1q as well, and have trunked to switches behind the SMs. Have done this with Cat6500s all the way down to Cat 2900XL units.
Assume I have:
(1) AP
(2) SMs
The AP and both SMs are connected to 2960s, and the ports the Canopy units are terminated to are trunked ports.
Does the Canopy system need to be configured for VLANs, or will the system transparently pass all of the traffic because it is already tagged?
Thanks,
Matt
I believe that unless VLANs are enabled, tagged frames will either be dropped or you will hit an MTU issue.
In this scenario I would recommend setting a management VLAN on all your equipment that does not conflict with your customer’s VLANs, enabling Dynamic VLAN Learning on your Canopy gear, and then disabling SM Isolation on the AP. Of course this is assuming that AP has nothing but these two sites on it. If not, something like an L2TPv3, L2TP/IPSec or OpenVPN tunnel hairpinned by a router would be ideal. I am fairly certain that none of the Canopy PMP products support Q-in-Q… some of the backhauls might, however.
Good call to get away from the 802.11 stuff, though there are vendors that support passing VLAN tags. Even Tranzeo can accomplish this…
Thanks for the reply and the information.
The trunk ports on the Ciscos switches that terminate the current 802.11 equipment are native members of VLAN 23, which is the management VLAN for all of the company’s networking equipment.
So to go along with your first recommendation, in this particular scenario, I would set all of the Canopy devices to a Management VLAN ID of 23.
So if “Dynamic Learning” is enabled, I am guessing that the Canopy gear will snoop the frames at Layer-2 and extract the 802.1q VID from the header and add that numeric value to the Canopy device’s dynamic table? The AP would indeed only have the two (2) remote sites connected.
What if we ended up deplyoing two (2) dedicated PTP Canopy BH links as opposed to the Multipoint topology…would VLAN configuration still be required on the BH units, or will they transparently pass the 802.1q tags?
Thanks for the help. I’m going to have to download the latest manual. It’s been awhile since I have used Canopy or kept up with any of the theory.
Thanks,
Matt
Yes, you would place them on VLAN 23 if the customer were to have management access to this equipment, or if you manage the customer’s gear, or whatever. You would of course have to change the switch configuration so 23 was no longer the native VLAN.
You are quite right - without Dynamic Learning enabled, the Canopy gear drops tags for VLANs that are not in it’s membership table. This is analogous to having “switchport trunk allowed vlans” in your config.
Unfortunately I am not very familiar with Motorola’s PTP units as we prefer Redline for backhaul links. If it’s anything the same, the “VLAN” feature on the units should just control how the management interface responds. Product manuals would be your best bet here 
Cheers
Yes I just downloaded the latest manual and have been reading the VLAN section, in addition to logging into a customer’s network that we designed which has two (2) PTP BH links.
You are correct, the only VLAN configuration parameters available in the GUI of the BH units is to Enable or Disable the VLAN feature, and, to set the Management VID.
Thanks again for the help.
Matt
msmith wrote:
What if we ended up deplyoing two (2) dedicated PTP Canopy BH links as opposed to the Multipoint topology...would VLAN configuration still be required on the BH units, or will they transparently pass the 802.1q tags?
BH units will pass the 802.1q tags transparently. Word of caution, make sure you set the native VLAN on the switches to be the same as your BH management network, else you won't be able to log into them. I've stranded BH units like that before.
Thank you for the reply. I will make sure to do so.
if vlan 23 is your cisco “native” vlan then setting your canopy management vlan to 23 will not work. actually leave the canopy management vlan set off since the cisco will expect “native” vlan traffic to be untagged. actually the better solution would be to not set the “Switchport trunk native vlan” command on the port connected to your canopy equipment and turn management tagging on with vlan 23, that way you know exactly the the fuck is going on!
So if the native VLAN of a Cisco switch is configured to be 23, and Ciscos do not expect incoming native VLAN traffic to be tagged, does that mean that management traffic used to manage the switch needs to be coming from a port on the switch that is a port-based member of VLAN 23 rather than a .1q tagged frame?
Does that also mean that when Canopy devices have their Management VLAN configured, that the http (or whatever) management interface on the Canopy unit will only permit access if an incoming frame is “tagged” with the appropriately configured management VLAN? For example, if I configured my Management VLAN on a Canopy device to be 99, does that mean that the Canopy device inspects each Layer-2 frame and looks for a .1q header, and if it equals 99, the mangement interface will open, else, the packet is dropped?
msmith wrote: So if the native VLAN of a Cisco switch is configured to be 23, and Ciscos do not expect incoming native VLAN traffic to be tagged, does that mean that management traffic used to manage the switch needs to be coming from a port on the switch that is a port-based member of VLAN 23 rather than a .1q tagged frame?
Er, sort of.
This is how most normal trunk ports look:
switchport mode trunk
switchport trunk encapsulation dot1q
switchport trunk allowed vlans 9,23,42,505,999
[switchport trunk native vlan 1] <- default command so it is hidden
All you have to do is issue "switchport trunk native vlan 23" to have VLAN23 sent with not 802.1q tags over that trunk port. Note that VLAN23 must still be in the allowed list - in my example above, VLAN1 traffic isn't actually transmitted. Older switches like Cisco 2924s always have VLAN1 and 1000-1005 enabled. This does not affect the behaviour of any other ports on the switch.
msmith wrote: Does that also mean that when Canopy devices have their Management VLAN configured, that the http (or whatever) management interface on the Canopy unit will only permit access if an incoming frame is "tagged" with the appropriately configured management VLAN? For example, if I configured my Management VLAN on a Canopy device to be 99, does that mean that the Canopy device inspects each Layer-2 frame and looks for a .1q header, and if it equals 99, the mangement interface will open, else, the packet is dropped?
Yes, the onboard NIC will ignore any frames that do correspond to its management VLAN tag. Of course it will still pass them down the line.
salad wrote:
switchport trunk encapsulation dot1q
And some of the newer switches have that by default, the encaps isl option is no longer available... and of course the command won't necessarily show up in the show run. Always better to type that in and get the error message than assume it is there and find out it's actually still set for ISL.
salad wrote: Older switches like Cisco 2924s always have VLAN1 and 1000-1005 enabled.
The full range of Catalyst 2900XL and 3500XL platforms exhibited this behavior, as well as some of the older CatOS revs of firmware on Cat5000/5500, and early model Cat4000 platforms too.
ccie4526 wrote: Always better to type that in and get the error message than assume it is there and find out it's actually still set for ISL.
Yes indeed. "It's blinking green/orange" "What the hell is that?" "Well spanning tree looks fine on this end..." Good times! Better times when one of the parties is partially colorblind
ccie4526 wrote: as well as some of the older CatOS revs of firmware on Cat5000/5500, and early model Cat4000 platforms too.
Sssshhh... we don't talk about CatOS around here :) (Disclaimer: I have a 5500 in my basement)
As a side note I find it somewhat irritating that the latest release for the 5500, which occurred eons ago, let you drop those archaic VLANs, but the 2900XL and 3500XL, like you mention, running IOS ver from just two years ago still force it.
Yes, the BH units will transparently pass 802.1q tags, I run trunk links between switches across BH units.
salad wrote:
Sssshhh... we don't talk about CatOS around here :) (Disclaimer: I have a 5500 in my basement)
I won't tell you the core switch for our ISP is a Cat5500 with RSM, and has been running for the last 8 years.... :)
8 years with an RSM? Very nice! There was a thread on cisco-nsp with a bunch of 5500 uptimes… you know there’s a software update, right? 
We’ve got a 5500 (not for long now that we got some more linecards for the 6509 next to it) on SUP-IIIs at 1346 days.