OSPF area range & summary-address overlap

hostmaster · ‎09-10-2009

Question (Q1):

Can I really use an overlapping subnet/mask in both an area range and summary-address commands in OSPF?

Example:

area 1 range 172.31.1.0 255.255.255.0

summary-address 172.31.1.0 255.255.255.0

Background:

I use the 172.31 range for all the /32 loopbacks and management addr's I have. The third octect designates a site (e.g., 172.31.1 is site 1, 172.31.2 is site 2, etc). Some of these addresses are for some devices not participating in OSPF and are defined by static routes and redistributed into OSPF via an ASBR.

I only want summary routes for each of the 172.31.x from each site going into other areas.

The two commands seem to be doing what I want. Without the summary-address, I am still getting /32 routes into the backbone area (O E2 routes). Adding the summary-address with the area range, I am getting just one summary route.

Add'l questions:

Q2. Are these two commands designed to work together in an overlap like this?

Q3. How does OSPF process the two overlapping commands?

Q4. Any issues with this or better solutions?

Thanks.

Jon Marshall · ‎09-11-2009

Richard

"Can I really use an overlapping subnet/mask in both an area range and summary-address commands in OSPF?"

Yes you can because the 2 commands deal with different routes.

area range command is a way to summarise routes that are internal to the OSPF domain

summary-address is a way to summarise routes that are external to the OSPF domain that have been redistributed into the domain.

So there is no conflict between what the 2 commands are doing. In fact without both as you rightly say you will not get full summarisation.

Q2 - as previously stated they are doing different things so it's not so much designed to work together as they are just separate functions of OSPF

Q3 - again as they are dealing with different routes it's not really an issue unless i am missing the point of your question

Q4 - None that i can see

Jon

Giuseppe Larosa · ‎09-11-2009

Hello Richard,

1) The two commands seem to be doing what I want. Without the summary-address, I am still getting /32 routes into the backbone area (O E2 routes)

this happens because O E2 routes are external routes, area range commands applies to O routes in preparing O IA LSA to be sent to area 0.

O E2 routes can be summarized only by the ASBR node(s) in the act of injecting the routes in the OSPF domain.

Q2) I wouldn't say so it depends from the addressing plan: if you had a clear distinction between loopback addresses of OSPF speaking nodes and that of devices not taking in part in OSPF the two commands would create two distinct aggregates.

Q3) they are processed in parallel being different route types each of them exist if at least a component route of the right type exist in the OSPF database of the node.

Q4) Aggregating Loopback /32 ip addresses has a known drawback with MPLS: host routes are needed to setup MPLS label switched paths.

Another possible problem is the lack of support for BGP next-hop tracking.

If you don't use MPLS you should be fine.

having two /25 aggregate routes one for OSPF nodes and one for non OSPF devices can be a more clean solution in the long term.

Hope to help

Giuseppe

yagnesh_tel · ‎09-11-2009

Jon,Giuseppe

May be I am missing something here or Richard can put more lights on his topology.

There is no doubt that ABR will summarize O IA routes using 'area range' command whereas ASBR will do this using 'summary address'. So there will be two distinct summary routes for same prefix. But from the perspective of receiving router, isn't having two summarized routes will create ambiguity?

For example Router A in backbone area 0 gets two summary routes: One from ABR router B and other from ASBR router C. So it will prefer route from router B considering OSPF's preference for internal route over external. So isn't that create black hole for prefixes summarized by router C? Off course you wont have any issue if Router B and router c represent only one device.

Please comment.

Giuseppe Larosa · ‎09-11-2009

Hello Yagnesh,

I understand your concerns.

only the O IA summary route is considered outside the originanting non zero area.

When traffic hits the ABR it should forward the route to the specific host if it knows it.

the scenario tells us that both area range and summary address are given on the same router in a remote site.

if ABR and ASBR are two different routers this game becomes dangerous.

But if they are the same node no problem occurs and the only effect of the summary address is that of hiding the /32 O E2 routes on the backbone area.

Actually if the scenario is so simple even redistributing this host static routes could be avoided at all.

the O IA /24 would be enough to reach also non OSPF devices.

But the drawback is in troubleshooting.

Hope to help

Giuseppe

hostmaster · ‎09-11-2009

For clarification, the same router is a ASBR/ABR. Essentially, I had an ABR that also became an ASBR after I redistributed the static subnets to get the non-OSPF loopback/mgmt devices.

Re Q3: Since the aggregate I'm after is just that /24 for the loopbacks, I suppose it doesn't really matter if it's injected into the RIB from the area range or the summary-address as long as I have one. Regarding the OSPF process, this question inquiring into the algorithm and how it dealt with coming across an area range for subnet x and then later seeing that same subnet x in a summary-address. Is OSPF just going to inject the IA summary from the area range because of its preference to an otherwise identifical prefix? (After a bit of interpretation of the RFC here.)

Re Q4: Great idea to use /25's for the OSPF and non-OSPF devices. What design do you use for your loopbacks and do you summarize or recommend summarization (or should I just keep all the /32's visibile in the RIB for some other benefit -- MPLS/BGP not used internally, at least for now).

Jon Marshall · ‎09-11-2009

Yagnesh

To an extent it does depend on the topology. I was assuming that the ABR was the router that connected the 2 areas together and that the ASBR was contained within the none area 0 ie.

ASBR (area 1) -> (area 1) ABR (area 0) -> (area 0) etc...

So the ASBR would summarise the redistributed loopbacks and the ABR would summarise the internal loopbacks. The only way to get into Area 1 is via the ABR so it's not a problem.

I guess if you had an ABR and then another router acting as an ASBR/ABR in the same area then there would be multiple entry points into the area but the traffic would still end up at the destination, just maybe not by optimal routing.

So i'm not sure how your example creates an issue as long as the ABR & ASBR in your example connect to the same areas then traffic would still end up going to that area for the loopbacks.

Perhaps i've misunderstood ? If so please let me know.

Jon

yagnesh_tel · ‎09-11-2009

Jon

I was assuming topology where ASBR and ABR are directly connected to Backbone area 0.

So

ASBR( area x)-> Backbone area 0 -> ABR (area x)

But I guess Giuseppe imagines right topology where ABR and ASBR represent same router.

Giuseppe,

I've been expecting your interview on Netpro since few months and happy to see this morning.

Jon Marshall · ‎09-11-2009

Yagnesh

I think that was the bit that was confusing me about your example ie.

if the ASBR and the ABR are both directly connected backbone area then they would both advertise the summary address into area 0. As long as the summary address was the same then it wouldn't really matter which route was chosen by routers in other areas. As long as the traffic is sent to either the ASBR or the ABR then it will enter the correct area. It may not route the most efficient way but it would still get there.

And as the ASBR and the ABR will both know about all loopbacks within the area the routing should work.

Jon

Giuseppe Larosa · ‎09-11-2009

Hello Yagnesh,

>> I've been expecting your interview on Netpro since few months and happy to see this morning.

you are too kind I hope it doesn't look like deja vu

Best Regards

Giuseppe

yagnesh_tel · ‎09-11-2009

Not at all. Good to know your background and that hidden CCIE logo. Especially, I like your tag line :)