OSPF design trickery

[sterdnotshaken]

Hey there!

Question for ya... Here is the scenario:

A single 4500 running in a OSPF stub area with 2 uplinks to 2 separate  upstream core switches (Let's refer to them as North and South)... Your typical network triangle... All 3 are members of this same totally stub  area and as such, both upstream switches are sending default route's to this 4500. The problem comes into play when the 4500 forwards that default route received from each respective upstream switch up the other upstream link to the other core switch...

Per this, our "South" core switch, was removing the default route it was also receiving from a BGP adjacency it has with the "North" core switch (by virtue of OSPF superior AD) and replacing it with the default route received via the totally stubby area. As a result, said south switch routes all default reliant packets through the stub area and through said 4500 on it's way to the north switch and out... uhhh... less then preferred ... For obvious reasons, we would prefer the core switches use the iBGP default route instead.

How would you control this? We considered modifying the AD for iBGP, but after discussing it decided that wasn't an option. Per both core's having this same totally stubby area on them, I can't use area range or filter statements to prevent the default route sent by the north switch to the 4500 from being sent back upstream again to the south switch... We ended up putting each upstream leg from the 4500 into separate OSPF area's, which fixed the default route from going down the one leg only to travel back up the other. But personally, I don't like this solution (because of this solution, the SVI's or loopbacks on the 4500 are now only advertised up one of the 2 uplinks of whom's OSPF area they are all a member of, so we now loose the utility of redundant uplinks)...

We also tried Distrubute lists using both prefix-list's and ACL's. Nothing seemed to satisfy our need for intra-area filtration...

Idea's or recommendations?

Thanks kindly!

[mgalazka · Accepted solution]

Hello,

I am trying to fully understand how this situation came about. This post is related to the previous configuration, not the new "fixed" configuration you spoke of at the end of your post. I am going to try to describe this back to you, and please correct me where my assumptions are wrong I apologize if my post comes across redundant or just covering things you've already thought about -- I just want to make sure I am following you.

- Your topology as described is "North" and "South" core routers running BGP and OSPF.

- "North" and "South" are OSPF ABR's with link(s) in area 0 and link(s) in area X (totally stub area).

- "North" and "South" receive a default route from iBGP, which comes in with an AD of 200.

- "4500" is downstream from "North" and "South" - with 2 routed uplinks to each ABR.

- "4500" runs OSPF and only has interfaces in area X (totally stub area).

Am I correct thus far?

If so, then am I correct in saying that "North" and "South" were configured with "area X stub no-summary" while "4500" was configured with "area X stub" ?

I labbed this up to see if I could end up in the same situation you are describing, and I was able to under a pretty unique configuration.

In a "normal" scenario as described above, you would want to have a routed link directly between the ABR's "North" and "South" for them to establish neighborship. Preferrably from an optimal routing perspective, you would have a link in each area shared by those ABR's (i.e. subinterfaces with link in area 0 and area X).  Furthermore, you would want to make sure that any loopbacks are not in area 0 -- because remember, that with an ABR for a totally stub network, it will flood an LSA type 3 default route as long as it has at least one up/up interface in area 0.  This *includes* loopbacks.  If you lose all of your area 0 links to other routers, you probably don't want to advertise a default anymore!

Anyway, the scenario you are describing, where "North" and "South" were learning default route via OSPF inter-area route through "4500" -- instead of inserting the iBGP route into the routing table.  The only way I found to make this happen was if:

1. The link / neighborship between ABR's "North" and "South" was down (Area 0 is key here)

2. AND if either "North" or "South" still had another interface in area 0, then the other ABR would receive and insert that default route into its routing table. So for instance, I moved a loopback interface into area 0 on "North" - and "South" changed its routing table to use the OSPF inter-area default route through "4500".

If point #1 is resolved -- then the ABR will not insert the totally stub net summary default route into its routing table, and your iBGP route will show up.  If (per point #2) the ABR's only interface in area 0 is the link between ABR's, which is down, then the ABR will no longer flood a default route LSA type 3 route into the stub area.  Hence, the routing table for each ABR would use the iBGP default route.

I hope this makes sense.  Probably the best recommendation would be to ensure there is a neighborship on area 0 established between the "North" and "South" ABR's.

Please let me know if any of this is unclear or you have further questions.

Thanks,

Matt

[paul driver]

Hello

Be a lot easier ot understand with a topology, I was with you upto the "south core " and bgp part.

res

Paul

[sterdnotshaken]

Thanks mgalazka and pdriver for responding to my thread! Wow mgalazka, I appreciate all the effort in labbing this up! Sorry for the delayed response...

So, the design issue\picture is abit more complex then I originally stated... Per pdriver request, here is a series of drawing's that convey our plight. The first picture below illustrates what was happening when both uplinks for the 4500 were in the same Totally Stubby area...

So, here's what we did to solve it, alas, I really don't like it per the fact that any subnet assigned to the 4500 can obviously only be a member of one area, so all those subnet's and SVI's were being advertised up that one uplink... IE, no redundancy ... The default routing behavior is fixed with this design though...

Yet with this multi-area Totally Stub design, now we have the below traffic flow inefficiencies... Now the internal routes, per OSPF having better AD, flow across both core switches to get to the destination, verses what would be much more preferable, ie, traffic hitting the south core then going directly from there east to the destination subnet...

So, I guess my questions are, how would you solve this design issue? If modifying AD wasn't an option... Per the last pic, this is what makes me hesitate to form a OSPF adjacency between the Core's. Aside from forming said OSPF adjacencies between the cores to avoid the first picture default route issues, are there any other options?

Thanks in advance!