This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Regarding your message before your last one. I did what you asked me to do. I connected to the stack via USB console and performed the ping tests, here's the result:
(M5300-28G3) >ping 10.0.0.3 Pinging 10.0.0.3 with 0 bytes of data Reply From 10.0.0.3: icmp_seq = 0. time <1 msec. Reply From 10.0.0.3: icmp_seq = 1. time <1 msec. Reply From 10.0.0.3: icmp_seq = 2. time <1 msec. ----10.0.0.3 PING statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (msec) min/avg/max = <1/<1/<1 (M5300-28G3) >ping 192.168.48.1 Pinging 192.168.48.1 with 0 bytes of data Reply From 192.168.48.1: icmp_seq = 0. time <1 msec. Reply From 192.168.48.1: icmp_seq = 1. time <1 msec. Reply From 192.168.48.1: icmp_seq = 2. time <1 msec. ----192.168.48.1 PING statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (msec) min/avg/max = <1/<1/<1
Then I connected the workstation to a port configured as untagged VLAN 48 at the stack directly and the ping to the mgmt IP still fails. Furthermore pinging other IPs configured on the stack fail, too. For example pinging 192.168.48.1 (VLAN 48) also fails. It seems that none of the IP configured at the stack can be accessed from my workstation in VLAN 48.
Very interessting: EVERYTHING ELSE seems to work fine. Traffic from and to any of the VLANs connected to and routed over the stack seems to working fine. All this traffic is being routed over IPs configured at the stack.
---------------
Regarding your latest message. Sure, no problem. Can you please tell me where to send the configs to?
Yes, it is strange. But hey, I'm used to face strange problems... 😉 Thanks for the link!
I can assure that the workstation's IP settings are fine. In fact even DHCP works after the stack becomes inaccessible but of course I double checked it.
Right now I'm in the process of cleaning out older VLAN settings through out the different interfaces at the stack -> Trunk allowed VLANs settings, asf. After that I will wait a couple of hours up to a day and then check if that changes something. I will let you know as soon as possible. If this doesn't help, I will prepare and send the configs to you. I hope that's fine for you.
I just wanted to let you know that I found how to avoid the problem. Right now I'm still trying to reproduce the problem but I wasn't lucky so far. I will keep you informed about what ever I find.
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.
