OSPF Type-4 LSA & The Forward-Address Part 2

VN:F [1.9.6_1107]
Rating: 3.7/5 (3 votes cast)
By Joe Astorino on November 11th, 2009

Welcome back everybody! Today we will be continuing our discussion on some of the internals of OSPF Type-4 LSAs and the forwarding-address. We will also be discussing an interesting feature known as forward-address suppression and see how it can actually dramatically change the flow of our traffic in OSPF. The diagram we will be working on is similar to the one used for part 1 of this blog, but modified to make it a bit more…interesting?

JOE55

Notice that area 56 and area 65 are both NSSA. Here is a quick summary of what we are actually doing here with all this routing madness. R7 has a loopback of 7.7.7.7/32 which it only advertises into RIP. This RIP route will get redistributed into OSPF at R6 and injected into both area 56 and area 65 as a Type-7 LSA. R5 being the ABR will then convert the Type-7 LSA to a Type-5 LSA and inject it into the backbone. The fun and magic will come with the specifics and exactly what is happening behind the scenes.

The first thing we should understand is how things happen and look during normal redistribution into a regular old area – without all the NSSA area madness. To demonstrate this quickly, lets add loopback22 on R2 and redistribute it into OSPF. This should make R2 an ASBR, and we can see exactly how the LSA looks.

R2(config)#int lo22
R2(config-if)#ip add 22.22.22.22 255.255.255.255
R2(config-if)#route-map OSPF-Connected 10
R2(config-route-map)#match int lo22
R2(config-route-map)#router ospf 1
R2(config-router)#red conn sub route-map OSPF-Connected

Excellent…let’s see what that LSA looks like on R1 inside of area 12.

R1#sh ip ospf data ext 22.22.22.22

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

                Type-5 AS External Link States

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

OK. So what is going on here? R2 has become an ASBR. We see that R2 is the advertising router for the prefix 22.22.22.22/32 as expected. The thing we want to pay attention to here is the Forward Address. It is set to 0.0.0.0. What this means is that R1 will forward traffic for this prefix to the router that originated it – R2. Simple. Now, we will revert the config and see what happens with redistribution into a NSSA.

R2(config-router)#no redistribute conn

Now we will head over to R6 and see how things look when we redistribute RIP into the NSSAs.

R6(config-router)#router ospf 1
R6(config-router)#redistribute rip subnets

R5(config-router)#do sh ip route | i 7.7.7.7
O N2    7.7.7.7 [110/20] via 56.56.56.6, 00:00:01, FastEthernet0/0.56

R5(config-router)#do sh ip ospf data nssa 7.7.7.7

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

                Type-7 AS External Link States (Area 56)

  Routing Bit Set on this LSA
  LS age: 9
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 7.7.7.7 (External Network Number )
  Advertising Router: 66.66.66.66
  LS Seq Number: 80000002
  Checksum: 0x77E0
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 6.6.6.6
        External Route Tag: 0

                Type-7 AS External Link States (Area 65)

  LS age: 91
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 7.7.7.7 (External Network Number )
  Advertising Router: 66.66.66.66
  LS Seq Number: 80000001
  Checksum: 0xCDD9
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 65.65.65.6
        External Route Tag: 0

There are a few important things to note here. First off, we are receiving TWO NSSA Type-7 LSAs for the 7.7.7.7/32 prefix. This is normal and expected as we have two NSSA (area 56 and area 65). Notice the Type 7/5 translation is set. This means R6 is setting a bit in the LSA that instructs R5 (the ABR) to translate the NSSA Type-7 LSA into an external Type-5 LSA and inject it into the backbone. This is known as the P bit, and is set by default by the ASBR when it redistributes routes into an NSSA. We’ll also notice a significant change from the first example. The forwarding address for both Type-7 LSAs is no longer 0.0.0.0. The forward address is set to R6 in both cases. The rules for what you set the forward address to are outlined in RFC 3103. In summary, first it will choose the highest loopback that is on the ASBR and that is also being advertised into the area. If there is no loopback, it will go with the highest interface that is running OSPF and also advertised into the NSSA. This is why we see 6.6.6.6 for the first LSA and 65.65.65.6 for the second. 6.6.6.6 is a loopback on R6 and it is being advertised into NSSA 56. 65.65.65.6 is the highest available address on R6 that is participating in area 65. The question then becomes if we have two Type-7 LSAs with two different forward address values, which one gets injected into area 0? Let’s check out R2 for the answer.

