Solved OSPF - Incorrect return route selected

---

Hi ITPro, I just experienced a strange issue with OSPF in the field and thought I would run it by you. This isn't Cisco gear.. Basically we had two primary links fail between Site 1 and Site 4 (See diagram), and all other links have the same cost.

The Site 1 firewall chose a route to Site 2 for Site 4 access. (Site1>Site2>Site4) 800 total cost
The Site 4 firewall chose a route to site 3 for Site 1 access. (Site4>Site3>Site1) 800 total cost

Because the return route for traffic was different, in this scenario the packets were being dropped. I can't think of a way around this issue without manually adjusting the cost values so that the most preferred path would be uses and there wouldn't be a tie like this.

I am surprised that OSPF would do this, sharing the link state database across all routers I assumed would cause the same failover route selection regardless of more than one link combination using the same cost.

Just closing the loop on this. After talking with SonicWALL and reviewing our environment, there were two changes I made that resolved this.

First, SonicWALL has asymetric route support that can be enabled on "tunnel interfaces". Who knew? I didn't.

Second, I went through and manually adjusted costs on all the links so that the traffic was a bit more predictable. So instead of relying on the routers to all select the same path with the same cost info, I just forced it.

Things have been running well since the changes. Just wanted to let everyone know what I ended up with.

Regards,
Adam Tyler

Usually if OSPF sees two routes with the same cost across two route to a destination, it will do equal cost load balancing across them.

This is called asymmetric routing which normally occurs inter-area for OSPF. I would suspect that Site 4 is not in the same area as Site1. Can you verify that both routers are in the same OSPF area?

@Ronnie-Wong Hi Ronnie, is equal cost load balancing a Cisco specific feature or is it a feature of the OSPF standard? I've only ever seen one route added to the table via OSPF on this particular equipment we are using regardless of there being another route available with the same cost.

All routers in the diagram are area border routers.. However the links in the diagram are all coded for Area 0.

Regards,
Adam Tyler

@Adam-Tyler,

What is the router vendor?

@Ronnie-Wong SonicWALL.

@Adam-Tyler,

I had to do a look up to RFC 2328. 16.8 they call it Equal-cost multipath. So it's not just a Cisco thing.

I'm not familiar with the SonicWALL implementation of OSPF. But you may have to look at documentation there to explain.

@Ronnie-Wong Ha! Thanks Ronnie. I'll follow up with SonicWALL support. Weird problem. Learning lots about OSPF....

-Adam

Just closing the loop on this. After talking with SonicWALL and reviewing our environment, there were two changes I made that resolved this.

First, SonicWALL has asymetric route support that can be enabled on "tunnel interfaces". Who knew? I didn't.

Second, I went through and manually adjusted costs on all the links so that the traffic was a bit more predictable. So instead of relying on the routers to all select the same path with the same cost info, I just forced it.

Things have been running well since the changes. Just wanted to let everyone know what I ended up with.

Regards,
Adam Tyler