Route redistribution from BGP to OSPF and rfc1583
-
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.
-
I have been following this post over at the Cisco Community forums - did you see the latest idea from Paul Driver? He suggested the following:
"The most simplistic way is to change the maximum metric of R5 (65535 + the cost of the destination link to azure networks) so the other rtrs will see their direct connection to the R2/R3 as preferred path.
R5
router opsf x
max-metric router-lsa summary-lsa -
@Anthony-Sequeira-0 Morning Anthony, haven't tried it yet, but I plan to! What I don't get is how the RFC reads compared with this suggestion. It appears that standard rfc2328 reads that in this scenario the backbone area will be avoided no matter what. I don't see why changing the maximum metric would have an impact, but we'll see here.
Regards,
Adam Tyler -
I saw in one of your posts that you are also using tunnel interfaces in this scenario - that could certainly be effecting things and I would not be at all surprised if that is effecting what we think should be happening...
-
@Anthony-Sequeira-0 This saga is coming to a close and I've come up with a solution that didn't involve enabling rfc1583compatibility everywhere. See the cisco post for a full explanation, but bottom line is that moving the ASBR a single hop into ONLY Area 0 resolved this.
Regards,
Adam Tyler -
Great news Adam and great work on a complex scenario!
