Understanding OSPF route aggregation

[kamilazat]

Hi everyone,

We were having a discussion with colleagues and nobody could prove each other how an aggregate OSPF route would look like. So we set up a lab for it. 

First, we get this output from 'show route ospf' command:

OE 10.128.0.0/16 via 10.1.81.194, eth0, cost 540:0, age 2, tag 0x000003e5, instance default 
                                    via 10.1.81.195, eth0 
                                    via 10.1.81.196, eth0 
                                    via 10.1.81.197, eth0 
                                    via 10.1.81.198, eth0 
                                    via 10.1.81.199, eth0 
OE 10.128.181.254/32 via 10.1.81.194, 0, cost 540:0, age 2, tag 0x000003e5, instance default 
                                    via 10.1.81.195, eth0 
                                    via 10.1.81.196, eth0 
                                    via 10.1.81.197, eth0 
                                    via 10.1.81.198, eth0 
                                    via 10.1.81.199, eth0 

And we have this output, for example:

GW1> set aggregate 10.128.0.0/9 contributing-protocol ospf2ase contributing-route all-ipv4-routes on
It is visible as Aggregate
GW1> show route aggregate all
Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),
       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
       NP - NAT Pool, U - Unreachable, i - Inactive
 
A 10.128.0.0/9 is an aggregate route

And when we use 'refines on' flag, we get the same output:

GW1> set aggregate 10.128.0.0/9 contributing-protocol ospf2ase contributing-route 10.128.0.0/9 refines on

GW1> show route aggregate all

Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),

       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),

       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,

       NP - NAT Pool, U - Unreachable, i - Inactive

A 10.128.0.0/9 is an aggregate route 

But when we use 'exact on', the aggregate route becomes hidden and inactive:

GW1> set aggregate 10.128.0.0/9 contributing-protocol ospf2ase contributing-route 10.128.0.0/9 exact on

GW1> show route aggregate all
Codes: C - Connected , S - Static, R - RIP, B - BGP (D - Default),
       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
       NP - NAT Pool, U - Unreachable, i - Inactive
 
A H i 10.128.0.0/9 is a hidden aggregate route 

We read the documentation about aggregate routes numerous times, and figured that 'exact on' flag doesn't get activated unless it receives the exact IP range and mask.

But we still can't figure out if the aggregation works or not with the previous examples. What should we see here?

Cheers!

[Duane_Toler]

Are you trying to re-advertise the aggregate? Or just use it locally?  If you're using it locally, then what you see will be correct and your interpretation of "exact" is correct.  If you want to re-advertise it, then you need a routemap entry to advertise the aggregate.

As you already see, you need a contributing route to create the aggregate locally.  Locally, as you already see, you'll see both the aggregate and the contributing route(s).  You can then show your OSPF LSDB to see what's installed:   show ospf database

You won't see the aggregate, unless this router is an ABR and doing summarization based on the aggregate.  If you're intra-area, then you can only do filtering as routes enter the FIB from the route table manager.  All of this is best done via routemaps, however.

Keep in mind, with OSPF, all neighbors in the area need to have the same LSDB to run the SPF algorithm and build their respective SPTs.  The aggregates will largely be of most benefit when redistributing to another routing protocol such as BGP, RIP, or (again) installing locally.

Hope this helps.

[the_rock]

We had similar issue with customer and TAC guy gave us something to run to fix this, just cant recall what exactly. I would open the case and mention this post. In the meantime, will see if I can find it.

Andy