R2(config-router)#do sh ip ospf data ext 7.7.7.7

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

                Type-5 AS External Link States

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

There we have it. 6.6.6.6 won. Why? The first thing the router will do is check the metrics to those multiple forward addresses. In this case the metric will be 20 to both 6.6.6.6 and 65.65.65.6 because they are O N2 routes. Since the metric is tied, we go with lowest address. Another thing to be aware of here is that R5 is no longer just an ABR between area 0 , area 56 and area 65. It is now an ASBR as well because it is now generating Type-5 LSAs and injecting them (thats what an ASBR does by definition.) Therefore, some interesting things happen regarding our Type-4 LSA. Let’s look at R2.

R2(config-router)#do sh ip ospf data asbr

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

                Summary ASB Link States (Area 12)

  LS age: 1444
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 5.5.5.5 (AS Boundary Router address)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000006
  Checksum: 0xD00A
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 64

Pay very close attention. The Type-4 LSA is ONLY present in area 12. There are NO Type-4 LSAs being injected into area 0. How then do routers inside of area 0 know how to get to R6 for routes like 7.7.7.7? They will go to R5 since R5 is now acting as an ASBR as well and actually is the one generating the LSAs going into area 0. Everybody in area 0 already knows how to get to R5s RID because R5 is itself part of area 0! In area 12 however, we still will need the Type-4 LSA because routers in area 12 know nothing about R5’s RID as it is in a separate area.

So far we have seen that the behavior of the forward address parameter is different depending on if you are redistributing into a normal area or a NSSA. Furthermore, we saw a little deeper into how the Type-4 LSA works. Now we will go further down the rabbit hole hehe…Since 6.6.6.6 won the battle on R5 for the right to be sent as the forward address into area 0, we should see 6.6.6.6 set as the forward address of the Type-5 external LSA on R1 and R2. Let’s check R1…

R1#sh ip ospf data ext 7.7.7.7 | i Forward
        Forward Address: 6.6.6.6

Just as expected. Essentially this is saying “If you want to get to 7.7.7.7 you need to contact the ASBR over at 6.6.6.6.” In order for us to actually install the route in our routing table we need a valid intra or inter-area route for 6.6.6.6. Currently we have 6.6.6.6/32 as an inter-area route so we are golden. That means our ping traffic should go from R1 –> R2 –> R5 –> R6 –> R7

R1#ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

R1#trace 7.7.7.7

Type escape sequence to abort.
Tracing the route to 7.7.7.7

  1 12.12.12.2 0 msec 0 msec 0 msec
  2 25.25.25.5 0 msec 0 msec 0 msec
  3 56.56.56.6 4 msec 4 msec 4 msec
  4 67.67.67.7 4 msec *  0 msec

So far so good! NOW…can we influence what the forward address gets set to? The answer is yes we can, and in multiple ways. We have already seen that the Type-7 LSA on R5 with the best metric to the ASBR will win the battle and be injected into the backbone. Take a look:

R5(config-router)#do sh ip ospf int brie
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               5.5.5.5/32         1     LOOP  0/0
Se0/2/0      1     0               25.25.25.5/24      64    P2P   1/1
Fa0/0.56     1     56              56.56.56.5/24      1     DR    1/1
Fa0/0.65     1     65              65.65.65.5/24      10    DR    1/1

R5(config-router)#do sh ip ospf border

OSPF Process 1 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

i 2.2.2.2 [64] via 25.25.25.2, Serial0/2/0, ABR, Area 0, SPF 17
i 66.66.66.66 [1] via 56.56.56.6, FastEthernet0/0.56, ASBR, Area 56, SPF 15
i 66.66.66.66 [10] via 65.65.65.6, FastEthernet0/0.65, ASBR, Area 65, SPF 14

