Nov
24

Tonight I’m posting some updates to the IEWB-RS Volume 1 Version 5.0 section of OSPF, along with an interesting teaser on how OSPF path selection works towards external routes originated in an NSSA. In my pursuit of networking Nirvana, I have a motto; learn something new every day. This topic for sure will fall into that category for many engineers.

We all (hopefully) know what an NSSA is in OSPF. It’s that cute little area that’s sort of stubby, but not completely, which allows us to cut down on the size of the OSPF database while still doing redistribution into an area. What is a little lesser known fact however, is how calculation towards an external route originated in an NSSA differs from a normal route redistributed into OSPF. Check the above link for the detailed walkthrough of how this works, along with the diagram and initial configs for those of you that don’t already have a subscription to the product, but the spirit of the situation is as follows…

As previously seen with OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0. This election process is an optimization of the OSPF database, and relates to how the Type-7 NSSA External route uses the forward address field to ensure optimal routing.

Recall that with normal external routes, only one Type-5 LSA is originated by the router performing the redistribution. When the route moves between areas, each ABR originates a Type-4 ASBR Summary LSA advertising their reachability to the ASBR. This means that for all Type-5 External LSA inter-area lookups OSPF would require Ext_Routes + Num_ABRs + Num_Routers LSAs, where Ext_Routes is the number of Type-5 LSAs, Num_ABRs is the number of ABRs generating Type-4 ASBR summaries, and Num_Routers is the number of Type-1 LSAs from the routers in the local area.

Now with Type-7 LSAs the situation becomes more complicated, because this information needs to be re-originated at the ABR level as the route moves into area 0. Let’s suppose for the sake of argument that each ABR connecting the NSSA to area 0 did do a translation of Type-7 to 5. This would mean for all inter-area lookups on a Type-5 External LSAs that were translated from Type-7, there would be (NSSA_Routes * Num_ABRs) + Num_ABRs + Num_Routers LSAs, where NSSA_Routes is the number of Type-7 LSAs to start.

This operation would be highly redundant and inefficient, because each ABR would re-originate the same Type-5 LSA, each with the same forwarding address. To avoid this only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow. This principle can be illustrated as follows.

Before any modification in the OSPF domain, R5 performs a lookup on the Type-5 LSA for 9.9.9.9 that was translated from a Type-7 LSA. At this point R3 has an OSPF Router-ID of 150.1.3.3, and R6 has 150.1.6.6. The advertising router R5 sees is 150.1.6.6 (R6), since R6 won the translator election due to the higher RID. Note however, the forward address is set to 150.1.9.9 (SW3). This means that R5 next needs to figure out how to route towards 150.1.9.9.

Rack1R5#show ip ospf database external 9.9.9.9

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 224
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 9.9.9.9 (External Network Number )
  Advertising Router: 150.1.6.6
  LS Seq Number: 80000001
  Checksum: 0x1F10
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 150.1.9.9
        External Route Tag: 0

Since 150.1.9.9 does not belong to a device in the same area as R5, an inter-area lookup is performed on the Type-3 LSA. R5 finds that two ABRs are advertising the route to 150.1.9.9, 150.1.3.3 (R3) and 150.1.6.6 (R6), both with a metric of 3.

Rack1R5#show ip ospf database summary 150.1.9.9

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

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 603
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 150.1.9.9 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0xBD35
  Length: 28
  Network Mask: /32
        TOS: 0  Metric: 3 

  LS age: 4 (DoNotAge)
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 150.1.9.9 (summary Network Number)
  Advertising Router: 150.1.6.6
  LS Seq Number: 80000001
  Checksum: 0x9656
  Length: 28
  Network Mask: /32
        TOS: 0  Metric: 3

R5 now needs to find what the metric is to reach these ABRs. R5 checks its locally originated Type-1 Router LSA and finds that 150.1.1.1 (R1) and 150.1.3.3 (R3) are directly attached, both with a metric of 64.

Rack1R5#show ip ospf database router 150.1.5.5 self-originate 

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

                Router Link States (Area 0)

  LS age: 1620
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 150.1.5.5
  Advertising Router: 150.1.5.5
  LS Seq Number: 80000019
  Checksum: 0x7DAE
  Length: 108
  Area Border Router
  Number of Links: 7

*snip*
    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 150.1.1.1
     (Link Data) Router Interface address: 155.1.0.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64
*snip*

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 150.1.3.3
     (Link Data) Router Interface address: 155.1.0.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64
*snip*

R5 asks R1 who it is adjacent with, and finds 150.1.6.6 (R6) is connected over the a Virtual-Link with a metric of 1.

