v1.4.7rcX Bug Reports and Comments

[giannici]

1.4.7rc7 gives "invalid field" trying to save a config with a WS-8-150-DC (I think due to "Power" tab).
No problem downgrading to 1.4.7rc4.

[Eric Stern]

1.4.7rc7 gives "invalid field" trying to save a config with a WS-8-150-DC (I think due to "Power" tab).
No problem downgrading to 1.4.7rc4.

This will be fixed in the next release.

[tma]

Eric, on the QoS tab, please permit specifying CIDR networks with a prefix length in addition to network masks, i.e. 10.11.0.0/15. It is so much more readable - and it would actually fit into the field :-) which an ip/netmask pair usually does not, hiding the last component which is the one that needs to be checked most often. So widening that field somewhat would be a good idea too.

[tma]

On the QoS tab, if I want to prioritize OSPF packets, what "type" should I choose?

My first thought was to identify them by IP protocol 89, but there's no "IP protocol" type. My second though was to identify OSPF by its multicast address(es), but that one appears on the target side always - and there's only a "Source IP" type. Maybe, there's a trick with one of the other types?

Chris, btw, I'm lab testing how far I could get in moving QoS from EdgeRouters (which don't support it unless one sacrifices hardware acceleration) to the switches. When I brought that up earlier, you mentioned your next gen switches will be able to do it. In the meantime, though, QoS on this generation of switches has gotten far more options than I thought it would ever have. That's why I'm trying with what we got now and I'm asking myself (or you :-): Is an "IP protocol" or "Target IP" type something that can't be done with the current chipset, i.e. should I wait for next generation?

Related: You mentioned the "WS-26" in the release notes. Is that a next gen switch or a redesign of the current 24-400 or just an internal nickname of the 24-400?

[Eric Stern]

On the QoS tab, if I want to prioritize OSPF packets, what "type" should I choose?

My first thought was to identify them by IP protocol 89, but there's no "IP protocol" type. My second though was to identify OSPF by its multicast address(es), but that one appears on the target side always - and there's only a "Source IP" type. Maybe, there's a trick with one of the other types?

Chris, btw, I'm lab testing how far I could get in moving QoS from EdgeRouters (which don't support it unless one sacrifices hardware acceleration) to the switches. When I brought that up earlier, you mentioned your next gen switches will be able to do it. In the meantime, though, QoS on this generation of switches has gotten far more options than I thought it would ever have. That's why I'm trying with what we got now and I'm asking myself (or you :-): Is an "IP protocol" or "Target IP" type something that can't be done with the current chipset, i.e. should I wait for next generation?

Related: You mentioned the "WS-26" in the release notes. Is that a next gen switch or a redesign of the current 24-400 or just an internal nickname of the 24-400?

I can add "IP Protocol" in the next release. "Target IP" is not supported by this generation of switches.

The WS-26 switches are a redesign of the current gen.

[tma]

Many Thanks, Eric, "IP Protocol" would be very handy indeed - not only for OSPF but also for VRRP, ICMP, GRE, ESP/IPsec.

[sirhc]

People with WS-8-150-DC PLEASE READ RELEASE NOTES FOR RC8

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
- Fixed the support for WS-8-150-AC - RC7
- Fixed console login
- Fixed/Force powerdown/powerup limits on WS-8-150-DC to help prevent switch lock up when draining battery to 9V - RC8
- Fixed DC2DC-500 detection for WS-26-500-DC - RC8
- Fixed voltage range on dumb DC models - RC8
- 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
RC7 Released 1/27/2017
RC8 Released 2/7/2017

[petecarlson]

v1.4.7rc6 and newer appear to break the trunk vlan checkbox (Access List) feature. Tested working with 1.4.6 1.4.7rc4. Not working in 1.4.7rc6, 1.4.7rc8.

CP

[Eric Stern]

v1.4.7rc6 and newer appear to break the trunk vlan checkbox (Access List) feature. Tested working with 1.4.6 1.4.7rc4. Not working in 1.4.7rc6, 1.4.7rc8.

CP

I'll look into it.

[tma]

I've just had a strange experience with the access list function and finally locked myself out, although the switch should have reverted to the previous configuration, but it didn't. Some details:

This happened on v1.4.7rc7.

When I entered the first source subnet on the access list, a popup appeared reminding me to add the subnet the switch is currently in - nice. I did that and added a few more subnets from our NOC. I saved and access was still okay. Next, I unchecked all Enable options for all subnets, saved and still had access. Having a pre-defined list of subnets, all disabled, was actually what I was hoping for as a template. So far so good.

I then re-enabled one of the pre-defined subnets, but not the one I was directly connected with. After saving, I had access still - strange. I had expected to be locked out and the switch reverting itself to the previous working configuration which was all access subnets disabled.

To test me being locked out, I deleted the one subnet definition that matched my current (directly connected) source address, and saved. The switch accepted that and did not lock me out at first, i.e. the GUI came back. But a few seconds later, the red connection lost banner appeared and indeed I had lost access. No way to get back in w/o doing a reset to default config.

So there's actually two weird things going on:

1) If the list of access subnets contains a subnet that matches the IP of the switch and the accessing PC, access is granted even if this subnet definition is disabled - as if the enable/disable option had no effect at all.

2) If the subnet matching the IP of the switch and its managing (directly connected) PC is deleted, the revert feature won't work because access is still available a few seconds after the GUI returns from saving. A few seconds later access is lost though, as if the access list had been applied asynchronously after saving.

I had to ship this switch, but I can try to set this up later in the lab. OTOH, if you know the explanation is that the access list is applied asynchronously (with a delay), I can live with that.