We were getting random disconnects from the SQL server, which is located across 3 hops from the accounting department. The mesh devices-from the same vendor? ordered together? often sequential MACs? Know the MACs? anything:ĭid the problem start immediately after implementing the wireless mesh, or.?ĭo you have symptoms outside the switch console? Can you match it to a device connectivity problem report? Maybe if we ask enough questions we'll trigger a thought. I am hindered by the fact that I cannot troubleshoot this during normal working hours, and one soul implied I ought to be willing to come back at midnight every day until it is fixed. The broadcast traffic on the backbone is excessive, leading me to think it *might* be a packet storm, but I have to date failed to identify the loop. But packets to the destination along that route fail to arrive as that is NOT the correct path.Įvery 20 or 30 seconds or so it appears that the switches try to correct themselves, and the pings start arriving again, but intermittently, and then fail for several attempts thereafter. So the issue is the intermediary switch is being told that the path to the device it wants is actually through the questionable switch.
It shows NO dropped packets on the uplink ports. If I reconnect it, I start losing pings, but the pings are not dropping as is evidenced by looking at the port status on the destination switches.
I can disconnect that switch from the infrastructure and our pings to the rest of the switches clear up. We have updated the firmware on all the switches. My problem, as I stated before is a single mac address on multiple ports. Also, his problem is multiple macs on a single port which is quite normal if there is a device on the other end with multiple adapters, as in a virtual machine that uses bridging to share it's network adapter. Second, the command he gave does not work, unless the firmware for his particular switch is different from all the procurves I am using. Clearing the arp cache does nothing for the mac-address table. First of all, the arp table is different than the mac-address table. The advice in the posted article does not work. But what is clear is that some switches DO allow a table with a mac address showing up on multiple ports. The article actually is treating the condition where a single entry device that is doing routing connected with multiple physical links (as in static vlan connections) connected to a device which used a multiple entry table could result in a failure of Spanning Tree to properly resolve, which *might* have induced my particular issue, although it is speculation at this point. The multiple ports with one mac address is explained in an obscure document from HP which discusses the issue of some switches having single entry hardware tables, as opposed to some of them having multiple entry tables. Configured as a routing mesh also alleviates the problems.
Also, shutting off the mesh caused the packet storm to subside, which pretty much clinches it. Although I had compiled enough data from my troubleshooting techniques to come to the same conclusion, I got a tech support person at Open-Mesh to tell me they are rewriting their firmware from the ground up because their method for blocking ports in a lan bridge environment was not working correctly. First of all, the Mesh Wireless was the culprit.
0 kommentar(er)
