VLAN on Canopy for Dummies

(I am moving my post to the general discussion, as advised)

I have searched the forums, and found links to guides that no longer exist. I have read the manual pp 169-170, pp 249-252, and pp 282-285. But I am still confused. The VLAN concept is familiar to me: append an ID and devices with the same ID are in the same VLAN. But how does Canopy really work?


  • I do not understand the Management ID. What is this, and why do I get locked out locally if this is changed?

  • Can the front-end of the SM be on a separate VLAN from the backend (wireless port vs ethernet)?

  • I want to be able to get to the user interface locally (a tech support person) and on the admin network. But the tech does not want to carry around a switch capable of VLAN. How do I get around this?

  • I want SMs available on the network by admins. This seems possible with a VLAN.

  • I want the SMs isolated. While this could be done with VLAN, it sounds like it is easier to use SM isolation on the AP. However, one or two SMs should be able to to get into everyone’s SMs (tech support).

  • Almost all the APs are connected via CMMs, but one links to an SM with a sync cable. How would this work?

  • I have Redline, Dragonwave, Memorylink, Last Mile Gear, (and something else) products used for backhauls that I want on the VLAN. I do not see VLAN configuration for each of these devices. What are my options (throw them on a switch, can the CMM handle it, etc)?


Thank you for assistance. A link to a good guide would be very helpful. I realize this is all probably basic, but I am not getting how to properly create VLANs that accommodate the ethernet vs wireless ports on these devices.

The Canopy manual assumes a certain level of working knowledge with VLANs. To bring you up to speed, try these:

- http://www.firewall.cx/networking-topic … works.html
- http://www.techhead.co.uk/introduction-to-cisco-vlans

eanderson wrote:
I do not understand the Management ID. What is this, and why do I get locked out locally if this is changed?

This is short for the Management VLAN ID. When an SM is in Bridged mode, the management interface will only respond on this VLAN. To access it you must send frames tagged with the appropriate VLAN on either the wired or wireless interfaces.

eanderson wrote:
Can the front-end of the SM be on a separate VLAN from the backend (wireless port vs ethernet)?

Sort of, depending on your scenario. The primary use of VLANs on Canopy is to separate management traffic from customer traffic. This assumes that your management access is somewhere from your office. This being so, the wireless interface is a trunk that carries multiple VLANs, and generally you set one of the VLANs to go to management, and the other VLAN to go to the ethernet port. The other mode of operation is in NAT mode. In software versions 10.something and higher, you can have the external NAT on a separate VLAN from the management on the wireless side. There is no VLAN on the wired port since the Layer 2 broadcast domain gets terminated locally.

eanderson wrote:
I want to be able to get to the user interface locally (a tech support person) and on the admin network. But the tech does not want to carry around a switch capable of VLAN. How do I get around this?

The most common answer among WISPs is to run NAT mode. Otherwise, exactly how you do this will depend on whether or not you use Prizm/BAM to push VLAN configuration. In our network, with Prizm, the VLAN settings are only active on an SM if it’s linked to an AP. Repairs where the SM doesn’t link are pretty straightforward. For other times we give our techs a VPN to connect back to the office and access the SM like that. If you were to manually configure VLANs in every SM, the tech would need to carry a VLAN-capable switch, have a NIC that supports VLAN tagging (some Broadcom, nVidia, and definitely Intel Pro NICs), or use the factory reset plug.

eanderson wrote:
I want SMs available on the network by admins. This seems possible with a VLAN.

VLANs are not required for office access and are not always the answer to everything. What is the problem you are trying to solve?

eanderson wrote:
I want the SMs isolated. While this could be done with VLAN, it sounds like it is easier to use SM isolation on the AP. However, one or two SMs should be able to to get into everyone’s SMs (tech support).

SM isolation is a very important feature on Canopy APs to keep broadcast storms down and security between customers, especially in bridged mode. VLANs are not required to isolate customers from each other, just to keep customers away from your management traffic.

What do you mean by “one or two SMs should be able to get into everyone’s SMs”? Are your tech support reps out in the field? This not compatible with VLANs or SM isolation.

eanderson wrote:
Almost all the APs are connected via CMMs, but one links to an SM with a sync cable. How would this work?

For the SM “ghetto BH” you will need to let it trunk through all VLANs. The AP that it’s connected to upstream will need to have the VLAN for the child AP allowed through it.

eanderson wrote:
I have Redline, Dragonwave, Memorylink, Last Mile Gear, (and something else) products used for backhauls that I want on the VLAN. I do not see VLAN configuration for each of these devices. What are my options (throw them on a switch, can the CMM handle it, etc)?

Backhaul equipment is usually transparent to any VLANs as they just punt packets back and forth and do not need to make switching or filtering decisions. The only setting you will see is a Management VLAN ID. If you don’t, you will need to configure the switch ports they connect to to use a “primary VLAN” or “native VLAN” of whatever you’d like the management for this gear to be on.


My best advice is to get your hands on a couple of VLAN-capable switches and just start playing around. This is really the best way to get familiar with the practical sides of VLANs and their pros and cons. If you start into implementing VLANs on a wireless network without a solid understanding and knowing what to expect, you can easily cause a huge outage that can result in truck rolls and having to reset equipment to defaults.

First, thank you for the reply.

salad wrote:
[quote=“eanderson”:vblqnua2]Can the front-end of the SM be on a separate VLAN from the backend (wireless port vs ethernet)?

