9

Preparing for CCNP, doing some lab work. ZEUS is summarizing two loopbacks with area 2 range 172.16.2.0 255.255.254.0, and the summary route is arriving on router 'WODAN' but the subordinate routes (2 /32's) are also still showing up in WODAN's ip routing table. Why? My understanding was that once the summarization occurred that the normal T3 LSA's would not be sent, instead a summary T3 would be sent by the ABR (zeus in this case)? I can't understand why I still see /32's if the summary is received on WODAN.

Here are the topology and relevant command outputs for the two routers in question.


Topology Diagram:

ZEUS Configuration:

WODAN routing table:

1 Answer 1

9

The short answer is because ZEUS (which is summarizing) is summarizing for Area 2, but it also shares Area 2 with WODAN. OSPF requires all routers in an area to have the same exact copy of the area's link-state database; OSPF ABRs run a separate SPF algorithm calculation for each area they participate in.

Quoting RFC 2328 - Open Shortest Path First:

  1. ...
  2. ...
  3. ...
  4. Functional Summary

A separate copy of OSPF's basic routing algorithm runs in each area. Routers having interfaces to multiple areas run multiple copies of the algorithm.

...

12.2. The link state database

   A router has a separate link state database for every area to
   which it belongs. All routers belonging to the same area have
   identical link state databases for the area.

You can verify this with:

WODAN# show ip ospf database | i ID|Area|Link|172.16.2
...
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Summary Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
172.16.2.0      3.3.3.3         1721        0x80007657 0x006E08 1
...
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Router Link States (Area 2)
Link ID         ADV Router      Age         Seq#       Checksum Link count
172.16.2.2      3.3.3.3         1721        0x80007657 0x00640F 1

I mocked that output up from experience, but I expect you to see:

  • The Network Summary LSA for 172.16.2.0 in Area 0
  • The Router LSA containing 172.16.2.2 in Area 2 (I made the assumption that 172.16.2.2 is the Router LSA's ID)

Since 172.16.2.2 still exists in the OSPF LSDB, OSPF installs a route for it. Note that there is a difference between 172.16.2.2/32 and 172.16.2.0/23 in the output of show ip route:

  • 172.16.2.0/23 is an O IA route (IA means Inter-Area, generated by a Type 3 Network Summary LSA)
  • 172.16.2.2/32 is an O route, if there are no letters following the O, then the route comes from a Router LSA, also called Type 1 LSA

A final side note that you didn't explicitly mention... you configured ZEUS' Loopbacks with 24-bit masks; however, due to the way OSPF handles loopbacks, those loopbacks are advertised as host routes.

3
  • Ok, so you're saying, even though ZEUS is summarizing (and it's showing up in WODAN as a summary), WODAN is also doing it's own SPF calc and so it's picking up the loopbacks also unsummarized. Is there a way to achieve just a one line summary? Would I have to make a summary on WODAN, or is this just a limitation of OSPF - no same area summarization? Just at edges?
    – A L
    Dec 6, 2013 at 17:26
  • 1
    @AL, the only way to get rid of 172.16.2.2 on WODAN is to ensure that the LSA doesn't show up in an area that WODAN is attached to. One of the limitations of link-state IGPs is their inability to summarize routes sourced within the same area. Dec 6, 2013 at 17:30
  • 1
    Awesome, I completely understand this now and would expect this in the future. Also explains why when I advertised the Loopbacks into Area 4, it showed up as I was wanting - a one line summary. VERY COOL! Thanks for this Mike.
    – A L
    Dec 6, 2013 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.