'IGP Routing'

OSPF NSSA Forward Address Selection Process

Now I don’t know about you guys, but it’s the little things that bother me at times.
Well the big things bother me more, but let’s move on :)

Consider the following topology:

In the topology above, area 1 is an NSSA area, with R2 & R4 NSSA ABRs.
R1 F1/0 & R1 F1/1 are in Area 0.
R2 F1/0 & F1/1 are in Area 0.
R4 F1/1 & F1/0 are in Area 0.

R2 F2/0 is in Area 1.
R3 F1/0 & F1/1 are in Area 1.
R4 F2/0 is in Area 1.

For the purposes of this test, I have created a loopback ip on R3 with IP: 30.30.30.30 & have redistributed it into OSPF 100 as follows:
  • Loopback1              30.30.30.30     YES manual up                    up
  • router ospf 100
    router-id 3.3.3.3
    area 1 nssa
    redistribute connected subnets
Now, the redistribute command above turns R3 into an NSSA ASBR.
NSSA ASBRs generate Type 7 LSAs, so lets check the forward address of the Type 7 LSA for 30.30.30.30:
  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 10.1.34.3
Observe above that the forward address is set to 10.1.34.3.
This goes against the concept of forward address for External LSAs, which is, if OSPF is not running on the interface that receives the external route then forward address = 0.0.0.0.
In the case of R3, the loopback address 30.30.30.30 is NOT running OSPF:
  • R3#sh ip o int b
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    Fa1/1        100   1               10.1.34.3/24       1     BDR   1/1
    Fa1/0        100   1               10.1.23.3/24       1     DR    1/1

So its clear that something is going on here… :)

RFC 3101 (The OSPF Not-So-Stubby Area (NSSA) Option) states:

  • If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires the P-bit be set and a non-zero forwarding address is unavailable, then the route’s Type-7 LSA is not originated into this NSSA. When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router’s internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router’s active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network’s address is used. When the interface whose IP address is the LSA’s forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re-originate it. If one is not available the LSA should be flushed.

Now by default whenever an NSSA ASBR originates a Type 7 NSSA External LSA, it sets the P-bit (propagate-bit) to 1, to indicate that the NSSA ABR receiving this Type 7 LSA should perform a 7-5 translation & advertise a Type 5 LSA for the external into the backbone.
So…as R3 sets the P-bit to 1 by default, this means R3 MUST set the forward address to a non zero value.
Question is, WHAT IP is R3 to choose?!
Well from the RFC & some testing, the order goes:

  1. Highest Loopback IP on the NSSA ASBR (that is running OSPF, and is in the NSSA area)
  2. Else, Highest Non Loopback IP on the NSSA ASBR (that is running OSPF, and is in the NSSA area)

To prove the above, lets check what the current forward address is again:

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 10.1.34.3

Checking the active interfaces in the NSSA area, we see that 10.1.34.3 is indeed the highest IP currently:

  • R3#sh ip o int b
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    Fa1/1        100   1               10.1.34.3/24       1     BDR   1/1
    Fa1/0        100   1               10.1.23.3/24       1     DR    1/1

Lets add a Loopback IP into the mix and add it to the NSSA area 1:

  • R3(config)#int lo100
    R3(config-if)#ip add 100.100.100.100 255.255.255.255
    R3(config-if)#router ospf 100
    R3(config-router)#net 100.100.100.100 0.0.0.0 area 1

Now lets check whether the forward address has changed:

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 100.100.100.100

Yep, as expected :)
Let’s remove the network statement for 100.100.100.100 & see what happens.

  • R3(config)#router ospf 100
    R3(config-router)#no net 100.100.100.100 0.0.0.0 area 1

R3#sh ip o d nssa-external 30.30.30.30 | i Forward
Forward Address: 10.1.34.3

OK, so this proves that even if the IP address of an interface is higher than the IP of the current forward address, that IP must be in the NSSA area.

Adding 100.100.100.100/32 back to NSSA 1:

  • R3(config)#router ospf 100
    R3(config-router)#net 100.100.100.100 0.0.0.0 area 1


100.100.100.100 is back as the forward address:

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 100.100.100.100

Now lets create another loopback interface & add it to area 1:

  • R3(config)#int lo200
    R3(config-if)#ip add 200.200.200.200 255.255.255.255
    R3(config-if)#router ospf 100
    R3(config-router)#net 200.200.200.200 0.0.0.0 area 1

Any change to the forward address? Yep as expected

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 200.200.200.200

One LASt thing…in the above cases we used loopback ips that were HIGHER than 10.1.34.3.
What if we add a loopback ip that is smaller then 10.1.34.3?

Removed the network statements for the above loopbacks so that 10.1.34.3 is once more the forward address:

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 10.1.34.3

Ok, cool, NOW lets add a loopback ip 3.1.1.1:

  • R3(config)#int lo2
    R3(config-if)#ip add 3.1.1.1 255.255.255.255
    R3(config)#router ospf 100
    R3(config-router)#net 3.1.1.1 0.0.0.0 area 1

What do we see?

  • R3#sh ip o d nssa-external 30.30.30.30 | i Forward
    Forward Address: 3.1.1.1

Yep the SMALLER ip, even though its a loopback, wins! :)

So to reiterate the rules its:

  • Highest loopback IP in the NSSA area
  • If no loopback interface in NSSA area, choose highest physical interface IP in the NSSA area

Finally a few more things to be aware of.

Note above in our topology diagram that we have TWO NSSA ABRs, R2 & R4.

