v1.5.5rcX Bug Reports and Comments

[mayheart]

Updated to the image you sent me, packet loss problem is back.

Code: Select all

Jan 1 00:00:10 netonix: 1.5.5rc3-201909302247 on WS-12-250-AC
Jan 1 00:00:14 system: Setting MAC address from flash configuration: EC:13:B2:64:09:0E
Jan 1 00:00:17 root: adding lan (eth0) to firewall zone lan
Dec 31 19:00:33 root: removing lan (eth0.997) from firewall zone lan
Dec 31 19:00:38 root: adding lan (eth0.997) to firewall zone lan
Dec 31 19:00:44 root: adding lan (eth0.997) to firewall zone lan
Dec 31 19:00:46 system: starting ntpclient
Oct 1 11:47:58 dropbear[1362]: Running in background
Oct 1 11:48:01 switch[1388]: temp sensor version 3
Oct 1 11:48:01 switch[1389]: Detected warm boot
Oct 1 11:48:03 monitor: restarting vtss_appl
Oct 1 11:48:17 monitor: restarting vtss_appl
Oct 1 11:48:31 monitor: restarting vtss_appl
Oct 1 11:48:44 monitor: restarting vtss_appl
Oct 1 11:48:57 monitor: restarting vtss_appl
Oct 1 11:49:11 monitor: restarting vtss_appl
Oct 1 11:49:25 monitor: restarting vtss_appl
Oct 1 11:49:38 monitor: restarting vtss_appl
Oct 1 11:49:52 monitor: restarting vtss_appl
Oct 1 11:50:05 monitor: restarting vtss_appl
Oct 1 11:50:19 monitor: restarting vtss_appl
Oct 1 11:50:32 monitor: restarting vtss_appl
Oct 1 11:50:46 monitor: restarting vtss_appl
Oct 1 11:50:59 monitor: restarting vtss_appl
Oct 1 11:50:59 monitor: restarting snmpd
Oct 1 11:51:13 monitor: restarting vtss_appl
Oct 1 11:51:13 monitor: restarting snmpd
Oct 1 11:51:27 monitor: restarting vtss_appl
Oct 1 11:51:27 monitor: restarting snmpd
Oct 1 11:51:41 monitor: restarting vtss_appl
Oct 1 11:51:41 monitor: restarting snmpd
Oct 1 11:51:55 monitor: restarting vtss_appl
Oct 1 11:51:55 monitor: restarting snmpd
Oct 1 11:52:08 monitor: restarting vtss_appl
Oct 1 11:52:08 monitor: restarting snmpd
Oct 1 11:52:22 monitor: restarting vtss_appl
Oct 1 11:52:36 monitor: restarting vtss_appl
Oct 1 11:52:36 monitor: restarting snmpd
Oct 1 11:52:50 monitor: restarting vtss_appl
Oct 1 11:52:50 monitor: restarting snmpd
Oct 1 11:53:04 monitor: restarting vtss_appl
Oct 1 11:53:04 monitor: restarting snmpd
Oct 1 11:53:18 monitor: restarting vtss_appl
Oct 1 11:53:18 monitor: restarting snmpd
Oct 1 11:53:31 monitor: restarting vtss_appl
Oct 1 11:53:32 monitor: restarting snmpd
Oct 1 11:53:45 monitor: restarting vtss_appl
Oct 1 11:53:59 monitor: restarting vtss_appl
Oct 1 11:54:12 monitor: restarting vtss_appl
Oct 1 11:54:26 monitor: restarting vtss_appl
Oct 1 11:54:39 monitor: restarting vtss_appl
Oct 1 11:54:40 monitor: restarting snmpd
Oct 1 11:54:53 monitor: restarting vtss_appl
Oct 1 11:55:07 monitor: restarting vtss_appl
Oct 1 11:55:07 monitor: restarting snmpd
Oct 1 11:55:21 monitor: restarting vtss_appl
Oct 1 11:55:21 monitor: restarting snmpd
Oct 1 11:55:35 monitor: restarting vtss_appl
Oct 1 11:55:49 monitor: restarting vtss_appl
Oct 1 11:55:49 monitor: restarting snmpd
Oct 1 11:56:02 monitor: restarting vtss_appl
Oct 1 11:56:02 monitor: restarting snmpd
Oct 1 11:56:16 monitor: restarting vtss_appl
Oct 1 11:56:16 monitor: restarting snmpd
Oct 1 11:56:30 monitor: restarting vtss_appl
Oct 1 11:56:44 monitor: restarting vtss_appl
Oct 1 11:56:44 monitor: restarting snmpd
Oct 1 11:56:58 monitor: restarting vtss_appl
Oct 1 11:56:58 monitor: restarting snmpd
Oct 1 11:57:12 monitor: restarting vtss_appl
Oct 1 11:57:12 monitor: restarting snmpd
Oct 1 11:57:25 monitor: restarting vtss_appl
Oct 1 11:57:39 monitor: restarting vtss_appl
Oct 1 11:57:53 monitor: restarting vtss_appl
Oct 1 11:58:06 monitor: restarting vtss_appl
Oct 1 11:58:20 monitor: restarting vtss_appl
Oct 1 11:58:33 monitor: restarting vtss_appl
Oct 1 11:58:47 monitor: restarting vtss_appl
Oct 1 11:59:00 monitor: restarting vtss_appl
Oct 1 11:59:13 monitor: restarting vtss_appl
Oct 1 11:59:27 monitor: restarting vtss_appl
Oct 1 11:59:40 monitor: restarting vtss_appl
Oct 1 11:59:41 monitor: restarting snmpd
Oct 1 11:59:54 monitor: restarting vtss_appl