Rack1R5#show ip ospf database router 150.1.1.1

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 773
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 150.1.1.1
  Advertising Router: 150.1.1.1
  LS Seq Number: 8000001B
  Checksum: 0xFA2E
  Length: 72
  Area Border Router
  Number of Links: 4

    Link connected to: a Virtual Link
     (Link ID) Neighboring Router ID: 150.1.6.6
     (Link Data) Router Interface address: 155.1.146.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

This means that R5’s intra-area cost to R3 is 64, and to R6 is 65. Since both R3 and R6 reported a cost of 3 to the forward address 150.1.9.9, the total forward metric through R6 is 65+3 = 68, but is only 64+3 = 67 through R3. Therefore although the route is originated into area 0 by R6, the Type-7 to 5 translator, the traffic does not actually flow through R6. Instead the path through R3 installed with the default redistribution metric of 20 for the E2 route, and a forward metric of 67 through R3.

Rack1R5#show ip route 9.9.9.9
Routing entry for 9.9.9.9/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 67
  Last update from 155.1.0.3 on Serial0/0, 00:17:27 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.6.6, 00:17:27 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R5#traceroute 9.9.9.9

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 155.1.0.3 28 msec 32 msec 32 msec
  2 155.1.37.7 32 msec 32 msec 32 msec
  3 155.1.79.9 28 msec *  28 msec

This illustrates why a Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup. Since the forward address is preserved only one router needs to do the translation, while the calculation of the final forwarding path stays independent

The Type-7 to 5 translator election can be modified by increasing R3’s router-id to be higher than R6’s.

Rack1R3#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R3(config)#router ospf 1
Rack1R3(config-router)#router-id 150.1.30.30
Reload or use "clear ip ospf process" command, for this to take effect
Rack1R3(config-router)#end
Rack1R3#clear ip ospf 1 process
Reset OSPF process? [no]: yes
Rack1R3#

Rack1R5#show ip ospf database external 9.9.9.9

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 42
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 9.9.9.9 (External Network Number )
  Advertising Router: 150.1.30.30
  LS Seq Number: 80000001
  Checksum: 0xE519
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 150.1.9.9
        External Route Tag: 0

R5 now sees the advertising router as 150.1.30.30 (R3), because this is the highest router-id of the ABRs connecting the NSSA to area 0.

Although the advertising router has changed, the forward address is still 150.1.9.9, which means the traffic flow has not changed.

Rack1R5#traceroute 9.9.9.9

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 155.1.0.3 28 msec 32 msec 28 msec
  2 155.1.37.7 32 msec 32 msec 32 msec
  3 155.1.79.9 28 msec *  28 msec

Only once the forward metric via R3 is higher than the forward metric via R6 will the path selection change. This can be accomplished by changing the OSPF cost on R3’s link to SW1.

Rack1R3#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R3(config)#interface Fa0/0
Rack1R3(config-if)#ip ospf cost 1000
Rack1R3(config-if)#end

Now when R5 computes the forward metric through R3 it sees the same intra-area cost of 64 to R3, but R3 increased the advertised metric to 150.1.9.9 to 1002.

Rack1R5#show ip ospf database summary 150.1.9.9 adv-router 150.1.30.30

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

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 70
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 150.1.9.9 (summary Network Number)
  Advertising Router: 150.1.30.30
  LS Seq Number: 80000002
  Checksum: 0x854B
  Length: 28
  Network Mask: /32
        TOS: 0  Metric: 1002

The final result is that the route is installed via R6 with a metric of 20 reported by the ASBR, plus the forward metric of 68 through R6.

Rack1R5#show ip route 9.9.9.9
Routing entry for 9.9.9.9/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 68
  Last update from 155.1.0.1 on Serial0/0, 00:02:06 ago
  Routing Descriptor Blocks:
  * 155.1.0.1, from 150.1.30.30, 00:02:06 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R5#traceroute 9.9.9.9

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 155.1.0.1 29 msec 28 msec 28 msec
  2 155.1.146.6 28 msec 32 msec 28 msec
  3 155.1.67.7 32 msec 32 msec 28 msec
  4 155.1.79.9 32 msec *  28 msec

If R6 loses connectivity to area 0 its route to the forward address is lost, and traffic is rerouted to R3.

Rack1R6#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R6(config)#interface Fa0/0.146
Rack1R6(config-subif)#shutdown
Rack1R6(config-subif)#

Rack1R5#traceroute 9.9.9.9 

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 155.1.0.3 28 msec 32 msec 28 msec
  2 155.1.37.7 28 msec 28 msec 28 msec
  3 155.1.79.9 32 msec *  28 msec
About Brian McGahan, CCIE #8593, CCDE #2013::13:

