OSPF Forwarding Address Part III: The perfect recipe for chaos

After getting familiar with the FA, when it’s set and when not, we’re ready to cook the recipe for chaos: NSSAs, Default Route injection and Forwarding Address.

Probably a good disclaimer for this article is – I agree, usually there are other, more simple and straightforward solutions to doing what I did, but in cases where you know 3 solutions to a problem, and none can be applied, it’s good to have the 4th one a click away.

Network Design

To begin with, the network design we’re going to be experimenting on today is not extremely common, but has a practical application though.

ospf-p3-1

Configuration

I will start by not sharing the configuration files for this design, with a simple reason – Please lab it yourselves! You will have all sorts of things to gain from this, from typing rapidity, thinking the addressing scheme to troubleshooting your own mistakes. It’s not that big of a deal and it should not take you more than half an hour.

On a high level overview, everything you need to know is on the scheme. Nevertheless, here are the configuration principles:

  • Each router has a loopback configured, to ease things when it comes to router IDs
  • OSPF has default configuration everywhere, no metric tweaking, no additional options. It is just activated. Also, areas are as described above
  • The 2 eBGP sessions are configured with the only command needed. Nothing more. You can choose any ASNs you want. Mines are: ISP1=ASN100, ISP2=ASN300, ASBR3/4= ASN200
  • ASBR3/4 do not have an iBGP session configured. You can try and see what happens
  • Both ISP1 and ISP2 only announce the default route to ASBR3 and ASBR4 respectively
  • ASBR3/4 do no apply any changes to the routes received from the ISPs
  • ASBR3/4 are configured to redistribute BGP into OSPF, both with the following command:

ASBR3/4(config-router)# redistribute bgp 200

  • No filtering is configured anywhere whatsoever

First problem – “Where’s the RFC???”

If you’ve never met this design before you may think you forgot how to configure either OSPF or BGP, because there will be no default routes redistributed. Let’s have a look at the status.

ASBR3/4 receive the default routes via BGP and install them in the routing table:

ABR4_ASBR4#show ip route bgp
—Output omitted—
Gateway of last resort is 100.100.100.2 (ISP2) to network 0.0.0.0
B*    0.0.0.0/0 [20/0] via 100.100.100.2, 00:25:33

ASBR3#sh ip ro bgp
—Output omitted—
Gateway of last resort is 200.200.200.2 (ISP1) to network 0.0.0.0
B*    0.0.0.0/0 [20/0] via 200.200.200.2, 00:28:37

That’s one good thing. Next let’s see the OSPF database on the 2 routers:
 
ASBR3#sh ip ospf database nssa-external
            OSPF Router with ID (33.33.33.33) (Process ID 1)
 
ABR4_ASBR4#sh ip ospf database nssa-external
            OSPF Router with ID (4.4.4.4) (Process ID 1)

Nada. Question is obviously why? Well, first time you bump your head into this, you would probably not know that Cisco hardcoded into IOS that a default route cannot be redistributed into OSPF or IS-IS. So…

ospf_p3_2

So how do we do it then?

First let’s remember that an ABR of an NSSA area does not automatically inject a default route into the NSSA to compensate for the fact that there are no external routes allowed in the respective area (no T5 LSAs allowed).

Why is that? Answer is simple: NSSA areas are actually made to be used in this type of design, at the edge of the network. They are quite often used for connecting to the Internet and so they don’t need a default route to the inside of the network.

The above being cleared, there are a few ways of actually injecting the default route into OSPF without redistributing it, the simplest being to add the “default-information originate” command on both ASBR3 and ASBR4. But I for one will go with another more interesting method. You may be familiar with the command “area X nssa default-information-originate” and that it is used on the ABR of the NSSA to force it to break the above behavior, and inject a default route into the NSSA.

Well, this command is to be used as well on the ASBRs that want to inject a default route, although it has a slightly changed behavior:

  1. When issued on an ABR, the ABR automatically injects a T7 LSA into the NSSA with a default route, without the need of actually having a default route into the routing table. One thing to keep in mind is that in the T7 LSA containing the default route, the P(propagate) bit is NOT set, meaning that no other ABR of that NSSA is allowed to translate the T7 LSA into a T5!

