Native VLAN

[nelson05]

Tried to replace four ToughSwitches on our busiest tower with a WS-24-400A and unfortunately ran into some trouble on the VLAN front. For whatever reason things seemed to work OK when using the ToughSwitch in a configuration where port 1 is connected to a device with the following configuration:

VLAN 1: Tagged
VLAN 20: Tagged
VLAN 120: Tagged
VLAN 166: Tagged
VLAN 190: Tagged

With VLAN 1 set as the Native VLAN on a trunked port.

When configuring the WISP Switch, I noticed that it didn't seem possible to configure a port for both a tagged and untagged VLAN on the same port. In other words, it doesn't appear possible to have a native VLAN that is the same as what is already set as a tagged VLAN when a port is set as a trunk port. We hoped it would work configuring the port as VLAN 1 tagged, but no go. Tried VLAN 1 untagged and had the same result- no go.

In the end, this forced us to use the ToughSwitch as an intermediary device so that one port of the ToughSwitch was configured as stated above and connected to the uplink device the other port fed the WISP Switch with the same configuration stated above except that VLAN 1 is untagged on the port connecting to the Netonix. Once I did this, everything came up and worked on VLAN 1. Prior to this, only the other VLANs passed traffic.

Any suggestions? We would of course like to eliminate the ToughSwitch ASAP.

Also, I should note this switch has the latest firmwareL 1.0.2 (no RCs, the final version)

Thanks!

[mhoppes]

I want to make sure I understand what you are saying.... you're saying you want a port(s) to have VLAN 1 as both tagged and untagged? If so, I don't understand what you're trying to accomplish.

Normally you either tag and equipment handles taking care of the untagging or tagging, or you untag your native VLAN and the equipment needing to ride that VLAN just sends it on the native VLAN untagged.

[Rory]

Tried to replace four ToughSwitches on our busiest tower with a WS-24-400A and unfortunately ran into some trouble on the VLAN front. For whatever reason things seemed to work OK when using the ToughSwitch in a configuration where port 1 is connected to a device with the following configuration:

VLAN 1: Tagged
VLAN 20: Tagged
VLAN 120: Tagged
VLAN 166: Tagged
VLAN 190: Tagged

With VLAN 1 set as the Native VLAN on a trunked port.

When configuring the WISP Switch, I noticed that it didn't seem possible to configure a port for both a tagged and untagged VLAN on the same port. In other words, it doesn't appear possible to have a native VLAN that is the same as what is already set as a tagged VLAN when a port is set as a trunk port. We hoped it would work configuring the port as VLAN 1 tagged, but no go. Tried VLAN 1 untagged and had the same result- no go.

In the end, this forced us to use the ToughSwitch as an intermediary device so that one port of the ToughSwitch was configured as stated above and connected to the uplink device the other port fed the WISP Switch with the same configuration stated above except that VLAN 1 is untagged on the port connecting to the Netonix. Once I did this, everything came up and worked on VLAN 1. Prior to this, only the other VLANs passed traffic.

Any suggestions? We would of course like to eliminate the ToughSwitch ASAP.

Also, I should note this switch has the latest firmwareL 1.0.2 (no RCs, the final version)

Thanks!

Apologies for the questions, I think that I understand what you are trying to accomplish but your statements are slightly inconsistent. I just want to clarify so I can assist, I'm not really trying to argue semantics =D

You say: "it doesn't appear possible to have a native VLAN that is the same as what is already set as a tagged VLAN when a port is set as a trunk port" I'm pretty sure that's not what you mean. The native vlan is another word for the untagged vlan on a trunk port. You can't have a single vlan set as tagged and untagged on the same port, I've never seen a switch or other device that would allow that mode of operation. Some of the gear I am familiar with allows you to tag the default / native vlan, but not on the same port it is already untagged on.

If I am understanding what you are trying to do, it is tag the native vlan on your trunk port, probably for security reasons. If anybody has not read up on this, check out http://www.networkworld.com/article/2234512/cisco-subnet/cisco-subnet-tagging-the-native-vlan.html .

This should be possible, I have seen folks run that way, and I have tested out this functionality. Could you post some screen shots of the vlan config in the wisp switch and whatever pertinent config you have in your other device? Please do not include any ip addresses or other information that could be used to identify you or your network. In this manner I can try to duplicate your issue. If there is a bug in the switch, I would be glad to pass the information along to the programmer responsible for fixing it, but I need to be able to duplicate the issue to guarantee a fix. If the problem is one of configuration, then we can hopefully get you in business even faster.