Did you catch the cost difference? Fa0/0.56 has a cost of 1 while Fa0/0.65 has a cost of 10. Because Fa0/0.56 has the lower metric to get to the ASBR we advertise the forward address as whatever we learned on Fa0/0.56 (6.6.6.6). What if we change things around?

R5(config-router)#int fa0/0.56
R5(config-subif)#ip ospf cost 10
R5(config-subif)#int fa0/0.65
R5(config-subif)#ip ospf cost 1

R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward Address
        Forward Address: 65.65.65.6

By simply modifying the cost of a link, we have altered where things should be heading! In this case it won’t really affect the routing path, but in certain situations it could. Are there other things we can do? Of course! The second thing we can do is this: If you make the interface on the ASBR (R6) that is facing the outside AS (RIP in this case) part of the OSPF process itself, things will change as well.

R6(config-if)#router ospf 1
R6(config-router)#pass def
R6(config-router)#no pass fa0/0.56
R6(config-router)#no pass fa0/0.65
R6(config-router)#network 67.67.67.6 0.0.0.0 area 65

What we should see at this point is that on R5 and thus R1 and R2 the forward address is now set to R6’s interface facing the RIP domain!

R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
        Forward Address: 67.67.67.6

This makes things veeeeeeerrrrry interesting! Right now, we have a route to 67.67.67.6 via R5, so things would not really be altered. What if we knew about 67.67.67.6 another way though? Let’s advertise the 67.67.67.0/24 network into OSPF on R7. Keep in mind this means that we are advertising the same prefix into two different areas at the same time – On R6 we are injecting it into area 56 and on R7 we are injecting it into area 0. This means that from the perspective of R2 we will prefer the route from R7 over VLAN 27. It is an intra-area route VS an inter-area route from area 56.

R7(config-if)#int fa0/0
R7(config-if)#ip ospf 1 area 0

Check things out on R6…

R2(config-router)#do sh ip route | i 67.67.67.0
O       67.67.67.0 [110/2] via 27.27.27.7, 02:27:31, FastEthernet1/1

Guess what? The 7.7.7.7/32 still has a forward address of 67.67.67.6. We now know about 67.67.67.6 through another path over VLAN 27. In theory, we just completely altered the path of our packets through the network! Watch this…

R1#sh ip ospf data ext 7.7.7.7 | i Forward
        Forward Address: 67.67.67.6

R1#trace 7.7.7.7

Type escape sequence to abort.
Tracing the route to 7.7.7.7

  1 12.12.12.2 0 msec 4 msec 0 msec
  2 27.27.27.7 4 msec *  0 msec

WOW! Look at that! We are now taking the path R1 –> R2 –> R7 instead!!! Now here is the REAL kicker. There is a little known feature in OSPF known as forward-address suppression and it is specific for NSSA ABRs. Imagine what would happen if R1 and R2 had no way to reach 67.67.67.0. What would happen is we may have the LSAs in the LSDB but the route would never get put into the RIB. The forward-address suppression feature is a way around this. Essentially what it does is tell the ABR of the NSSA that is injecting the Type-5 LSAs to set the forward-address to 0.0.0.0. When the other routers get the LSA they will then forward to R5 instead of 67.67.67.6. Clearly this can COMPLETELY alter our routing path without changing ANY metrics or anything. Cool huh? Let’s see it in action.

BEFORE:

R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
        Forward Address: 67.67.67.6

R2(config-router)#do trace 7.7.7.7

Type escape sequence to abort.
Tracing the route to 7.7.7.7

  1 27.27.27.7 4 msec *  0 msec 

R5(config-router)#area 65 nssa translate type7 ?
  suppress-fa  Suppress forwarding address in translated LSAs

R5(config-router)#area 65 nssa translate type7 suppress-fa

AFTER:

R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
        Forward Address: 0.0.0.0

R2(config-router)#do trace 7.7.7.7

Type escape sequence to abort.
Tracing the route to 7.7.7.7

  1 25.25.25.5 4 msec 0 msec 0 msec
  2 65.65.65.6 4 msec 4 msec 4 msec
  3 67.67.67.7 4 msec *  0 msec

That about does it for today guys!!! I really hope you all enjoyed the article and got something out of it! I will be talking to you all soon :P

Regards,

Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor – IPexpert
Mailto: jastorino@ipexpert.com
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130

