v1.5.6 Bug Reports and Comments

[rbaxter]

OS Version: 1.5.5 -> Unknown
pulled from SNMP

[Stephen]

Hey Stephen,

I had this issue pop up again from here. viewtopic.php?f=17&t=5816&start=90#p32887

This time it was facing a Cisco 3560-X. The Cisco device was acting like a router, no other connections go through it. I had access to the Cisco via a console cable at the time, it did not register any spanning-tree loops or issues. No VLANs were blocked for violations.

The tower feeding port 1 just came back from having the power out.

Sep 22 18:11:37 STP: MSTI0: New root on port 1, root path cost is 80000, root bridge id is 31488.3C-28-6D-5A-A7-83
Sep 22 18:11:37 STP: msti 0 set port 12 to discarding
Sep 22 18:11:39 STP: msti 0 set port 12 to learning
Sep 22 18:11:42 STP: msti 0 set port 12 to discarding
Sep 22 18:11:44 STP: msti 0 set port 12 to learning
Sep 22 18:11:44 STP: msti 0 set port 12 to discarding
Sep 22 18:11:53 STP: msti 0 set port 12 to learning
Sep 22 18:11:56 STP: msti 0 set port 12 to forwarding
<cut>
<this is me flapping the port, no change>
Sep 22 18:24:41 Port: link state changed to 'down' on port 12
Sep 22 18:27:49 Port: link state changed to 'up' (1G) on port 12
Sep 22 18:27:49 STP: msti 0 set port 12 to discarding
Sep 22 18:27:52 STP: msti 0 set port 12 to learning
Sep 22 18:27:52 STP: msti 0 set port 12 to forwarding
Sep 22 18:27:54 STP: msti 0 set port 12 to discarding
Sep 22 18:27:57 STP: msti 0 set port 12 to learning
Sep 22 18:27:58 STP: msti 0 set port 12 to discarding
Sep 22 18:28:03 STP: msti 0 set port 12 to learning
Sep 22 18:28:04 STP: msti 0 set port 12 to discarding
Sep 22 18:28:07 STP: msti 0 set port 12 to learning
Sep 22 18:28:08 STP: msti 0 set port 12 to discarding
Sep 22 18:28:49 STP: msti 0 set port 12 to learning
Sep 22 18:28:50 STP: msti 0 set port 12 to discarding
Sep 22 18:28:55 STP: msti 0 set port 12 to learning
Sep 22 18:28:58 STP: msti 0 set port 12 to discarding
Sep 22 18:29:18 STP: msti 0 set port 12 to learning
Sep 22 18:29:18 STP: msti 0 set port 12 to discarding
Sep 22 18:29:54 STP: msti 0 set port 12 to learning
Sep 22 18:29:57 STP: msti 0 set port 12 to forwarding
Sep 22 18:29:58 STP: msti 0 set port 12 to discarding
Sep 22 18:30:00 STP: msti 0 set port 12 to learning
Sep 22 18:30:00 STP: msti 0 set port 12 to discarding
Sep 22 18:30:15 STP: msti 0 set port 12 to learning
Sep 22 18:30:16 STP: msti 0 set port 12 to discarding
Sep 22 18:30:45 STP: msti 0 set port 12 to learning
Sep 22 18:30:46 STP: msti 0 set port 12 to discarding

<snip>


At this point I got into the Netonix and turned off spanning tree. Things started to pass traffic again. Things were also fine after re-enabling it. I've only seen this so far happening on 1.5.5 and 1.5.6.

Hey mayheart, when looking at the logs, is there any evidence that vtss_appl was crashing? Obviously I don't see it here but if you still have those logs in the GUI, change the selection from "Switch" to "All" to see it.
So far, I am unable to replicate the behavior, what settings were set on the cisco port? Anything special?

[Stephen]

OS Version: 1.5.5 -> Unknown
pulled from SNMP

Hello rbaxter, try doing an snmp walk first and then see if it still read's that way.

[Ludvik]

This is long-time error :-) Many versions ago.

snmpwalk .1.3.6.1.4.1.46242 helps. Maybe snmpget .1.3.6.1.2.1.105.1.3.1.1.4.8
and after this repeat get .1.3.6.1.4.1.46242.1.0 (firmware version).

OS Version: 1.5.5 -> Unknown
pulled from SNMP

[mayheart]

Nothing interesting with "all"

Only shows when I turned off spanning tree.

Code: Select all

Sep 22 18:32:49 UI: STP_Enable: changed from 'Enabled' to 'Disabled'
Sep 22 18:32:51 syslogd exiting
Sep 22 18:32:52 syslogd started: BusyBox v1.19.4
Sep 22 18:32:54 STP: msti 0 set port 12 to discarding


As for the Cisco router facing the equipment, nothing special on the port, just trunk mode with a bunch of allowed vlans.

Hey Stephen,

I had this issue pop up again from here. viewtopic.php?f=17&t=5816&start=90#p32887

This time it was facing a Cisco 3560-X. The Cisco device was acting like a router, no other connections go through it. I had access to the Cisco via a console cable at the time, it did not register any spanning-tree loops or issues. No VLANs were blocked for violations.

The tower feeding port 1 just came back from having the power out.