[Stephen]

Couple things to try real quick,

First, remove the sfp module and plug in a patch cable to the router and reboot the switch by powering it off completely.
Does this issue continue?

Second, try changing the Management VLAN ID back to 1 and save. Reboot the switch again from a total power down and see if that helps.
Some of the log message's I'm seeing might point to this as the issue.

Let me know how this goes because it will dictate where I go next in the firmware.

[Ludvik]

It is not bug 1.5.5, I've noticed that before. After upgrade snmp does not return right version number.

#snmpget -v 2c -c public curve1.vinarice .1.3.6.1.4.1.46242.1.0
SNMPv2-SMI::enterprises.46242.1.0 = STRING: "Unknown"

I don't know what operations solve it. Reboot, saving configuration, trying snmpwalk (oid .1.3.6.1.4.1.46242), or only time ...

I upgrade 5 switches to 1.5.5rc2, one is OK, four is "unknown"

[mayheart]

Couple things to try real quick,

First, remove the sfp module and plug in a patch cable to the router and reboot the switch by powering it off completely.
Does this issue continue?

Second, try changing the Management VLAN ID back to 1 and save. Reboot the switch again from a total power down and see if that helps.
Some of the log message's I'm seeing might point to this as the issue.

Let me know how this goes because it will dictate where I go next in the firmware.

1) I don't have access to this switch currently to do this, I can confirm it's doing this out of the box on a brand new WS-26-400-IDC with the same SFPs.

2) Will get this done and let you know.

[Stephen]

I will see if I can find out what's happening there as well.

Speaking of which, Ludvick - would you mind sharing your "ip addr" output on the switch that you have ipv6 enabled on as well as the switch that you have IP addresses assigned to non-management VLAN's? If necessary feel free to PM me the details. It will help while I am working on some of the other things you mentioned earlier.

[Ludvik]

Yes, but tomorrow. I don't use ipv6 on production (management) network ...

[mayheart]

OK, I can confirm with VLAN 1 with uplink untagged does fix the packet loss problem. The switch has been running for 10 minutes without any restarting vtss_appl entries in the syslog.

Oddly enough it brings back the SFP model name as well in the top UI display.

[Stephen]

Ludvick, thank you - believe me I have no shortage of work in the mean time.

mayheart,

Well at the very least that is good evidence that the bug I am hunting right now that causes that is the same one that you're running into.
It's actually no surprise the SFP model name shows up again. vtss_appl is responsible for talking to inserted SFP module's, so it just needed enough time to complete the setup.

I may have another test image for you later today/tomorrow if you're still up for it. Let me know.

[mayheart]

Sure send away. I'll get it loaded on this switch. It's not going into production for a while.

Update on the current switch: up for 2h20m, not a single packet dropped.

[Stephen]

OK great, I have sent you a new test image. Let me know here how it goes.