Route redistribution from BGP to OSPF and rfc1583

[atyler555]

Hi everyone, I'm experiencing a very frustrating problem with route redistribution from eBGP into OSPF.  Consider the below diagram.  The goal is to route traffic as directly as possible to the Azure networks 10.24.0.0/16 and 10.25.0.0/16.  This was all going well until I connected a non-Area 0 (R5) router to R2 and/or R3.  See referenced links A and B in the diagram.

Once R5 brought up an adjacency with R2 and/or R3, R1 and R4 decided the best path to these /16 networks was via R5.  An ospf path cost much larger than any direct path.  I've attempted to redistribute using External type 1 and type 2, no difference.  All ospf areas are "normal".

If I take the link A and B down, all goes back to normal and routing makes sense again.  R5 in this case chooses R1 > R2 > 10.25.0.0/16.  Also R5 chooses R1 > R3 > 10.24.0.0/16.

R5 is only a member of Area 40.  R1, R2, R3, and R4 are all ABRs.  R2 and R3, ASBRs.

At first I thought this was a bug.  I've managed to make it far up the escalation chain and was finally given the response that this behavior with external routes within ospf is normal while using the default rfc2328 operating mode.  I was told that in order to deal with this I would have to enable the older rfc1583 operating mode.  On every router in our organization.  About 50.

I feel like rolling back to this older rfc is the wrong move.  There has to be another way to deal with this, but for the life of me I have yet to come up with a solution.  Other than simply NOT connecting my non-Area 0 routers directly to R2 and R3.

[Anthony_E]

Hello atyler555.

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[ebilcari]

Are all the routers FGT in this setup and are all the connections point-to-point between the routers? How does the OSPF database look like in R1 and R4 when link A and B are up, are the cost calculation done wrong while still in the database or is just updating the routing table with the wrong routes?

[atyler555]

"Are all the routers FGT in this setup"

No, it is a mixture of Cisco Nexus, SonicWALL, and FortiGate.

"Are all the connections point-to-point between the routers"

Yes, just about every connection is n IPSec tunnel interface with a little /30 network for p2p OSPF adjacency.  Costs are tuned manually in order to reliably predict failover and path selection.

"How does the OSPF database look like in R1 and R4 when link A and B are up, are the cost calculation done wrong while still in the database or is just updating the routing table with the wrong routes?"

Cost calculations look perfect when all links are up.  For O and IA routes only.  E1/E2 (LSA Type 5) routes are the ones that break.  I've been told it has to do with rfc2328, section 16.4.1. External path preferences..

[atyler555]

I have a twin of this post over on the Cisco community forum.  Quite a bit of discussion there.

Re: Route redistribution from BGP to OSPF and rfc1583 - Cisco Community

[atyler555 · Accepted solution]

I was able to solve this problem by implementing VDOM on both R2 and R3.  Basically, the ASBR was moved to the second VDOM, 1 hop into OSPF area 0.  An updated concept diagram after changes looks something like this.

 

[Toshi_Esumi]

Did you mean VDOMs(VDOM1 and VDOM2) in the diagram? If you created VDOMs, you don't need VRFs because the new VDOM is technically a new router.

Toshi

[atyler555]

Indeed.  VDOMs were used, not VRF.  The requirement was separate OSPF processes, couldn't do this without VDOMs on the FortiGate platform.  VRF was originally what I had planned to try until I realized this limitation and had to go learn VDOM.