v1.4.7rcX Bug Reports and Comments

[IntL-Daniel]

Is there a way to improve pause frame storm detection to be able to detect pause frame storm end and re-enable the Flow Control on the port?

[sirhc]

Is there a way to improve pause frame storm detection to be able to detect pause frame storm end and re-enable the Flow Control on the port?

We thought about this but decided not because a loop/thrashing could occur.

[IntL-Daniel]

Hm..so maybe just a selectable option with posibility to set some variables for storm end detection?

[sirhc]

Hm..so maybe just a selectable option with posibility to set some variables for storm end detection?

How can we tell it is over as once we disable FC there are no more Pause Frames to count.

I think the fact that we simply disable Flow Control on the offending port and not disable the port entirely which is what every other manufacturer's solution to a Pause Frame Storm detection was that I could find is the best yet safest solution we could come up with.

The problem is we do not want to make an assumption as to what is going on just restore network traffic, notify the network engineer, and allow him or her to decide what to do next.

The real solution is for the equipment maker that is causing the storm to fix their firmware so as not to create them in the first place.

[IntL-Daniel]

I understand what you mean. But in our case the pause frame storm is detected when the summer rain storm breaks the AF24 link..then the FC is automatically disabled. When the AF24 link is re-established it works even with FC disabled but 100Mbit devices (like RocketM5) are limited to approx 30 Mbit traffic without FC enabled. So the switch waits to be maintained to re-enable the FC later after the rainstorm. If there is no way how to detect pause frame storm end, then I think about some time limit option (1 hour?) when the switch could automatically re-enable the FC...if the pause frame storm will persist it could automatically disable the FC again.

And I know..it is a major Ubiquity product issue but I do not believe they will ever fix it :-(

[sirhc]

NOTE: MSTP is still being tested so use MSTP at your own risk.

FIXED/CHANGED
- Fixed temp sensors showing crazy values in very cold environments - RC3
- Fixed getting "unexpected link change" messages due to port bounce, watchdogs, etc - RC3
- Fixed port bounce being 1 hour off after daylight savings time changes - RC3
- Fixed VLAN tab layout getting messed up when you delete a VLAN - RC3
- Fixed mac table refresh button causing entire page to reload - RC3
- Fixed problem with QinQ when using untagged VLANs - RC3
- Fixed fan control handling negative temperatures - RC4
- Fixed input voltage graph labels - RC4
- Fixed Apply/Save becoming active when looking at MSTP configuration even though nothing changed - RC6
- Fixed port number in log messages - RC6
- Fixed issue when importing config from a RevE board to a RevF with different POE port options. Affected WS-6 and WS-12 - RC6
- Changed UI layout on QOS tab - RC3
- Changed dumb DC models to temporarily disable POE when input voltage falls too low instead of disabling POE in the configuration - RC3
- Changed valid DC input voltage range to 9-72V in GUI for newer board revs - RC3
- Changed valid upper range for dc output voltage from 51V to 53V - RC3
- Changed input voltage graph to auto-scale - RC3
- Changed fan control to also use CPU and PHY temp - RC6
- Changed valid temp range on Status page meters - RC6

ENHANCEMENTS
- Added MSTP - RC3
- Automatically disable flow control on ports using QOS bandwidth limits to prevent packet locks - RC3
- Added restart timer to DC power supply to help in very cold environments with cold starts - RC3
- Added log message when time is set by NTP after boot is finished - RC3
- Added logging when STP selects new root port - RC3
- Added POE startup delay option on Power tab - RC3
- Added root path cost on STP tab - RC3
- Added portDuplex SNMP stat from CISCO-STACK-MIB - RC3
- Added ifAdminStatus to SNMP stats - RC3
- Added support for new WS-26 models - RC6
- Added Double Tagged to VLAN configuration - RC6

KNOWN ISSUES
- Some language templates need help - please contact us to help

RC3 Released 1/3/2017
RC4 Released 1/3/2017
RC6 Released 1/26/2017

[petecarlson]

Could you explain the new Double Tag option in RC6? Is it just like Q but adds a 0x8100 tag as the outer tag instead of a 0x88a8 tag?

With two Neonix switches connected together SW1 P1 T500 - SW2 P1 T500

With SW1 P2 set T500 connected to a 4948 trunk port and SW2 P2 set to D500 and connected to a switch sending C VLAN tagged packets.

I am seeing the MACs of client on V500 on SW2 and SW1, but they don't appear in the mac table of the 4948. I haven't broken out wireshark yet to see what's going on but is there an explanation of the expected behavior of "D"?

[Eric Stern]

Its in the online help. Click the question mark in the top right corner of the VLANs tab.

[petecarlson]

Thanks Eric, It doesn't seem to be working going from a Netonix switch to a cisco 4948 but I could be doing something stupid. I know that the 4948 passes double tagged 0x8100 packets, at least when going from cambium AP through a netonix switch to a 4948. I'll pcap it and see what is going on.

[petecarlson]

Looks like it might be a spanning tree issue but I have no idea how or why. The 4948 was blocking the VLAN.

VLAN0500 Desg BKN*4 128.48 P2p *PVID_Inc

bpdufilter clears it up.