Enabling OSPF for an Interface Causes Loss of PING

[Twitch]

Evening all. I did a test with enabling OSPF for several Layer 3 interfaces on our switch stack this evening. A few moments after clicking save I lost ping to those interfaces.

For example, I had a continuous ping going to the 10.0.100.1 interface that lives on the stack and had 100% successful replies with 0% loss. I then enabled OSPF for that interface and a few moments later I had 100% loss.

Is there a quirk with OSPF on Meraki that causes loss of ping to an Interface after OSPF is enabled? Or is this a sign that there is a another issue within the network that is causing this??

Thanks!

[Bruce · Accepted solution]

Did the pings come back eventually? It could just be that as the OSPF algorithm fires up its consuming a lot of resources (it has a lot to do initially), and hence doesn't have the time to respond to ICMP echo requests (pings). This wouldn't impact normal traffic as that's basically processed in hardware, but I'm pretty sure ICMP requests are punted up to the processor.

[Twitch]

Morning @Bruce - the pings do come back eventually, but then then disappear again. Functionality seems to be fine - pings out to the interwebs work fine, websites can be reached, etc. The pings only fail when going to the layer 3 interface.

Since they work then fail, then come back again, perhaps the issue is the switch dropping the ICMP packets due to demand for resources and pings are just a low priority operation like you said.

Thanks for the reply!!

Twitch

[Twitch]

@Bruce- I have to say, though, that the ratio of failed pings to successful pings HEAVILY favors failure, probably in the vicinity of 95%+ failed. I could see if it was an intermittent issue, but the failed pings seem to be the norm.

I can't imagine that would be considered normal?

The implication is once I put our data center production network on OSPF in the next few days, I will no longer be able to ping the default gateway for our 10.0.0.0/22 network, which is 10.0.0.2. It's the layer 3 address on the stack for the 10. network. I would imagine it will be reachable for production traffic, but quite possibly not reachable to ping tests to the gateway address when troubleshooting an issue.

[Bruce]

If OSPF has been up and running for a while and you’re still seeing 95%+ packet loss then it’s probably worth looking around to see if there are any other issues on the network. Are there a lot of Links State changes happening which are causing the OSPF algorithm to continually run? It might be worth logging a support ticket too, they’ll be able to see if the CPU is running high on the switch.

[Twitch]

Good points, @Bruce. I have opened a case with support.

Thanks much!

[Twitch]

@Bruce- It appears that your theory about excessive STP activity is correct:

**Update** I just spoke with support and they told me the overall STP topology looks stable, and that these events in the log are most likely not having much of an impact.