Route redistribution from BGP to OSPF and rfc1583

[actyler1001]

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.

[Joseph W. Doherty]

For starters, if you're using multiple OSPF processes, for areas zero and 40, you likely not doing what I did.

But, go ahead and post what you did.

BTW, what I did, I believe in principle, is very simple.  So much so, it might be difficult to understand if you're looking for something complex.

All I'm doing is providing a "shadow" of some or all of area zero, using another area, to "satisfy" RFC 2328.

[Joseph W. Doherty]

@MHM Cisco World Are you still going to post what you did that didn't work?  Again, from what you mentioned, I suspect you didn't do exactly what I did

[MHM Cisco World]

this Lab I run, 
I make OSPF 1020 between R1-R2-R3-R4-R5

I make OSPF 100 that only redistribute BGP into 
and then redistribute OSPF 100 into OSPF 1020
still same result 
so OSPF process is not solve issue 
I see last months two case about ABR/ASBR in same router, both face suboptimal path.
first one solve by process but this NO, we need as you suggest add new Hop (if he dont have virtual then he must buy new router to do that) or by change RFC in only R1 and R2 (this as I mention below need lab to check).

[Joseph W. Doherty]

OSPF 1020 is it's own OSPF process?

E.g. router ospf 1020

If so, that's not what I did (or suggested).

What I did was create just a new area in the existing OSPF process.

[MHM Cisco World]

Yes @actyler1001  explain that.

I was thinking that you want to add additional link between Routers with now area and this what I see from your previous post (additional link between Routers). But in reality @actyler1001  have option to add another hop (virtual) which add new area.

This new area redistribute bgp into ospf and R1 and R2 will be only abr between this new area and area0.

He share topology and I was try to solve it with out change anything add or remove hops.

MHM

[Joseph W. Doherty]

Yes, I proposed adding a link (logical or physical) between some area zero routers, using another new area.  I found this worked, although you wrote it does not!

I now understand you didn't do EXACTLY what I did, and what YOU tried did not work.

Although what I proposed worked, OP noted they were unable to add links, even additional logical links using additional tunnels.  So, we continued to look for acceptable alternative solutions beyond changing all routers to use an older RFC.

We found having the ASBR not also be an ABR avoids the issue too.  (BTW, for the record, I didn't think this would work, but I wasn't sure, so I volunteered to try it.)

The latter works well for the OP within the limitations of their environment.

However, the earlier solution, I found, might be better in other environments.

I would ask, in the future, not to write something doesn't work based on testing something SIMILAR.

[MHM Cisco World]

So, we continued to look for acceptable alternative solutions beyond changing all routers to use an older RFC. 

Not all I suggest only R1 and R2.

And I try process' which is your previus suggestion and it not work and I mention that.

For link I think @actyler1001 reply you. He need link to all router for new area.

So process and additional link not work.

Separate abr and asbr is solution since he have option to add hop.

[Joseph W. Doherty]

So, we continued to look for acceptable alternative solutions beyond changing all routers to use an older RFC. 

Not all I suggest only R1 and R2.

Unfortunately, opens risk of routing loops.  Otherwise, suspect it could work just fine.  Probably only need to change ABRs.

And I try process' which is your previus suggestion and it not work and I mention that.

Not what I suggested.  Also not knowing what you actually did, cannot say why whatever you tried didn't work.  Likely due to you adding an OSPF process.

For link I think @actyler1001 reply you. He need link to all router for new area.

Perhaps I was unclear about what I proposed?

What I proposed was another area that uses (logical - using same physical) links in parallel with area zero links.  Could parallel all or a subset (only need path to ASBRs) of area zero links.

Since the newer RFC will prefer non zero path, this new area basically provides the SAME area zero paths.

So process and additional link not work.

BTW, don't doubt whatever you did didn't work.  If what I did, which works, and does not use an additional OSPF process, is unclear, let me know.

Separate abr and asbr is solution since he have option to add hop.

Yup.

[Adam -The Man- Tyler]

@Joseph W. Doherty Thanks so much for your work here.  I really appreciate it.  While the parallel non-Area0 trick you've come up with is creative, I don't feel it is a viable solution in our environment.  If it were as easy as connecting more physical interfaces, maybe.  In our case all connections are tunnel-interfaces tied to IPSec tunnels and it would just be a mess.  I'd enable the old rfc compatibility option over this design.

If you still have your lab setup where you were able to re-create this routing problem on the ASBR, would you mind burying the ASBR back into only Area 0 one hop and sharing with me what you find?  Curious if it behaves the same way or solves this problem.

The license for me to test this on our FortiGate device is over $800 (unlock additional vdom - sort of like vrf and separate ospf process).  PO in progress....

Regards,
Adam Tyler

[Joseph W. Doherty]

Cannot say how FortiGate works, but on a Cisco router, using a parallel tunnel is trivial.  Again, you may not need a parallel tunnel for every area zero tunnel.

When I get a chance, I'll try what you want me to try.

BTW, how many area zero routers do you have?

Also, again, you do not need another OSPF process.  The new area is just like area 40, except for the routers using it would be area zero routers.

[actyler1001]

Yea most of our tunnels are on SonicWALL.  The fact that OSPF works at all on the platform is impressive.  Adding this additional layer we'll just say isn't something I'd recommend.

About 7 firewalls in Area 0.  We're about to add another critical site soon.

Super interested to see if you are able to fix this problem by adding a single hop into Area 0 for the ASBR.  I'm still waiting on my FortiGate VDOM license...

[Joseph W. Doherty · Accepted solution]

"Super interested to see if you are able to fix this problem by adding a single hop into Area 0 for the ASBR."

In my lab, using an ASBR that's just an area zero router, i.e. it's not an ABR, traffic to external chose area zero path!

That makes sense, as there's no direct non-zero area path to it.

Whether you would get the same result using a VRF, on an ABR, is a separate question because the router's VRF you would directly leak the external into, would be an ABR.

[actyler1001 · Accepted solution]

@Joseph W. Doherty , Confirmed!  Our license came in just this afternoon, and I've just finished implementing this hack in my environment.  Just a refresher that R2 and R3 in our case are two FortiGate VM04 firewalls running on the Azure platform.  Instead of VRF and a separate OSPF process (I still think this would work), they use a technology called Virtual Domains or VDOMS.  Basically an entirely virtualized firewall running on the same hardware.  Using this option to bury the ASBR one hop into Area 0 seems to have fixed this problem.  Wow, I need that Staples Easy button.

Regards,
Adam Tyer

[Joseph W. Doherty]

Fantastic!

As your VDOM creates a virtual device (similar to some network vendors providing virtual routers [not to be confused with VRFs]) it too should (and appears it does) generate the all important next hop in area zero.

I believe a VRF might not work the same.  I'm not even sure if you can leak between VRFs without using BGP and/or whether a leaked route is seen another hop away.

[MHM Cisco World]

So to clear' instead teaffic go R4 ->R5-> R1 

You add virtual FW with new areaX

So traffic is R5->R1->virtualFW 

Here you make divide the role' before R1 was both abr/asbr (no lsa4) and now it only abr(lsa4).