Unsolved
This post is more than 5 years old
7 Posts
0
20406
M6348 firmware 5.1.7.5 port get shutdown randomly
Hello,
I'm not a switch expert, just basic understanding of how it works and how to setup the minimum, I had two M6348 which were previously under version 4.2.0.4, It was running fine but had some bugs (in UI and commands) so I upgraded to the last version 5.1.7.5 two months ago. The bugs went away, and a few new features came, it was nice, but since this update, the switch is shutting down ports randomly. I don't know if it was STP or another protocol or a protection that does it but I can't find any reason (with my limited knowledge)
Only one port is carring the main traffic is getting shutdown almost everytime when I do a maintenance on virtual machine that host Microsoft RRAS, or sometimes without any change on the network, the port get shutdown
The two switches are not connected directly, they are connected to a sonicwall. the only link connecting them to the sonicwall is the one that get shutdown
Everything work fine for days or weeks and then the ports go down, the quickest way to fix it is just to restart the switches (from the CMC UI) and they are ok 2mins later for X hours/days.
How can I fix this issue ? it's extremely annoying.
Thank you for the help
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 30th, 2015 11:00
I would start with checking the switch logging. # show logging. Look around the time frame that the interface goes down. This should give an indication of why the interface is going down.
asanhaji
7 Posts
0
May 1st, 2015 02:00
Hello Daniel, thank you for the answer, the show logging command shows nothing regarding the problem, no logs about ports going down or up.
Do you have more suggestions please. This problem is becoming critical.
asanhaji
7 Posts
0
May 1st, 2015 06:00
The logging show nothing at this date beside a few "user logging successfully logged in or failed", nothing is talking about ports going down or up. This is why I found this strange.
I can disable STP on the ports but this is not really a solution right ?
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
May 1st, 2015 06:00
The logging should show the port going down and coming back up. Or it might show it as blocking/discarding/forwarding. Can you post up the output from the logging? Along with the time that the port last went down.
You might try temporarily disabling spanning tree on that port, see if the behavior changes at all.
asanhaji
7 Posts
0
May 1st, 2015 07:00
I could reproduce the error and this time i see the follow logs:
<190> MAY 01 14:04:56 192.168.11.252-1 CLI_WEB[219198480]: cmd_logger_api.c(260) 6171 %% [CLI:admin:192.168.11.51] User admin logged in to enable mode.
<190> MAY 01 14:04:54 192.168.11.252-1 CLI_WEB[219198480]: cmd_logger_api.c(260) 6170 %% [CLI:admin:192.168.11.51] User has succesfully logged in
<189> MAY 01 14:04:28 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6167 %% Link Up: Gi1/0/33
<189> MAY 01 14:04:21 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6166 %% Link Up: Gi1/0/34
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6162 %% Link on Gi1/0/34 is failed
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6161 %% Link Down: Gi1/0/34
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6160 %% Link on Gi1/0/33 is failed
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6159 %% Link Down: Gi1/0/33
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6158 %% Instance 0 has elected a new STP root: 8000:5c26:0af5:8a2f
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6157 %% Unit 1 elected as the new STP root
--More-- or (q)uit
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6156 %% Po2 is transitioned from the Forwarding state to the Blocking state in instance 0
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[315547504]: traputil.c(638) 6155 %% Link on Po2 is failed
<189> MAY 01 14:03:15 192.168.11.252-1 TRAPMGR[218795712]: traputil.c(638) 6154 %% DHCP Snooping error disabled interface: Po2
<188> MAY 01 14:03:15 192.168.11.252-1 DHCP_SNP[218795712]: ds_main.c(3533) 6153 %% DHCP Snooping has diagnostically disabled interface Po2. The incoming DHCP message rate on this interface exceeded the rate limit of 15 pps (burst interval 1).
I have logged in the UI and reenabled the Admin Status of the both ports 33 and 34, they are green again in the graphic, but no traffic flows correctly (I still get ping error, when previously the ping worked)
The reproduction was made by just restarting the Routing and Remote Access Service of Windows Server 2008 R2.
I am not sure from where this is from, before the firmware upgrade this didn't happened.
The only way now for this to work is to restart the switch
asanhaji
7 Posts
0
May 1st, 2015 07:00
Btw the DHCP Snooping is disabled in the global configuration "DHCP Snooping Mode -> Disabled"
it's activated nowhere no on the Ports, nor LAG, no VLAN.
NB: After the restart of the switch with the command "reload" I couldn't see any log in the [tag:show] logging from MAY 1, so the post I made before is not existing in the log of the switch why was it not recorded ?!
asanhaji
7 Posts
0
May 1st, 2015 07:00
M6348HQ002#show ip dhcp snooping
DHCP snooping is Disabled
DHCP snooping source MAC verification is enabled
DHCP snooping is enabled on the following VLANs:
Interface Trusted Log Invalid Pkts
----------- ---------- ----------------
M6348HQ002#
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
May 1st, 2015 08:00
Thanks for the update, this helps a lot. It is bizarre that with DHCP snooping disabled, it is somehow still disabling the port. Can you please test increasing the rate limit on that port channel, see if it helps.
# ip dhcp snooping limit rate 50 burst interval 1
I was looking through release notes on the firmware and noticed there is an even more recent firmware available. It would be worth the time to update the firmware and test for any behavior changes.
http://dell.to/1ApwSSR
asanhaji
7 Posts
0
May 1st, 2015 08:00
Thank you daniel, I checked the release note of the firmware upgrade too but nothing is related to this snooping bug.For the moment i just switched the ports to trust and the error is not occuring anymore. is this approche is good or should I do as you say put the pps rate to 50 ?
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
May 1st, 2015 09:00
This issue is also not listed as a known issue. Updating it, or even rolling it back, will help isolate it to this specific firmware revision or not. Trusted mode is a good idea. with trusted mode there is no need to change the rate. I would leave trust mode on the port and monitor to be sure the behavior does not continue.