Let’s see this on ABR3:

  • It has no default route in the RIB

ABR3(config)#do sh ip ro 0.0.0.0
% Network not in table

  • We configure it to inject the default route:

ABR3(config-router)#area 3 nssa default-information-originate

  • Database output:

ABR3#sh ip ospf database nssa-external

OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-7 AS External Link States (Area 3)
 LS age: 420
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0xB2F2
  Length: 36
  Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 1
    Forward Address: 0.0.0.0
     External Route Tag: 0

2. When issued on an ASBR in an NSSA, the ASBR needs to have the default route in the routing table for it to be redistributed

To prove that:

  • Shutdown the link on ASBR3 to ISP2 à make sure the default route is not received:

ASBR3#sh ip ro 0.0.0.0
% Network not in table

  • ASBR3 configuration

 ASBR3(config-router)#do sh run | s r o
router ospf 1
 area 3 nssa default-information-originate
 redistribute bgp 200 subnets

  • ASBR3 isn’t injecting anything into OSPF

ASBR3(config-router)#do sh ip ospf data nssa-external
             OSPF Router with ID (33.33.33.33) (Process ID 1)

  • Unshut the link to get the default route:

ASBR3#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via “bgp 200”, distance 20, metric 0, candidate default path
  Tag 100, type external
  Redistributing via ospf 1
  Last update from 200.200.200.2 00:00:00 ago
  Routing Descriptor Blocks:
  * 200.200.200.2, from 200.200.200.2, 00:00:00 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 100
      MPLS label: none

  • Verify that it is advertised into OSPF

ASBR3#sh ip ospf database nssa-external

OSPF Router with ID (33.33.33.33) (Process ID 1)
Type-7 AS External Link States (Area 3)
LS age: 37
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 33.33.33.33
  LS Seq Number: 80000001
  Checksum: 0x18B6
  Length: 36
  Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 1
    Forward Address: 10.10.33.33
    External Route Tag: 0

Let’s now issue the same command on ASBR4/ABR4 and make it inject the default route as well:

ABR4_ASBR4#sh ip ospf data nssa-external self-originate

OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-7 AS External Link States (Area 3)
LS age: 68
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000001
  Checksum: 0x940D
  Length: 36
  Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 1
    Forward Address: 0.0.0.0
     External Route Tag: 0

Striking facts:

  • ASBR3 sets the FA, while ASBR4/ABR4 does not set the FA.
  • No ABR translates the T7 LSA that contains the default route into a T5 LSA, even though the P-bit is set in ASBR3’s T7 LSA.

Striking fact no. 1 explained:

  • ASBR3 is an NSSA ASBR, injecting a T7 LSA into the NSSA area. This LSA has the P-bit set so as per the RFC, the following applies:

“6. Those Type-7 LSAs that are to be translated into Type-5 LSAs must have their forwarding address set.” (RFC 3101-Section 2.3)

So that is why the FA is set in ASBR3’s LSA. When the T7 LSA is translated into a T5 one, the FA is copied and maintained throughout the entire domain. ASBR/ABR4 does not set the FA as the P bit is not set in its T7 LSA.

Striking fact no. 2 explained:

Why doesn’t the T7 LSA get translated? Well, going back to the RFC, this states:

“Only installed Type-7 LSAs and those non-default Type-7 LSAs originated by the router itself should be examined.  Locally sourced Type-7 LSAs should be processed first.” (RFC3101-Section 3.2)

So default T7 LSAs are not translated to begin with. But we need it right, because it’s our default route from the ISP.

We can do it but there here’s still a catch. If we force ABR4_ASBR4 to translate the T7 LSA, it won’t, because the LSA it generated cannot be translated (no P-bit set). So we need to force ABR3 to do it:

ABR3(config-router)#area 3 nssa translate type7 always

The database now contains the T5 LSA

