Netonix Forums

Setting up a switch in my lab for general pre-production debugging.
v1.5.6 reset to factory defaults. (Tested and found same error on v1.5.4)
Management PC host attached to port4, IP: 192.168.1.133/24 & 192.168.123.133/25
Test host attached to port1, IP: 192.168.1.1/24 ...pings fine from PC & WS Tools/Ping
Set WS IP: 192.168.123.135/25
Set WS management VLAN from VLAN1 to VLAN123; port4: U; ports 13 & 14: T; others: E

All is fine ...

Add VLAN reusing VLAN1. Add test VLAN1 IP: 192.168.1.21/24; port4: E; ports 13 & 14: T; all others U

Occasionally on the Apply, I catch a glimpse of an info box something like "error during apply" ?

Now WS Tools/Ping is able to ping its 192.168.1.21, but is no longer able to reach 192.168.1.1 :(

If I move the PC from port4 to any other U port on the VLAN1, it can ping 192.168.1.1.

Change the second VLAN from VLAN1 to VLAN11, Apply
Now the WS Tools/Ping reaches 192.168.1.1 as well as the PC (when plugged into one of the VLAN11 U ports)

But if I try to change it back to VLAN1, same failure recurs. :(

In the title, I say "perhaps others" because I seem to have seen something like this on a remote switch which had a reconfigured management VLAN (like 123 in this example) and then tried to later use (eg 123) in later VLANs other than the management one.

It acts as though sometimes a filter rule is left over after the Apply?

It's really a time waster when we expect ping to work consistently and therefore start checking everything else in the network first.

I saved the config and can send it in a PM if you wish.

Hey JustJoe, yes please PM me the config.

Also the log from the test would help.

No problem, PM sent yesterday evening with both. (Still shows in my outbox)

Got it, thanks!

Hey JustJoe, just got around to looking into this, here's what I've found.

JustJoe wrote:It acts as though sometimes a filter rule is left over after the Apply?

I don't believe you need to worry about this as a leftover filter rule.
After successfully recreating the experiment,
I changed VLAN123-> VLAN124 & VLAN11->VLAN123 to check and see if any issue's would occur on the new VLAN123 since it was previously the management VLAN,
I was able to reach 192.168.1.1 like one would expect. If a rule was carried over from the former Management VLAN address then I should not have been able to ping 1.1

As far as what is happening on VLAN1, since VLAN1 is the default, internally we do a mapping (actually our manufacturer does this, we just activate it) for the switch so that you can give it a new number for the management VLAN, however it is actually hardcoded under the hood to use VLAN 1 still. This is similar to how cisco use's the native vlan 1 which is unable to be modified or deleted, our's is similar but a bit simpler than that. It is in essence always present on the internals of the management VLAN.

This is most likely the reason you are seeing this problem.

What this does expose though is that there is a bug in the code for the reason that VLAN 1 is allowed to be used outside of the managemant VLAN. The next update will have this fixed.

JustJoe wrote:In the title, I say "perhaps others" because I seem to have seen something like this on a remote switch which had a reconfigured management VLAN (like 123 in this example) and then tried to later use (eg 123) in later VLANs other than the management one.

Although I saw no evidence of this, a variation of what you are thinking may be possible. My guess right now would be that if that can occur, it would probably have to do with the firewall rules being reloaded. Everytime VLANs are changed, they have to be reloaded into the firewall along with several other functions (there is no way around this unfortunately, because the firewall is handled on the CPU and the VLANS on the ASIC separately). This reloading process does take time and while it's happening it could potentially result in ping loss. It should not however, result in permanent connectivity loss unless of course something was accidentally configured that way.

If you do manage to find another scenario where you can show this to be true. Please post it here and I will lab it and look for a solution.
Or, if I misunderstood something, let me know.

I came back to this thread to review some info I was going to pass on to a co-worker. I realized that the acknowledgement and thanks that I had posted a few weeks ago were missing. I seem to recall I was having some problems logging into this forum server and that may have dropped the post during a maintenance window.

So it is very possible that the other VLAN IDs being affected when reassigning the management VLAN as I was remembering were a timing issue. That case was a remote location so I only had one link as access and had no way of testing locally from the other VLANs like in the lab.

"native VLAN" on Cisco was also a bit of a strange duck. I can't swear to it on Cisco switches, haven't used them for awhile, but at least Cisco router VLAN configs allow reassigning the native VLAN ID # on the encapsulation command.

Also, it's really unfortunate this is a limitation that makes VLAN 1 be unique. I was doing Wireshark captures while testing this. Turns out all other traffic follows and is correctly delivered on the reassigned VLAN 1. The only thing missing is that ARP Replies are dropped/ignored. The WS even correctly issues and transmits the ARP Request after a ping is originated from it to the management PC host. I could see the host would correctly ARP Reply, but the WS didn't react to it.

If you wonder why on earth I would have tried to reassign a somewhat obvious malicious attack target like VLAN1, our intention was to let spare WSs go out with a mostly default config except for one port marked T. Then that trunk could be the complete path from a management PC which temporarily enabled VLAN1 at the NOC. There are of course a lot of other ways to accomplish the same thing, just seemed easy at the time.