Question is, as R2 & R4 will BOTH receive the Type 7 LSA for Link State ID 30.30.30.30, do BOTH routers translate the Type 7 into a Type 5 or just one of the ABRs. If one ABR is responsible, then which ABR is reponsible for injecting the Type 5 LSA for 30.30.30.30 into the normal areas?

Well the rule is:

The Type 7 LSA has a bit (called Bit P, P = Propagate) which is used in order to tell the NSSA ABR whether to translate type 7 into type 5:

  • No Type 7/5 translation means bit P = 0
  • Type 7/5 translation means bit P = 1
  • If there are multiple NSSA ABRs with bit P = 1, then the router with the HIGHEST Router-ID ONLY is responsible for translating the Type 7 into Type 5.
If we go onto R1 and check the external LSA for 30.30.30.30 we can see this rule in effect:
  • R1#sh ip o d ext 30.30.30.30

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

    Type-5 AS External Link States

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

As can be seen above, the advertising router that created the Type 5 is 4.4.4.4 (the Router ID of R4) which has a higher router id than 2.2.2.2 (the Router ID of R2).
And that is that :)

Understanding the OSPF RID selection process

The motivation to create this article was based on CCIE Pursuit’s Q of the Day 8 Dec
Thank you ccie pursuit :)

That question asked what interface would be the OSPF RID after configuring OSPF after the interfaces were in the following state:

  • R0(config)#do sh ip int b | e  una
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet1/0            155.1.146.1     YES manual up                    up
    Serial2/0                  155.1.13.1      YES manual up                    up
    Loopback0                  150.1.1.1       YES manual administratively down down

Now as a loopback interface is configured we automatically think that the loopback interface would be the OSPF RID, however note above that it is administratively shut.

The Rules regarding OSPF RID choice are as follows:

  • If OSPF RID is manually configured, use that
  • Else, choose the highest loopback interface that is in an up/up state at the time ospf process is started
  • Else, choose the highest physical interface thats in an up/up state at the time ospf process is started

Lets test the above rules.

Test 1: Manual OSPF RID

1st let’s test the OSPF RID, with the following interface state scenario:

  • R0#sh ip int b | e una
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet1/0            155.1.146.1     YES manual up                    up
    Serial2/0                  155.1.13.1      YES manual up                    up
    Loopback0                  150.1.1.1       YES manual up                    up

Now, let’s configure OSPF including manually setting the OSPF RID:

  • R0(config)#router ospf 100
    R0(config-router)#net 155.1.13.1 0.0.0.0 area 0
    R0(config-router)#router-id 1.1.1.1

Now let’s check who the OSPF RID is:

  • R0(config-router)#do sh ip ospf | i ID
    Routing Process “ospf 100″ with ID 1.1.1.1

As expected OSPF RID is the manually set 1.1.1.1

An interesting thing to note however, is that we can change the OSPF manual RID on the fly without restarting the OSPF process. <=== NB, if we have OSPF adjacencies established (which we don’t have here), and we try to change the OSPF RID manually, IOS will prompt us to either reload or do a clear ip ospf process in order for the new ospf rid to take effect.

  • R0(config-router)#router-id 2.2.2.2
    R0(config-router)#do sh ip ospf | i ID
    Routing Process “ospf 100″ with ID 2.2.2.2

Test 2: Highest ACTIVE Loopback interface as OSPF RID (OSPF RID not manually set)

For this test let’s use the following interface state scenario:

  • R0#sh ip int b | e una
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet1/0            155.1.146.1     YES manual up                    up
    Serial2/0                  155.1.13.1      YES manual up                    up
    Loopback0                  150.1.1.1       YES manual up                    up
    Loopback1                  150.2.2.2       YES manual up                    up

OSPF is not currently running on this router.
Let’s admin shut Loopback1 (the highest loopback):

  • R0(config)#int l1
    R0(config-if)#sh
    *Jan  4 15:16:15.199: %LINK-5-CHANGED: Interface Loopback1, changed state to administratively down
    *Jan  4 15:16:16.199: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to down
    R0(config-if)#do sh ip int b | e una
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet1/0            155.1.146.1     YES manual up                    up
    Serial2/0                  155.1.13.1      YES manual up                    up
    Loopback0                  150.1.1.1       YES manual up                    up
    Loopback1                  150.2.2.2       YES manual administratively down down

NOW lets configure OSPF:

  • R0#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    R0(config)#router ospf 100
    R0(config-router)#net 155.1.13.1 0.0.0.0 area 0

Lets check who the OSPF RID is:

  • R0(config-router)#do sh ip o | i ID
    Routing Process “ospf 100″ with ID 150.1.1.1

Observe that Loopback0, as the highest loopback interface, at the time the OSPF process started, is the OSPF RID, in the absense of a manually configured OSPF RID.

Test 3: Highest ACTIVE Physical Interface (Loopback ints down/down, no OSPF RID manually set)

For this test let’s use the following interface state scenario:

  • R0#sh ip int b | e una
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet1/0            155.1.146.1     YES manual up                    up
    Serial2/0                  155.1.13.1      YES manual up                    up
    Loopback0                  150.1.1.1       YES manual administratively down down
    Loopback1                  150.2.2.2       YES manual administratively down down

Now let’s configure OSPF:

  • R0(config)#router ospf 100
    R0(config-router)#net 155.1.13.1 0.0.0.0 area 0

Lets check who the OSPF RID is:

  • R0(config)#do sh ip o | i ID
    Routing Process “ospf 100″ with ID 155.1.146.1

This was to be expected…with no active loopback interface, and no ospf rid manually set, OSPF chooses the highest ip from its ACTIVE physical interfaces, i.e 155.1.146.1.

And that’s that :)