Sort of, depending on your scenario. The primary use of VLANs on Canopy is to separate management traffic from customer traffic. This assumes that your management access is somewhere from your office. This being so, the wireless interface is a trunk that carries multiple VLANs, and generally you set one of the VLANs to go to management, and the other VLAN to go to the ethernet port. The other mode of operation is in NAT mode. In software versions 10.something and higher, you can have the external NAT on a separate VLAN from the management on the wireless side. There is no VLAN on the wired port since the Layer 2 broadcast domain gets terminated locally.
[/quote:vblqnua2]
I guess further explanation of the current setup would help. We have been running NAT for most clients. But some clients with special needs are setup in Bridge mode. We use SM isolation (Block SM Packets from being forwarded) to reduce congestion/increase security. Furthermore, a fair amount of network administration is done from an SM on the network, and not from the Network Operations Center. This SM is able to administer most of the network easily, except for the SMs that are connected to the same AP. These must be administered through the AP, and some administration requires jumping to a different AP to accomplish the task.

So, from the description, you can see that this setup works, but has some holes. We are attempting to plug those holes, and were thinking that implementing VLANs could accomplish this, but have not been able to get our heads around EXACTLY how to do this, so that we do not lock out the entire system when implementing. Currently, we are testing with a (100% test) AP and SM that can be dropped onto the network easily.

So, in 95% of our use cases, we would want one VLAN for Management, and one for the ethernet. It is the other 5% that is troubling.
salad wrote:
[quote=“eanderson”:vblqnua2]I want to be able to get to the user interface locally (a tech support person) and on the admin network. But the tech does not want to carry around a switch capable of VLAN. How do I get around this?

The most common answer among WISPs is to run NAT mode. Otherwise, exactly how you do this will depend on whether or not you use Prizm/BAM to push VLAN configuration. In our network, with Prizm, the VLAN settings are only active on an SM if it’s linked to an AP. Repairs where the SM doesn’t link are pretty straightforward. For other times we give our techs a VPN to connect back to the office and access the SM like that. If you were to manually configure VLANs in every SM, the tech would need to carry a VLAN-capable switch, have a NIC that supports VLAN tagging (some Broadcom, nVidia, and definitely Intel Pro NICs), or use the factory reset plug. [/quote:vblqnua2]
Yes, this is part of the concern. We do not have Prizm, so roll out is a major concern.

salad wrote:

[quote=“eanderson”:vblqnua2]Almost all the APs are connected via CMMs, but one links to an SM with a sync cable. How would this work?

For the SM “ghetto BH” you will need to let it trunk through all VLANs. The AP that it’s connected to upstream will need to have the VLAN for the child AP allowed through it.
[/quote:vblqnua2]
Makes perfect sense.

salad wrote:

My best advice is to get your hands on a couple of VLAN-capable switches and just start playing around. This is really the best way to get familiar with the practical sides of VLANs and their pros and cons. If you start into implementing VLANs on a wireless network without a solid understanding and knowing what to expect, you can easily cause a huge outage that can result in truck rolls and having to reset equipment to defaults.

Thanks, that is exactly what is going on here. We cannot roll this out across the entire network without a great deal of confidence in how it will play out.

eanderson wrote:
I guess further explanation of the current setup would help. We have been running NAT for most clients. But some clients with special needs are setup in Bridge mode. We use SM isolation (Block SM Packets from being forwarded) to reduce congestion/increase security. Furthermore, a fair amount of network administration is done from an SM on the network, and not from the Network Operations Center. This SM is able to administer most of the network easily, except for the SMs that are connected to the same AP. These must be administered through the AP, and some administration requires jumping to a different AP to accomplish the task.

So, from the description, you can see that this setup works, but has some holes. We are attempting to plug those holes, and were thinking that implementing VLANs could accomplish this, but have not been able to get our heads around EXACTLY how to do this, so that we do not lock out the entire system when implementing. Currently, we are testing with a (100% test) AP and SM that can be dropped onto the network easily.

So, in 95% of our use cases, we would want one VLAN for Management, and one for the ethernet. It is the other 5% that is troubling.


Alright, so it seems you're looking to accomplish a few things:

  • Secure management from remote workers

  • Segregate management

  • Segregate bridged from NAT customers, and possibly bridged from bridged customers.


So first off the SM that techs do troubleshooting from: Since you already use SM Isolation you know the drawbacks... but, SM Isolation is Layer 2 only. This means that traffic that gets hairpinned at some place further upstream is allowed. You have a couple of ways to tackle this:

  • Remote user on SM connects to your core via VPN. SM is configured just like any other

  • SM is set up differently with a VLAN that terminates into the same routing space as your management networks, instead of regular subscriber internet access.


Segregating management on most Canopy gear isn't that hard if you go from the furthest point and change things over going inwards. Planned properly you can recover from most incidents as long as you can frame tagging on or off. Canopy APs aren't really an issue as they have the wonderful internal proxy. CMMs and almost all backhaul radios will pass through VLANs with no problem. So rollout of a management isn't that tricky, just labor intensive.

For your bridged customers you have a few options. An ISP we recently acquired ran their NAT SMs out of the same layer 2 space (and IP pool) as bridged customers. The only difference, really, was whether or not the SM was in bridged or NAT mode... To keep this cleaner you might use a separate VLAN to distinguish between NATted subscribers and bridged subscribers. You could also go so far as to use unique VLANs per bridged subscriber and assign them their own blocks like a /29 instead of having them pull from a pool or use static assignments.