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: OSP...
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
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