ABR3#sh ip ospf data external
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
LS age: 596
Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0xACC2
  Length: 36
  Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 1
    Forward Address: 10.10.3.33
       External Route Tag: 0

And everyone has the default route:

R1#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via “ospf 1”, distance 110, metric 1, candidate default path, type extern 2, forward metric 2
  Last update from 10.10.13.3 on FastEthernet0/0, 00:10:44 ago
  Routing Descriptor Blocks:
  * 10.10.13.3, from 3.3.3.3, 00:10:44 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1

 

Second problem: OSPF best path algorithm at its best

Let’s say that our datacenter contains both private servers and public ones. Not going too deep into this, the firewall has 3 zones, inside (internal corporate network), outside (internet connection) and DMZ (pub servers). So we have the connection to ASBR4/ABR4 that takes us to the Internet directly, in Area 4.

ASBR1 receives the T5 LSA translated by ABR3 via area 1 which is a normal area. As area 4 is an NSSA one, ABR4 will need to inject the default route as well.

So now, on ASBR1 we have 2 LSAs with the default route

–>  Type 7, N2. no P bit, no FA, from ASBR/ABR4
–>  Type 5, E2, FA set, from ABR3

Who wins?

ASBR1#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via “ospf 1”, distance 110, metric 1, candidate default path, type NSSA extern 2, forward metric 1
  Last update from 10.10.111.4 on GigabitEthernet3/0, 00:11:06 ago
  Routing Descriptor Blocks:
  * 10.10.111.4, from 4.4.4.4, 00:11:06 ago, via GigabitEthernet3/0
      Route metric is 1, traffic share count is 1

N2 wins over E2 but why?

According to RFC3101, ASBR1 needs to compute the cost to the FA in the T7/T5 LSA. If no FA is set, compare the cost to the ABR.

“The LSA type of two AS-external-LSAs plays no role in determining path preference except when the LSAs are functionally the same (i.e., same destination, cost and non-zero forwarding address).”(Appendix F-Section 2)

In our case we have:

  • T7 LSA has no FA à we need cost to ABR4

ASBR1#sh ip ospf data nssa-external | include Forward
Forward Address: 0.0.0.0

  • T5 LSA has FA (the FA of the T7 LSA ASBR3 generated) à need cost to FA

ASBR1#sh ip ospf data external | include Forward
Forward Address: 10.10.3.33

  • Cost to ABR4

ASBR1#sh ip ospf border-routers | in 4.4.4.4
i 4.4.4.4 [1] via 10.10.111.4, GigabitEthernet3/0, ABR/ASBR, Area 4, SPF 10

  • Cost to FA 10.10.3.33

ASBR1#sh ip ro 10.10.3.33
Routing entry for 10.10.3.0/24
Known via “ospf 1”, distance 110, metric 3, type inter area
Last update from 10.10.111.4 on GigabitEthernet3/0, 00:07:41 ago
Routing Descriptor Blocks:
* 10.10.111.4, from 4.4.4.4, 00:07:41 ago, via GigabitEthernet3/0
Route metric is 3, traffic share count is 1

If you don’t trust me, you can change the cost towards ABR4 to a value bigger that 3, and you’ll see that the E2 route will then win J
Let’s now see what happens if we get the two LSAs to be the same in the RFC sense. We’re going to suppress the FA in the translated T5 LSA:

ABR3(config-router)#area 3 nssa translate type7 always suppress-fa

And make the costs to the two ABRs (ABR3 and ABR4) the same:

ASBR1#sh ip ospf border-routers
i 4.4.4.4 [1] via 10.10.111.4, GigabitEthernet3/0, ABR/ASBR, Area 4, SPF 10
I 3.3.3.3 [3] via 10.10.1.1, FastEthernet0/0, ASBR, Area 1, SPF 7

ASBR1(config)#int gi3/0
ASBR1(config-if)#ip ospf cost 3

And now E2 wins, as per the well known order you know: O, IA, E1, E2, N1, N2 🙂

 

 

Cheers!

Facebook Comments
Rating

Leave a Reply