Brian McGahan was one of the youngest engineers in the world to obtain the CCIE, having achieved his first CCIE in Routing & Switching at the age of 20 in 2002. Brian has been teaching and developing CCIE training courses for over 10 years, and has assisted thousands of engineers in obtaining their CCIE certification. When not teaching or developing new products Brian consults with large ISPs and enterprise customers in the midwest region of the United States.

Find all posts by Brian McGahan, CCIE #8593, CCDE #2013::13 | Visit Website


You can leave a response, or trackback from your own site.

14 Responses to “New OSPF Updates + OSPF NSSA Teaser”

 
  1. Vladimir Sousa says:

    Really nice article dissecting this OSPF cost calculation.

    What are the modifications on this logic when we set the FA to 0.0.0.0 (area area-id nssa translate type7 suppress-fa) in case the FA is not reached with OSPF (O or OI)?

    Regards,
    Vlad

  2. Khurram Khalid says:

    How much fortunate for me, while studying OSPF, i was confused and still before reading this article about Forwarding address,its really nice.

    regards,
    Khurram

  3. josephc says:

    “Tonight I’m posting some updates to the IEWB-RS Volume 1 Version 5.0 section of OSPF”

    Hi Brian,

    The file in the vol 1 version 5.0 is still dated August 21st. Is this delayed?

    Thanks

  4. Vlad,

    There is a specific task dedicated to this that covers it in detail, but in summary if you suppress the forwarding address, the lookup occurs on the advertising router. This essentially means that if the Type-7 to 5 translator does the suppression of the FA, the traffic *must* flow through the translator, even if there is a shorter path through some other ABR.

  5. josephc says:

    Thanks, Brian.

  6. Eugenia says:

    Hello,
    Where are the diagrams for CCIE R&S Lab Workbook Volume I Version 5.0 OSPF?
    There are no OSPF areas on the initial diagrams.
    Sorry to distrub you.
    Thanks a lot, Eugenia

  7. Nicolas says:

    Hi Brian,

    If a router has Type 7 and Type 5 LSAs to a prefix, how does it compare them together?

    If I remember my Jeff Doyle’s, in the SPF calculation, intra-areas paths are preferred over inter-area paths which are preferred external paths.
    If I have Type 7 and Type 5, does the router compare their metric or are Type 5 preferred over Type 7?

    I’d also love to read a good explanation on the routing bit, the P bit and the Down bits.

    Thanks,

    Nicolas

  8. TheCount says:

    Hi Nicholas,

    With reference to your question, I think that a Type 7 will never be compared to a Type 5 as Type 7 LSA only exist in an NSSA and Type 5 LSA’s will never appear in an NSSA. So this way you will either have a Type 7 or a Type 5 only in any area. This is from my understanding ( I could be wrong :P ).. but since you asked Brian maybe lets wait for his answer.

  9. It could be possible depending on the design of the OSPF topology. Suppose the network looks like this:

           Area 0
            _____
           /     \
    RIP--R1       R2
           \_____/
    
         Area 1 NSSA
    

    R1 and R2 have two links to each other, one via area 0 and one via area 1 which is NSSA. R1 redistributes RIP into OSPF, originating a Type-5 External LSA into area 0, and a Type-7 NSSA External LSA into area 1. Which will it prefer?

  10. Shawky says:

    Hello Nicolas,
    Below is from rfc 1587 :

    When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie.
    a. Any type 5 LSA.
    b. A type-7 LSA with the P-bit set and the forwarding address non-zero.
    c. Any other type-7 LSA.

  11. Paul says:

    Hi all,

    I’m having trouble understanding how the Forward Address is selected.

    AREA 0 AREA 1 NSSA

    ____R1____
    / \
    / \
    R0 R3---RIP
    \ */
    \__________/
    R2

    In the example above R1 and R2 are the ABRs between the NSSA and Area 0.

    All links are equal but no matter who is the type-7 to type-5 translator the path via R2 is always preferred.

    Both R1 and R2 see the Forward Address as R3’s link to R2 (see * )

    Any ideas?

    Cheers,

    Paul

  12. Paul says:

    Fixed diagram for post above. Cheers

    AREA 0 AREA 1 NSSA

    ____R1____
    / \
    / \
    R0 R3—RIP
    \ */
    \__________/
    R2

  13. Bobby Hockensmith says:

    Brian,

    Why will an ABR that learns the translated Type-5 with a non-zero forwarding address create the Type-4 for the NSSA ABR and inject it into its attached non-backbone areas since as you say “a Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup”.
    This is of course when there are no other Type 5s originated by this ASBR that have forwarding address of zero.

 

Leave a Reply

Categories

CCIE Bloggers