Path Selection with Summarization

So I created a summary address on R5 (area 1 range 155.1.146.0 255.255.254.0) When I look at R8, I see a summary DB entry for 155.1.146.255? I am not sure I understand why I am seeing a .255 for the more specific entry on R8. Shouldnt it be two entries with .0 at the end?

 

                Summary Net Link States (Area 3)

 

Link ID         ADV Router      Age         Seq#       Checksum

155.1.146.0     150.1.5.5       220         0x80000011 0x00A4B6

155.1.146.255   150.1.5.5       13          0x80000001 0x00F38B

 

R8#show ip ospf database summ 155.1.146.0

 

            OSPF Router with ID (150.1.8.8) (Process ID 1)

 

                Summary Net Link States (Area 3)

 

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 255

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 155.1.146.0 (summary Network Number)

  Advertising Router: 150.1.5.5

  LS Seq Number: 80000011

  Checksum: 0xA4B6

  Length: 28

  Network Mask: /23

        MTID: 0         Metric: 2 

 

R8#show ip ospf database summ 155.1.146.255

 

            OSPF Router with ID (150.1.8.8) (Process ID 1)

 

                Summary Net Link States (Area 3)

 

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 65

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 155.1.146.255 (summary Network Number)

  Advertising Router: 150.1.5.5

  LS Seq Number: 80000001

  Checksum: 0xF38B

  Length: 28

  Network Mask: /24

        MTID: 0         Metric: 1001 

Comments

  • right but I am still confused on why it is showing 255.

  • Same thing is happening to me. I issued the following on R4

      area 1 range 155.1.146.0 255.255.254.0

    However now the OSPF DB for areas other than 0 and 1 looks odd



    R9#sh ip ospf database | in 155.1.146

    155.1.146.0     150.1.3.3       790         0x80000004 0x000D73

    155.1.146.255   150.1.3.3       790         0x80000003 0x003D58




    R9#sh ip ospf database summary 155.1.146.0


                OSPF Router with ID (150.1.9.9) (Process ID 1)


                    Summary Net Link States (Area 2)


      LS age: 821

      Options: (No TOS-capability, DC, Upward)

      LS Type: Summary Links(Network)

      Link State ID: 155.1.146.0 (summary Network Number)

      Advertising Router: 150.1.3.3

      LS Seq Number: 80000004

      Checksum: 0xD73

      Length: 28

      Network Mask: /23

            MTID: 0         Metric: 1002


    R9#sh ip ospf database summary 155.1.146.255


                OSPF Router with ID (150.1.9.9) (Process ID 1)


                    Summary Net Link States (Area 2)


      LS age: 825

      Options: (No TOS-capability, DC, Upward)

      LS Type: Summary Links(Network)

      Link State ID: 155.1.146.255 (summary Network Number)

      Advertising Router: 150.1.3.3

      LS Seq Number: 80000003

      Checksum: 0x3D58

      Length: 28

      Network Mask: /24

            MTID: 0         Metric: 2001





    Per haps this is because the summerized route is occupying the .0 for the link ID so the actual prefix has to use a new??? That may be a stretch.
  • I'm using INE's racks. So CRS1000v

     

  • Also ran into this today. And it appears it has to do with the same Link State ID.

    My setup:

     

    (AREA 1 - R1,R4, R6) - (AREA 0 R5) - (AREA 3 R8) - (AREA 3 R10)


    I had 3 routers (R1, R4, R6) on the same segment: 155.1.144.0/24 in Area 1

    All 3 routers connected to Area 0

    I configured summarization as follows:

    R1: 155.1.144.0/24 - no summarization

    R4: 155.1.144.0/23

    R6: 155.1.144.0/22

     

    So I had 3 Summary LSAs coming into Area 0, with Subnet Mask /24 , /23 and /22. The router on the other end, ABR to area 3, had all three Entries for Area 0 as expected:

    155.1.144.0     150.1.1.1       884         0x80000002 0x006209

    155.1.144.0     150.1.4.4       174         0x80000005 0x003033

    155.1.144.0     150.1.6.6       98          0x80000005 0x000C55

     

    However, for Area 3, they looked like this:

    155.1.144.0     150.1.5.5       96          0x80000004 0x00174D

    155.1.144.255   150.1.5.5       170         0x80000002 0x006215

    155.1.145.255   150.1.5.5       96          0x80000001 0x0084D5



    When I removed the summary address on R6 the following entries remained on R5:




    155.1.144.255   150.1.5.5       822         0x80000002 0x006215

    155.1.145.255   150.1.5.5       749         0x80000001 0x0084D5





    I could reset this by clearing the ospf process. Then the entries start at 155.1.144.0 again. 



    The real confusion is when you look into the next area (Area 3) on R8 and you are expecting a Summary LSA with the "correct" link state ID but cannot find it.



     

    I wonder what would happen if you add say Area 10 behind R10. Then have a virtual Link between R8 and R10. So now the summary gets advertised into Area 10, but what will it look like? If it looks like 155.1.144.255 - what will happen if you wanna do some filtering into Area 10? On what do you have to match?

     

     

  • This seems to be the answer:

    http://tools.ietf.org/html/rfc2328#appendix-E

    And the reason is this:

    12.1.  The LSA Header

    The LSA header contains the LS type, Link State ID and
    Advertising Router fields. The combination of these three
    fields uniquely identifies the LSA.

     

     

Sign In or Register to comment.