OSPF Summarization

[j.a.m.e.s]

Dear All,

Could someone advise me on some fairly naive questions around summaries in OSPF please? I have experience with EIGRP and BGP, but I'm looking at implementing OSPF at a new branch which has some unusual requirements around filtering and tagging routes.

1. Will OSPF only generate a summary if a component route is present in the LSDB? Or does the route need to be in the RIB?
2. Given that only an ABR or ASBR can generate a summary - in my diagram, could I feasibly use a narrow network statement on my branch switches alongside summary-address and redistribute connected to generate the aggregates on these normal-area routers?
3. Has anyone used a NX-OS OSPF table-map to apply a tag? The documentation wasn't clear only whether this is possible.

It might be that I'm better off using BGP or EIGRP for this task, but I would certainly appreciate some guidance on the above.

Thanks in advance,

James.

[paul driver]

Hello

---

@j.a.m.e.s wrote:

Dear All,

Could someone advise me on some fairly naive questions around summaries in OSPF please? I have experience with EIGRP and BGP, but I'm looking at implementing OSPF at a new branch which has some unusual requirements around filtering and tagging routes.

1. Will OSPF only generate a summary if a component route is present in the LSDB? Or does the route need to be in the RIB? -  for a summary to be advertised at least one of the networka in the summary needs to be advertised in ospf
   
   
2. Given that only an ABR or ASBR can generate a summary - in my diagram, could I feasibly use a narrow network statement on my branch switches alongside summary-address and redistribute connected to generate the aggregates on these normal-area routers? -  not sure i understand this -you can only summerize on a abr/asbr router so given your diagram the abrs are the core switches 
   
   
3. Has anyone used a NX-OS OSPF table-map to apply a tag? The documentation wasn't clear only whether this is possible. -Do you wish to tag a specific route of a summary ?

---

[j.a.m.e.s]

Hi Paul,

Thanks for your time. Please find my clarifications on the questions in blue below.

1. Will OSPF only generate a summary if a component route is present in the LSDB? Or does the route need to be in the RIB? - for a summary to be advertised at least one of the networks in the summary needs to be advertised in ospf.
Considering how BGP requires the component route in the BGP table, I wondered whether OSPF is dependant on the LSDB or the RIB? If EIGRP (or another routing protocol) for example installed the component in the RIB, would this trigger the OSPF summary?

2. Given that only an ABR or ASBR can generate a summary - in my diagram, could I feasibly use a narrow network statement on my branch switches alongside summary-address and redistribute connected to generate the aggregates on these normal-area routers? - not sure i understand this - you can only summerize on a abr/asbr router so given your diagram the abrs are the core switches.
Suppose I made the branch-sw1 and branch-sw2 switches ASBRs by using "redistribute connected" on these switches (would this make them an NSSA?)  that way I could originate a summary on the branch switches themseleves?

3. Has anyone used a NX-OS OSPF table-map to apply a tag? The documentation wasn't clear only whether this is possible. -Do you wish to tag a specific route of a summary ?
Yes, I'd like to generate summaries then tag them. This is working well with EIGRP because the branch routers can generate summaries then the core router uses a distribute-list to tag them based on the interface which announced them. This appears to be much harder with OSPF.

[Giuseppe Larosa]

Hello @j.a.m.e.s , @paul driver 

the summary route must be in the LSDB and in the IP routing table with the exclusion of connected for IPv4 routes.

in general OSPFv2 and OSPFv3 are very good in route filtering INTERNAL routes and not EXTERNAL routes.

Being a LS protocol the LSDB of each area is in sync in all routers belonging to the area.

Use NSSA areas , remember to inject a default route in the NSSA area on the ABR nodes.

use passive-interface vlan xx instead of redistribute connected. This allows you to build control on the ABR nodes of what internal routes are sent to the backbone area 0.0.0.0 or received from the area 0.0.0.0.

area 51 filter-list SOME-ROUTES out

This design will allow you to separate in different areas and to minimize the routing info in each area.

It also allows you to control what traffic is allowed between different departments but only when using internal routes

For external routes OSPF works in this way:

either you accept all external routes in standard area coming from the backbone

either you deny all external routes  LSA type 5 coming from area 0.0.0.0 to enter the area X LSDB  (stub area and totally stub area)

finally you deny all external routes LSA type 5 coming from area 0.0.0.0 to enter the area X LSDB  (NSSA area and totally NSSA area) but you allow space to host a special NSSA ASBR to inejct to area 0.0.0.0 some routes as LSA type 7 that can be translated by the ABR with highest router-id to LSA type 5 and sent via area 0.0.0.0 to all other areas.

The use of multiple OSPF areas is only for fine route control otherwise a single area can host hundreds of routers and multilayer switches.

Hope to help

Giuseppe

[j.a.m.e.s]

Hi Giuseppe

> the summary route must be in the LSDB and in the IP routing table with the exclusion of connected for IPv4 routes.

That's good infomation. I guess that by "the exclusion of connected for IPv4 routes", you mean the summary will be generated even if the connected route is absent from the LSDB?

Use NSSA areas, remember to inject a default route in the NSSA area on the ABR nodes.

Referencing my diagram above, I guess this command on the core-sw1 & 2 would automatically inject a default route into the NSSA area?

router ospf X
 area 1 nssa no-summary

Giuseppe, would you mind commenting on my idea of "redistribute connected subnets" on the NSSA routers (branch-sw1 & 2) alongside a summary-address? The idea is to ensure only the summaries are advertised out of the branch.

Finally, is there still no easy way to tag OSPF internal routes? This (old post) suggests it may only be possible by redistributing into another OSPF process. As an alternative, do you think I could redistribute an OSPF route into BGP and set a community based on the interface which announced the OSPF route? This would meet my goals without worrying about tagging.

[j.a.m.e.s]

Just to close down this thread, it turns out that there isn't really an easy way to tag OSPF routes, unlike EIGRP (distribute-list) or BGP (communities) and so controlling traffic asymmetry is difficult. I decided to limit the role of OSPF within the branch and do BGP back to the core.