I'm headed out for a bit after posting this, but I should be back in the office early this afternoon. (EST)

Thanks - Rory

[nelson05]

It is embarrassing to confirm, but I'm not sure I actually understand what I am trying to accomplish either except that it worked in the case of a ToughSwitch, but not with the WISP Switch.

I actually sent you a PM on it as I know at what point you were a user and potentially still are of the product we are connecting to, but essentially we are connecting to a Performant/Accedian Mind/Controller unit that is carrying VLAN tagged traffic across two different radio links. As I stated in my previous post, this seemed to work fine with the ToughSwitch connecting to the Accedian unit with the VLANs tagged as described above. It only appeared to be an issue for VLAN 1 on the WISP switch in that the other VLANs seemed to pass traffic between the WISP Switch and the Performant Gear yet VLAN 1 would not go between the two. After putting the ToughSwitch back in place and feeding the WISP switch through the ToughSwitch as described above, everything worked.

I understand your points regarding VLAN traffic on a port as being tagged or untagged (not both) for a particular VLAN. Just trying to understand why it works with the ToughSwitch but will not with the WISP Switch and, of course, want to ultimately eliminate the ToughSwitch. In terms of using VLAN 1, I also understand this is often for Management Access but the legacy of how things have been configured on our network, it is the primary VLAN our customers reside. I would like to avoid having to move off of this VLAN to avoid reconfiguring equipment down the line.

Hopefully that makes some sense and someone might have an idea on how to correct things?

Thanks!

[nelson05]

Sorry Rory... just saw your reply after posting my follow-up.

Thanks for the questions and am sorry my original description didn't help much. Hopefully the follow-up makes things a little clearer. In a way, I feel like we are working with a black box in some ways when speaking about the Performant gear I am attaching the ToughSwitch to. With us using VLAN 1 as regular customer traffic rather than as a management VLAN, this may make things a little more complicated.

As I shared above, I currently have one of the old ToughSwitches in place between the Performant device and the WISP Switch. Port 8 on the ToughSwitch is connected to the Performant device and Port1 of the ToughSwitch is connected to Port 1 of the WISP Switch. This had to be done to allow the WISP Switch to pass traffic on VLAN 1 to the Performant gear, which is connected to our backhaul radios. On the other side of the backhaul radios, there is another Performant device that connects to an EdgeRouter where VLAN 1 is untagged and the other VLANs are tagged. This would make me think that the WISP Switch could be configured the same, but it does not work and only seems to work on the ToughSwitch with the config as described.

Here are the relevant screenshots:

Screenshot 2014-11-10 12.13.07 Netonix.png (163.79 KiB) Viewed 9134 times

Screenshot 2014-11-10 12.14.23 ToughSwitch.png (372.96 KiB) Viewed 9134 times

Screenshot 2014-11-10 12.22.47 Performant.png (75.03 KiB) Viewed 9134 times

[Rory]

Have you tried setting the wispswitch up more like the toughswitch? With Vlan 1 set to T on the trunk port (port 1) instead of U? Apologies, I just want to confirm that you have tried that and it did not work.

I will be able to verify this configuration a little later tonight / tomorrow AM, so if there is something weird on my end I should hopefully be able to find it. I know I have tested similar and it worked at the time, but sometimes there are regressions on newer code, so there is always the possibility that it may not work now.

I noticed that your performant gear says "VLAN ID:1 ID:8" Do you know what that means? I tried googling their page, but all I get is a 'page cannot be displayed' for their store when I attempt to access any links to their site at the moment.

I will check back in as soon as I have more information.

[nelson05]

Yes, I tried the WISP Switch with VLAN 1 set to both T and U when connecting to the Performant device and neither worked.

The ID:8 is something internal to the Performant though I am sure Matt and Josh would be better suited to answer that. Some kind of mapping between C-Tags and S-Tags. I think I had it explained once to me, but haven't had to dive back in for a while. Its probably in my notes somewhere. My understanding is once the VLANs are handed off from the Performant gear, they act as any other device and it is just the VLAN ID that gets passed... in this case- 1.

[mhoppes]

Sorry, been working night shift here upgrading our network. I'll try to get to you today... but don't know for sure if I'll be able to.

[nelson05]

Much appreciated when you have the time. Hoping to get this resolved as this is holding up the deployment of my other WISP Switches.

Thanks again.

[josh]

ID # is just an internal "row" number the vlan is mapped to, that's it. It has nothing to do with VLAN ID. Basically saying "this is the 8th vlan you've made on this device"