Setting Management Vlan?

[mhoppes]

For example, if my management VLAN is 50, is there anyway to access the switch if I put it into this network? Or is the only way to access the switch if your management VLAN is 1?

[Rory]

Typically the management vlan is the untagged vlan. If the vlan is untagged, it doesn't really matter if the number that the switch and the connected device use to identify the vlan, it will work. Its not technically 'right' but it will work. I've done this to transition between different management vlan ID's during a configuration migration.

If you are tagging the management vlan, that is where the current setup fails at the moment. The only way to really have that work is to change your management vlan on the router / other switch / whatever is dot1q trunking to be vlan 1. Really the best option in my opinion is to untag your management vlan going to / from the Wispswitch until such time as we have the firmware updated to support changing the management vlan ID. In this manner you can keep your current vlan id structure until such time as this change is in, and it is a relatively minor change to make once the Wispswitch supports your config.

As Chris has stated, we are planning on implementing that feature soon, by the end of the year I believe. Please refer to Chris's posts though, he has the most up to date information on the planning and scheduling.

[mhoppes]

Thanks Rory. That's exactly how we are setup. VLAN 50 (management) is the untagged VLAN on all of our ports, while traffic flows across tagged VLANs on the ports. The only concern I've got (and I guess we can see what happens when we try) is if the Cisco switches will complain about a VLAN port mismatch and fail to come up?

I've seen that happen if one switch has the management set to 50 and the other set to 1. The Cisco complains and just won't bring the trunk port up. Since the Netonix doesn't technically do a "trunk port" the Native VLAN mismatch probably won't come into play?

[Rory]

Normally that type of error is caused by some informational protocol (DTP, VTP, CDP,LLDP) that is advertising the vlan ID's across devices. This is a common error when you are going between two devices that have such protocols enabled by default. I've seen it personally on Cisco to Cisco devices.

We actually had a customer who had CDP enabled on their wan interface (an 800 series router), which happened to be on a layer two port that was assigned VLAN ID of 2. When we made some changes to our network we missed the 'no cdp enable' on the new ports (in our router at the tower), which were also layer 2 ports, with a different VLAN ID. Since the VLAN ID's didn't match the customer's internet access would not come up until CDP was disabled on the port on my device. Once CDP was disabled, dot1q was blithely unaware of the VLAN ID mismatch, as the ports were all untagged. So make sure to disable such things on at least the port that connects to the Wispswitch, and you will be fine. Of course DTP and VTP may be used elsewhere on your network, so be aware of what you are disabling and where.

Also, I want to clarify: The Wispswitch does indeed support the Cisco specific dot1q 'trunk mode'. We spent quite a few long nights getting that functionality to work, and I have all of my installed Wispswitches establishing dot1q trunks to Cisco routers, so I have a reasonable expectation that will work. (We've tested it with layer 2 and layer 3 ports on the Cisco devices we have in our shop.) I have also personally mismatched the untagged 'native' vlans on a dot1q trunk with success, both in regards to Cisco gear and other manufacturers.

So please, lab things up before implementing as there may be some hurdles, but this should work when properly implemented. Do not hesitate to contact me with any questions you may have.

[mhoppes]

Rory,
Where do you turn dot1q trunk on for a port? I don't see anyway to do that short of setting T on every VLAN on that port.

[mhoppes]

Confirming that the switches jump onto VLAN 1 by default, so if management is VLAN 1 everything works right.

[Rory]

Rory,
Where do you turn dot1q trunk on for a port? I don't see anyway to do that short of setting T on every VLAN on that port.

You don't, it's automatic.

[mhoppes]

So you're saying if I just plug the two switches together they will trunk whatever vlans I pump in one side and try to pull out the other?

Or do I have to enable something?

Trunking by default is frightening!

[sirhc]

So you're saying if I just plug the two switches together they will trunk whatever vlans I pump in one side and try to pull out the other?

Or do I have to enable something?

Trunking by default is frightening!

Matt this is one of those situations where your knowledge of how VLANs work is a little weak.

PM Rory and ask him to give you a call tomorrow.

Don't feel bad VLANs still drive me a little crazy which is why I do not want to call you and answer this as I know enough to get myself in trouble let alone try and instruct others which is why I pay Rory.

[mhoppes]

Chris,
I've asked Rory to call me and we're going to talk tomorrow... but I'm going to respectfully disagree.

Trunking is a special function that can be assigned to a port, making that port capable of carrying traffic for ANY AND ALL of the VLANs accessible by a particular switch. Such a port is called a trunk port, in contrast to an access port, which carries traffic only to and from the specific VLAN assigned to it.

On the Netonix switches and the original generation of ToughSwitch firmware there were only three options: Tag, Untag, and Exclude. To "simulate" a "trunk port" you had to hit T on every VLAN you wanted to send across your backhaul. Ubiquiti then added the "Trunk" option to the ToughSwitch firmware in 1.3 which allows you to select a port as a "Trunk Port" which effectively accepts all traffic VLANs coming into the switch on that port. Cisco switches operate exactly the same way. We set up our backhaul NNI ports as trunk ports and setup the UNI ports as either Tagged or Untagged ports depending on where they are going.

I'll update the thread after talking with Rory tomorrow.