OSPF Type-4 LSA & The Forward-Address Part 2, 3.7 out of 5 based on 3 ratings
Share and Enjoy:
  • RSS
  • Twitter
  • Facebook
  • Google Bookmarks
  • Digg
  • Print
  • Technorati
  • Slashdot
  • LinkedIn
  • del.icio.us
  • Reddit
  • Sphinn
  • Mixx
  • Blogplay
  • Netvibes
  • NewsVine
  • Live
  • Ping.fm
  • MySpace
  • Yahoo! Bookmarks
  • Yahoo! Buzz

4 Responses to “OSPF Type-4 LSA & The Forward-Address Part 2”

  1. Istvan Rabai says:

    Hi Joe,

    This was a very interesting post. I recreated it in my lab and played around with it and duplicated exactly what you explained.

    The only difference was the following:
    When the ospf cost of both F0/0.56 and F0/0.65 were default (1), the forward address was 65.65.65.6 on R2 in my lab. So R5 chose the highest address, not the lowest ( IOS ver 12.4(15)T9 ).

    The other thing that I wanted to mention concerning the Type-4 LSA that advertises R5 as the ASBR into area 12 (this is just for other students to learn from):

    The other important function of the Type-4 LSA is to advertise the cost of the ASBR from the advertising ABR, in our case the cost to reach R5 from R2.

    This information is used in the following situation: when the 7.7.7.7/32 prefix is redistributed on R6 as an nssa external Type-1 prefix (N1), on R1 we get the cost of 85 for 7.7.7.7/32, which is an E1 route now.

    How does R1 calculate it:
    It adds the metric values of the following LSAs: the metric of its own interface toward R2 (Type-1 LSA) + the metric of the LSA from R2 to R5 (Type-4 LSA) + the metric contained in the external Type-5 LSA.

    Well, look at the metric values on the following outputs on R1:
    “sh ip ospf int f0/0″: it will show a cost of 1 (default ospf metric).

    Then: “sh ip ospf data asbr-summary” (the Type-4 LSA): it will show a metric of 64: the cost of R2 to R5 through the s2/0 interface.

    Then: “sh ip ospf data ext 7.7.7.7″ (the Type-5 LSA): it will show the default cost of 20 for E2 or N2 routes.

    By adding these metrics you will get a cost of 85, which is the same as the output of “sh ip route 7.7.7.7″ on R1.

    This is the way the cost of an E1 or N1 route is calculated. I hope this contribution will be useful for someone.

    Once again thank you Joe very much for your excellent post. I have learned a lot from it.

    Cheers:
    Istvan

    VA:F [1.9.6_1107]
    Rating: 0.0/5 (0 votes cast)
  2. Salman says:

    This is very nice and interesting article. It clears the concept of Type-4,5 & 7 ABR and ASBR.
    Waiting of your another new article.

    regards,
    Salman

    VA:F [1.9.6_1107]
    Rating: 0.0/5 (0 votes cast)
  3. Joe Astorino says:

    Note, the RFC should read RFC 3101 not RFC 3103.

    VA:F [1.9.6_1107]
    Rating: 0.0/5 (0 votes cast)
  4. Joe Astorino says:

    Crossposted from OSL:

    Hey guys,

    I wanted to clear up a few things regarding the blog and some of the questions. We have TWO type-7 NSSA LSAs coming into R5 originally: One with forwarding-address 6.6.6.6 and the other 65.65.65.6. The question is how do we select which one to set in the type-5 LSA ? In the blog I believe I incorrectly stated it was simply due to the lowest IP address. Some of you called me on that saying you saw it was the highest ip address in your experiments and I believe you are correct.

    The reason I was seeing the lowest IP address was because the metric from R5 to the ASBR (R6) in my setup was always tilted. The link to 56.56.56.6 started with a metric of 1 whereas the link to 65.65.65.6 started with a metric of 10. THAT is the reason the 6.6.6.6 was chosen. If the metric to the ASBR was indeed equal, I believe we would see the reverse. Thanks for all the interest and EXCELLENT questions.

    VA:F [1.9.6_1107]
    Rating: 0.0/5 (0 votes cast)

Leave a Reply