Sep 22 18:11:37 STP: MSTI0: New root on port 1, root path cost is 80000, root bridge id is 31488.3C-28-6D-5A-A7-83
Sep 22 18:11:37 STP: msti 0 set port 12 to discarding
Sep 22 18:11:39 STP: msti 0 set port 12 to learning
Sep 22 18:11:42 STP: msti 0 set port 12 to discarding
Sep 22 18:11:44 STP: msti 0 set port 12 to learning
Sep 22 18:11:44 STP: msti 0 set port 12 to discarding
Sep 22 18:11:53 STP: msti 0 set port 12 to learning
Sep 22 18:11:56 STP: msti 0 set port 12 to forwarding
<cut>
<this is me flapping the port, no change>
Sep 22 18:24:41 Port: link state changed to 'down' on port 12
Sep 22 18:27:49 Port: link state changed to 'up' (1G) on port 12
Sep 22 18:27:49 STP: msti 0 set port 12 to discarding
Sep 22 18:27:52 STP: msti 0 set port 12 to learning
Sep 22 18:27:52 STP: msti 0 set port 12 to forwarding
Sep 22 18:27:54 STP: msti 0 set port 12 to discarding
Sep 22 18:27:57 STP: msti 0 set port 12 to learning
Sep 22 18:27:58 STP: msti 0 set port 12 to discarding
Sep 22 18:28:03 STP: msti 0 set port 12 to learning
Sep 22 18:28:04 STP: msti 0 set port 12 to discarding
Sep 22 18:28:07 STP: msti 0 set port 12 to learning
Sep 22 18:28:08 STP: msti 0 set port 12 to discarding
Sep 22 18:28:49 STP: msti 0 set port 12 to learning
Sep 22 18:28:50 STP: msti 0 set port 12 to discarding
Sep 22 18:28:55 STP: msti 0 set port 12 to learning
Sep 22 18:28:58 STP: msti 0 set port 12 to discarding
Sep 22 18:29:18 STP: msti 0 set port 12 to learning
Sep 22 18:29:18 STP: msti 0 set port 12 to discarding
Sep 22 18:29:54 STP: msti 0 set port 12 to learning
Sep 22 18:29:57 STP: msti 0 set port 12 to forwarding
Sep 22 18:29:58 STP: msti 0 set port 12 to discarding
Sep 22 18:30:00 STP: msti 0 set port 12 to learning
Sep 22 18:30:00 STP: msti 0 set port 12 to discarding
Sep 22 18:30:15 STP: msti 0 set port 12 to learning
Sep 22 18:30:16 STP: msti 0 set port 12 to discarding
Sep 22 18:30:45 STP: msti 0 set port 12 to learning
Sep 22 18:30:46 STP: msti 0 set port 12 to discarding

<snip>


At this point I got into the Netonix and turned off spanning tree. Things started to pass traffic again. Things were also fine after re-enabling it. I've only seen this so far happening on 1.5.5 and 1.5.6.

Hey mayheart, when looking at the logs, is there any evidence that vtss_appl was crashing? Obviously I don't see it here but if you still have those logs in the GUI, change the selection from "Switch" to "All" to see it.
So far, I am unable to replicate the behavior, what settings were set on the cisco port? Anything special?

[Stephen]

As for the Cisco router facing the equipment, nothing special on the port, just trunk mode with a bunch of allowed vlans.

That might be the reason actually. STP doesn't speak the language of VLAN's, so if you are working with a trunked port with multiple different devices across VLAN's passing traffic, then the STP state engine might be interpreting the topology incorrectly as packets go back and forth from the switch to the router. MSTP theoretically should be able to handle this scenario, but that is a lot of added complexity that is really unnecessary if disabling STP is fine for this network segment.

Also if this is the case I would guess this happens randomly because of overlapping broadcast's on the individual VLAN's that are trunked, that would mean then that as the broadcast's from each VLAN travel to the switch port, the STP state engine would trigger if priorities/mac's were just right. I would imagine in that situation this would be the expected result.

Admittedly, this is an educated guess since I don't know much more about your network topology. If it's correct though at least it might help you and others plan around this scenario.

[petecarlson]

It looks like double tagged VLANs, The D 0x8100 option on the VLAN page, is broken in this release.

on 1.5.6 it isn't working - MAC table of D interface set to D 817 populates with MACs on VLAN 1. Looks like Q still works - I didn't test Q (0x88a8) fully as we run double 0x8100 tags back to our BNG.

rolling back to 1.5.2 works as expected.

[Stephen]

Hello petercarlson, it would help me to fix it if we can confirm what release it was broken in. I will test it myself as well, but was it also broken in 1.5.5?

[petecarlson]

Hello petecarlson, it would help me to fix it if we can confirm what release it was broken in. I will test it myself as well, but was it also broken in 1.5.5?

Not sure. I just rolled it back to the last tested production version we run (1.5.2) and verified it worked. I don't have anyone in the lab today to test it but it is pretty easy to test/duplicate. Connect a port to another switch and trunk a few VLANs into the D tagged port on the Netonix. If the MACs don't populate on the D port then you know you have the issue.

[Stephen]

No worries I will check it out. Just trying to get all the info I can. Thanks for letting us know.