Tuesday 1 March 2016

OSPF NSSA Translator Election & Forwarding Address






OSPF NSSA Translator Election & Forwarding Address



https://ccieblog.co.uk/wp-content/uploads/2015/07/OSPF-Forwarding-Address-With-An-NSSA-Two-ABRs.png


In this section I will look at who does the NSSA type 7 to 5 translation & how we can use the forwarding address to control routing towards external routes that have been brought into the OSPF domain via an NSSA. The topology we will use is below. Currently R4 is redistributing the 99.0.0.1/24 prefix into OSPF and all routers have reachability to it.

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, R1 performs a lookup on the Type-5 LSA for 99.0.0.1  that was translated from a Type-7 LSA. At this point R3 has an OSPF Router-ID of 3.3.3.3, and R2 has 2.2.2.2 . The advertising router R3 sees is 3.3.3.3 (R3), since R3 won the translator election due to the higher RID. Note however, the forward address is set to 4.4.4.4. This means that R1 next needs to figure out how to route towards 4.4.4.4.


In a network like above, only one ABR router connected to the NSSA is elected to do the LSA type 7 to 5 translation for the EIGRP route 99.0.0.0/24. The decision is based on who has the highest router-id. So if we look at the OSPF database for this external prefix on R1, we should see that the advertising router is R3 (3.3.3.3) because his router-id is higher than R2 (2.2.2.2) and therefore did the translation.


R1# sh ip ospf database external 99.0.0.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 76
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 99.0.0.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x6D63
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 100
        Forward Address: 4.4.4.4
        External Route Tag: 0

R1#


the output confirms that R3 (3.3.3.3) has done the type 7 to 5 translation. So if we were to make R2’s RID higher than 3.3.3.3, then R2 would be the router who does the type 7 to 5 translation. Let’s do that now.

R2(config-router)#router-id 255.0.0.2
Reload or use "clear ip ospf process" command, for this to take effect
R2(config-router)#do clear ip ospf process
Reset ALL OSPF processes? [no]: yes
 
Let’s check that same ospf database output on R1 to check if 

the advertising router has now changed. 



R1# sh ip ospf database external 99.0.0.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 16
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 99.0.0.0 (External Network Number )
  Advertising Router: 255.0.0.2
  LS Seq Number: 80000001
  Checksum: 0xBB1F
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 100
        Forward Address: 4.4.4.4
        External Route Tag: 0

R1#


R1#
R1#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 1 msec
    10.0.13.2 1 msec
    10.0.12.2 0 msec
  2 10.0.34.2 1 msec
    10.0.24.2 1 msec
    10.0.34.2 1 msec
R1#

And it has, R2 (255.0.0.2) is how the router who did the translation.
Let’s move on to talking about the forwarding address. In short, it’s just an IP address that should be used to solve the shortest path to an external prefix instead of solving the shortest path to the node who advertised the prefix. In the output above, R2 has told R1 to go via 10.0.34.4 to reach 99.0.0.0/24. So now it’s just a matter of checking R1’s best path to 10.0.34.4. And from the routing table we can see that we can reach it via R3.


R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 21, type inter area
  Last update from 10.0.12.2 on Ethernet0/1, 00:01:33 ago
  Routing Descriptor Blocks:
  * 10.0.13.2, from 3.3.3.3, 00:08:46 ago, via Ethernet0/2
      Route metric is 21, traffic share count is 1
    10.0.12.2, from 255.0.0.2, 00:01:33 ago, via Ethernet0/1
      Route metric is 21, traffic share count is 1
 
 R2(config)#router ospf 1
R2(config-router)#area 1 nssa translate type7 always suppress-fa
 
 

Note: 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.


R1#sh ip ospf database external 99.0.0.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 388
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 99.0.0.0 (External Network Number )
  Advertising Router: 255.0.0.2
  LS Seq Number: 80000002
  Checksum: 0xF0F8
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 100
        Forward Address: 0.0.0.0
        External Route Tag: 0

R1#

What I’ve done here is forced R2 to do the type7 to type 5 translation 
using the keywords “type7 always”. This is just to ensure that R3 could 
never do the the type 7 to 5 translation in the event R3 created a 
higher OSPF router-id than R2 (so technically we don’t really need this 
for this solution but it’s a good command to be aware of). I’ve also 
forced R2 to set the forward address to 0.0.0.0 using the “suppress-fa” 
command (and this is key to the solution). So let’s check this on R1’s 
ospf database.

R1#traceroute 99.0.0.1
Type escape sequence to abort.
Tracing the route to 99.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 0 msec 0 msec 5 msec
  2 10.0.24.2 1 msec 1 msec *
R1#
 
 
configurations
R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface Ethernet0/0
 no ip address
 shutdown
!
interface Ethernet0/1
 ip address 10.0.12.1 255.255.255.0
 ip ospf 1 area 0
!
interface Ethernet0/2
 ip address 10.0.13.1 255.255.255.0
 ip ospf 1 area 0
!

router ospf 1
 router-id 1.1.1.1
!



R2


interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface Loopback1
 ip address 21.21.21.21 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 1
!
!
interface Ethernet0/1
 ip address 10.0.12.2 255.255.255.0
 ip ospf 1 area 0

interface Ethernet0/2
 ip address 10.0.24.1 255.255.255.0
 ip ospf 1 area 1
!


router ospf 1
 router-id 255.0.0.2
 area 1 nssa
!
i
!
!
R3
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface Loopback31
 ip address 31.31.31.31 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 1
!
interface Ethernet0/0
 no ip address
 shutdown
!
interface Ethernet0/1
 ip address 10.0.13.2 255.255.255.0
 ip ospf 1 area 0
!
interface Ethernet0/2
 ip address 10.0.34.1 255.255.255.0
 ip ospf 1 area 1

!
router ospf 1
 router-id 3.3.3.3
 area 1 nssa
!

 
R4

interface Loopback0
 ip address 4.4.4.4 255.255.255.0
 ip ospf 1 area 1
!
interface Loopback1
 ip address 99.0.0.1 255.255.255.0
!
interface Ethernet0/0
 no ip address
 shutdown
!
interface Ethernet0/1
 ip address 10.0.24.2 255.255.255.0
 ip ospf 1 area 1
!
interface Ethernet0/2
 ip address 10.0.34.2 255.255.255.0
 ip ospf 1 area 1
!

router eigrp 1
 network 99.0.0.0 0.0.0.0
!
router ospf 1
 router-id 4.4.4.4
 area 1 nssa
 redistribute eigrp 1 metric 100 subnets