Procurve 5412zl problem with OSPF route returning to "normal"

Good morning, Expert!  I need some help with fixing (un-doing?) an OSPF issues we're having on a newly update HP Procurve 5412zl switch.  First the environment...

Two offices (site A, site B); both offices have a fibre WAN link for dedicated intra-office traffic *and* as a redundant internet trunk in the event one office loses internet connectivity.  Each site has an HP Procurve 5412zl interfacing directly with ISP equipment, with those switches acting as primary routing devices for each office.  Just inside that device each office has a Dell Sonicwall NSA2600.  We recently updated the firmware in both switches to vK16.01.0013; after rebooting Site B immediately began routing all 0.0.0.0/0 traffic through the OSPF failover to the Site A office.  Up until that time all routing was working perfectly in both offices and OSPF functioned properly (one site loses connectivity all traffic is routed to the other; when problem is resolved the affected site immediately began routing 0.0.0.0/0 traffic back through it's respective ISP.  As of right now I can't get Site B to resume routing through ISP; routing table on 5412zl (default route 0.0.0.0/0) is still pointing at the Site A side of the WAN link, routing all traffic through Site A.

Both Sonicwall and Procurve have been rebooted in the event it was just something odd; no effect.  OSPF configuration appears to be correct and identical for both sides (setting aside obvious router ID and subnet addresses, obviously).  I can set up a static route to <insert random internet website here> on the Site B 5412zl and local traffic to that site routes perfectly through the ISP equipment/interface, as expected.  The neighbor status between the Sonicwall and the Procurve 5412lz is good and reporting Full/DR on the OSPF neighbor status.

At this point I'm at a loss as to what I need to check to verify whatever triggered the OSPF route change is, and how I can test whatever it is; connectivity between the switches, firewalls, and ISP premise equipment has been verified.  I don't want to replace the default route (0.0.0.0/0) with a static route because that will effectively nullify our OSPF failover configuration.  I also haven't seen anything in the firmware K16.01.0013 documentation that would make me think there was a major change in firmware that would cause OSPF to not return to a "normal" route.

Open to suggestions here; I don't know what else to check because it all looks perfectly fine (configuration-wise) to me.  I don't want to bloat this thread with unnecessary config files and snapshots so if you'd like something uploaded please let me know!
Thanks.
SteveB
ospf_neighbors.png
ospf-routing.PNG
LVL 2
Steve BottomsSr Network AdminAsked:
Who is Participating?
 
Steve BottomsSr Network AdminAuthor Commented:
Turns out the problem was a SonicOS (Dell Sonicwall) bug that was preventing the Sonicwall from advertising the default route to OSPF neighbors with a configuration set "correctly".  We set the OSP setting to advertise routing to ALWAYS (instead of the correct "When WAN is up" setting) and the problem went away.  Evidently Dell/Sonicwall has a PRIVATE patch that's availalble (not advertised, not published) that we now how to try to get out of Dell without tearing apart our OSPF configuration to prove we actually need it.

Closing ticket as solved.
0
 
Steve BottomsSr Network AdminAuthor Commented:
See my last comment.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.