WS-12-250-DC: QinQ crash, MAC Table refresh hang

[cegner]

Hi,

I was trying to configure QinQ on a WS-12-250-DC in order to have all untagged or tagged packets from Port 3 handed over to port 13 in a tagged Vlan.
As soon as I apply the changes the switch crashes and reverts to the old config.

Dec 31 20:40:10 UI: VLAN 2 PortSettings: changed from 'EEUEEEEEEEEEET' to 'EEQEEEEEEEEEET'
Dec 31 20:41:12 admin: Reverting to last known good configuration

Am I doing something wrong?

Also I noticed that refreshing the MAC Table hangs with a "Please wait" dialog beeing displayed. I have to reload the page in order to gain access again.


Best Regards
Christof

[sirhc]

The switch is not "crashing" the switch is doing exactly what it is supposed to do. Why would you consider it to be crashing?

On the Device/Configuration Tab there is an input field called "Revert Timer" and the default is 60 seconds. What this feature does is prevent you from making a mistake to a remote switch that causes you to lose control and have to go driving to recover your mistake.

When you make the change you are referring to the Web UI that you are using to configure the switch is losing access to the switch due to your VLAN changes and is unable to re-connect to the switch within 60 seconds so the switch is doing exactly what it should and revert back to the last configuration.

If you do not want this feature you can disable it by changing the value to "0" but obviously your changes are causing you to not be able to reach the switch so you will lose control.

Or you can increase the value to say 300 which is 5 minutes before it will revert.

[sirhc]

Also make sure you upgrade to v1.3.9

[cegner]

Thanks for your feedback. I already upgraded to 1.3.9.

On any other VLAN changes it takes 5-10 seconds to apply the config and I immediately can access the switch again.
When doing the mentioned QinQ change, I completely loose connectivity to the switch. I can't ping it any more, although the changes should not affect access to the management VLAN. That's why I think it's crashing.

My config is simple. I have two VLANs, the default management VLAN (1), und another one (252).
Vlan 1 is untagged on all ports exept port 3. Vlan 252 is untagged on port 3 and tagged on port 13. This works fine.
Then I change port 3 to "Q" mode and immediately loose access. Am I doing something wrong?

What about the MAC Table hang? Can you reproduce it?

[sirhc]

Please post screen grabs of the following Tabs before you make the change that causes you the issues:
VLAN Tab, STP Tab, and Device/Configuration Tab

Then post the VLAN Tab before your hit Save/Apply with the change you say causes you the issue.
I am assuming there is no other change being done except on the VLAN Tab

Then post up a screen grab of the Log after the Save/Apply fails and it reverts to the previous config

[cegner]

Here you go. This is the working config before the changes:
CLICK IMAGES BELOW TO VIEW FULL SIZE

And this is before saving changes:

And the log:

Code: Select all

Dec 31 20:29:29 UI: Configuration changed by 192.168.10.173
Dec 31 20:29:29 UI: VLAN 2 PortSettings: changed from 'EEUEEEEEEEEEET' to 'EEQEEEEEEEEEET'
Dec 31 20:30:38 admin: Reverting to last known good configuration


[sirhc]

NOTE: I edited your post above and changed it to uploaded images as the place you had the pics hosted was spamming me with add Tabs.
You can simply upload images to the forums by clicking "Upload attachments" below the box where you type your post.

Now explain to me what is plugged into port 3 and 14 and are they setup to deal with QinQ VLANs?

Port 3 is a MIMOSA B5 PTP link going where?
Port 14 is going where? (I assume a router)

Now explain to me what you want the Q on Port 3 to do here.

You understand that putting a Q on port 3 will do the following:
Packets leaving Port 3 will have their outer VLAN tag 252 stripped off leaving the inner VLAN tag(s) if any exist alone
Packets entering Port 3 will have an outer VLAN tag of 252 added thereby encapsulating any VLAN tags within the VLAN ID of 252

Port 14 will only accept packets with an outer VLAN tag 252 and simple Untagged packets which will be directed to the switch UI/CLI (VLAN ID 1)

If you are accessing the switch UI/CLI via the B5 connection on port 3 you would lose access to the switch unless you have the other devices setup to deal with QinQ.

Packets entering Port 14 can be either Tagged with the VLAN ID 252 or simple Un-Tagged packets which will go to the switch UI/CLI
Packets leaving Port 14 will either be Un-Tagged packets from the switch UI/CLI or Tagged QinQ VLAN packets from Port 3 with an outer VLAN Tag of 252

Whatever is connected to Port 14 (I assume a router) has to be able to deal with QinQ packets

I will admit that I do not use QinQ at my WISP and thus I am not as familiar with it's use as I should be but I "think" I am explaining this correctly?

[sirhc]

Here are some other people's posts on QinQ
viewtopic.php?f=17&t=1033&p=7749&hilit=QinQ#p7749
viewtopic.php?f=6&t=974&p=7511&hilit=QinQ#p7511

Maybe Mike99 can chime in here and give his opinion.

I did send a PM to Mike to review this if he has a spare moment.

[sirhc]

I am looking into MAC table but I am not seeing an issue here yet?

[mike99]

How do you access your switch for management ? I see only port 3 and 14 up, every other down. My guest guest that your accessing the switch on port 3 via a IP address you set on this VLAN and loose access when you change the vlan 252 from a C-VLAN to a S-VLAN. Try it connected to any other port like port 4, it should work. Else, config seem fine to me. MTU is not shown on screenshot but S-VLAN need a additionnal 4 bytes at the MTU for every S-VLAN.