NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
M5300 unaccessible after reload and/or uplink reboot
Hi,
Starting with the beta firmware 11.0.0.30 there is a strange behaviour to be seen on a M5300 based stack. Here are the facts.
The stack:
1 M5300-28G3
1 M5300-28GF3
Role: OSPF Area Boarder Router
VLAN:
20 - OSPF Backbone + Switch Management VLAN
48 - Clients Network
XYZ - Multiple others
Uplink:
The stack is connected to the backbone via one 10Gb line. I know, should be more but by now it is just like this.
The Problem:
I see the stack not beeing accessible by any of its IP addresses anymore from VLAN 48 after:
1. The uplink switch in VLAN 20 (backbone) gets rebooted
2. The stack itself is being rebooted (reloaded)
All the other network traffic is still running fine over it but its own IP adresses do not even respond to pings anymore.
Connecting to the stack via console and reloading it from there does not solve the problem. I have to disconnect the whole stack from the power and then reconnect it. That's the only thing I can do in order to get the stack back into a status where it is accessible through its IP addresses.
-------------
So, this is strange and as I mentioned I started seeing this after I installed the firmware version 11.0.0.30.
Could someone from Netgear take a look to this, please?
Thanks and greets,
dialsc
Hi Carl_z,
Unfortunately I have to inform you that I'm about to give up. I'm not able to reproduce the issue. Once I did a config change I thought might be the problem I was not able to get it to run into the problem again. Here's a short description.
The switch in question was originally connected to the backbone switch with one 10GB line. That line was configured to carry a couple of VLANs where VLAN 48 was one of them. This was - let's say - a leftover from when the network topology was changed/a new area introduced.
Then the setup was changed so the uplink was not just one line but a LAG with two 10GB links. This LAG was configured to also carry VLAN 48 beside a couple of others. I did miss to take away the VLAN tagging/membership settings from the first single line when the LAG was fully set up. Once the new area was introduced, I forgott to remove VLAN 48 from the LAG, as well.
So, I did remove any other VLAN setting from both, the original single line as well as the LAG thus only VLAN20 (the backbone VLAN) was active on the LAG connecting to the backbone switch. After I did that change, the problem seemed to be resolved and I was not able to force it again.
I even applied the "old" startup-config from which I know that it was running when the problem occured. No chance, I do not get the switch to run into the issue again.
So, therefore I have to give up now which - on the one hand - is something realy good... ;) On the other hand I feel sorry not being able to show you how to force this issue.
Nevertheless, I'm done now... ;)
Best,
dialsc
31 Replies
Hi dialsc,
Welcome to the community!
Can you kindly help to post the following message?
1.show ip interface brife.
2.show ip route.
It also helpful if you can send us your configuration files.
How do I send diagnostic files from my Managed Switch to NETGEAR community moderators? http://kb.netgear.com/app/answers/detail/a_id/31439
Thanks
Carl
Netgear Employee
Hi Carl,
Thank you very much for your answer. I will create the files needed and send them according to your instructions. If you don't mind I would prefere to send the information you asked for with the email I'm about to send to the community moderators.
Greez,
dialsc
Hi dialsc，
Thanks,have received the information from you.
You use the ip of vlan 20 (10.0.0.3) as management address,right?
When the issue appeared, can you try to ping from pc in vlan 48 to vlan 48's address.(192.168.48.1).
If it success, you can long in switch with the ip 192.168.48.1.Then check if vlan 20 is up or not (show ip interface vlan 20).
Also, since pcs in vlan 48 are in different subnet with management vlan , so it need to make sure pc in vlan 48 have a route to 10.0.0.3.
Regards
Carl.
Yes, kindly proceed with it for as long as the switches are not being used for production at the moment so that we could isolate the problem and verify if the problem is only present when using firmwares v11.0.0.30 & v11.0.0.31. Be reminded to perform a factory reset on the switches after reverting back to the previous firmware (to when it was working fine before) then reconfigure it from scratch in order to start clean using the firmware uploaded.
Keep us posted about the result.
Regards,
DaneA
NETGEAR Community Team
Hi,dialsc
Sorry for late to back.
I have revieve and download your configuration file to my M5300. And connection is fine.
But in your TechSupport file , there have many logs:
“<12> May 26 22:05:14 ABR-0003-1 ARP[ipMapForwarding]: ipmap_arp_api.c(1149) 3026 %% Received ARP Request on interface vlan 48 with bad target IP address 255.255.255.255. Sender IP is 0.0.0.0, sender MAC is d0:66:7b:e1:7c:1c.”
And cpu usage is 58.02%.
So the ping package may be affect by this.
In order to prove this , I simulation the illegal ARP package as in your technical support file. And send the the illegal arp package to M5300 at 100Mbps.
After reset the uplink device my pc also ping fail to M5300. But ping success once stop ARP packets.
So suggest to check in you network ,why the device(it mac is d0:66:7b:e1:7c:1c) always send illegal arp package to your M5300.
Stop the illegal arp ,then try to access to M5300.
Any results please keep us informed.
Thanks&Best Regards
Carl.
Hi Carl_z,
Thank you so much for jumping into this one, highly appreciated!
I did an inspection regarding the information you've provided and found out the following: The source of those packages is a Samsung TV. That TV is creating two packages like the one you mentioned during its startup. I just tested it by doing "normal" TV usage... ;)
It looks like the scenario as you tested it - creating this kind of packages with 100Mbps - is not what happens in real live. So far, after doing a couple of restarts and therefore having a couple of these packages sent through the network, the stack IP is still accassible through VLAN 48 once the uplink switch has been restarted. It looks like there is something else causing the inaccessibility after a while of continued operation of the stack.
I will further test it by:
1. restart the uplink switch after 1 hour of stack operation
2. restart the uplink switch tomorrow
3. restart the uplink switch after 24 hours of stack operation
3. continue to do so
Once the inaccessability reoccurs I'll create a TechSupport file immediately and provide the information to you.
Hth!
Greez,
dialsc
PS: For what it's worth I've just seen the following behaviour. I was - due to tests asked by your colleague - still running firmware 11.0.0.28. I change the config to make the version 11.0.0.31 the active one. Then I triggered a restart through the web UI. After the stack has rebooted, the same problem occurs. The mgmt IP is not accessible from my workstation -> VLAN48. After triggering a second reload through the command interface the mgmt IP has become available.
Hi ,dialsc
Do you have a serial connection to the M5300 ?
When the issue appeaer can you try to ping vlan 20 and vlan 48 (ping 10.0.0.3, ping 192.168.48.1)via serial .
By doing this , we want to confirm vlan 48 is normal or not.
If you can ping vlan 48 (excute ping 192.168.48.1 in M5300 ) successfully.
Suggest do the follwoing test
1. Assign a new port untag in vlan 48.
2. Set the port pvid to 48.
3. Connect a PC to the port and set PC's IP as 192.168.48.77(This ip can be any one that in same subnet with vlan 48)
4. Connect from the pc to 192.168.48.1.
Thanks&Best Regards
Carl.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
