Can't figure out this ospf summarization problem

[cisconoobie]

Can someone shed some light on this for me? I'm just stuck not knowing what to do.

I'm running OSPF on Core101, Core102, Distro1 & Distro2.

All 6 interfaces that connect to each other are in area 0, even the link between distro1 and distro2 because I am not spanning vlans. All 6 interfaces are using /29 as point to point links.

Hsrp is used on distro1 and distro2 and basically sends hellos through the access layer.

I am manually pruning vlans off the trunks links between:

access 1 & distro1 and Distro2

switch trunk allowed vlan 96,97

and access2 to distro1 and distro2

switchport trunk allowed vlan 98,99

To keep this network clean, I was advised to summarize the connected vlans on distro1 and distro2 into ospf.

On Distro1 & Distro2 I redistribute connected subnets. Then I summarize the routes

summary-address 10.28.96.0 255.255.248.0

This creates a summary route null0 route in the routing table on both distro1 and distro2.

Everything is great if a failure does not occur, but if Distro1 loses the link to access1, vlan 96 and vlan 97 connected routes get removed from the routing table but the summary route 10.28.96.0 null0 still remains!

This blackholes the traffic destined for vlan 96,97 on distro1 from the Core because the summary route is still advertised out to Core101 and Core102.

How can I redirect the traffic that came into distro1 for vlan 96,97 (if it goes down) to Distro2 and have it forward to its vlan 96,97 destination?

I'm stumped, I created a static route but that causes a loop if Access1 goes down.

[simontibbitts · Accepted solution]

Hello.

The reason the null0 summary route stays in the routing table is because it still has active routes that are covered by it (The routes to VLAN 98 and VLAN 99 which the summary also covers)

You could resolve this by instead advertising two summary routes 10.28.96.0/23 & 10.28.98.0/23 from both routers. That way if the link goes down again then the null0 summary should also get dropped.

Simon

[lee.reade]

Hi,

What you should do is, have area 0 between the dists and cores, and have another area between the dists, say area 1.

The use area range command on dists to summarise to core, this way, each will install its own route to null0, and if it loses its link to access switch vlans, it will then remove its own local routes for those vlans, but will then learn them through the area1 connection via ospf from the other dist.

Basically, because you only have one area and are doing redistribution, there is no way for the dists to learn the other path via other dists.

Try this and let us know.

HTH

LR

[lee.reade]

Sorry meant to add, that you would include the access vlans into the area1 in as intra routes and not external.

[Giuseppe Larosa]

Hello Sparky,

as explained by Simon or you split the summary-address in two more specific entries that closely follows your topology, or you need to provide a backup L2 trunk for the access-vlans from dist1 to dist2 to solve the black hole problem.

The first one is to be preferred.

Hope to help

Giuseppe

[cisconoobie]

Thank you all for responding. If I create 2 different summary routes, then Core101 will have 2 different /23's from both distro1 and distro2.

If the link from distro1 to access1 fails, then the summary route on distro1 will get removed for the /23 and trigger LSU's in the ospf domain.

Wouldn't this defeat the purpose of summarization?

Don't you summarize to prevent these calculations from traversing the whole network?

[Giuseppe Larosa · Accepted solution]

Hello Sparky,

yes but the limit of summarization is accuracy: a summary route is too big if a black hole can form.

We can also say that in performing summarization we should follow the topology: in your case the component subnets are connected via two different links and this call for two summary routes in order to be accurate and fault tolerant.

So we need to trade off, however up to 5000 routes in OSPF are manageable in multi-area, what you cannot absolutely do is to redistribute the full BGP internet (270000 prefixes) into OSPF.

To help reduce SPF calculations you could move to a multi-area and have all access subnets in different areas and use network commands as correctly suggested by Lee.

Hope to help

Giuseppe