NSSA external route with Forwarding Address demystified with RFC 3101

NSSA external route demystified with RFC 3101
Basic Configuration of all routers:
R1:
interface FastEthernet0/0
ip address 12.0.0.1 255.255.255.0
ip ospf 1 area 0
no sh
!
router ospf 1
router-id 0.0.0.1
R2:
ip address 12.0.0.2 255.255.255.0
ip ospf 1 area 0
no sh
!
ip address 23.0.0.2 255.255.255.0
ip ospf 1 area 23
no shu
!
router ospf 1
router-id 0.0.0.2
area 23 nssa
R3:
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
ip address 23.0.0.3 255.255.255.0
ip ospf 1 area 23
no sh
!
router ospf 1
router-id 0.0.0.3
area 23 nssa
redistribute connected subnets route-map CONNECTED
!
route-map CONNECTED permit 10
match interface Loopback0
Area 23 is configured as NSSA.
R3 redistrbutes the prefix 3.3.3.0/24 into OSPF domain.

R2 receives a Type-7 LSA from R3 as shown below:
R2#sh ip os data nssa
OSPF Router with ID (0.0.0.2) (Process ID 1)
Type-7 AS External Link States (Area 23)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 3
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 3.3.3.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xFC73
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 23.0.0.3
External Route Tag: 0
R2#
The Forward Address is 23.0.0.3, per RFC 3101 section 2.4 Originating Type-7 LSAs, when an
NSSA ASBR originates a Type-7 LSA, the NON-ZERO forwarding address is mandatory and the
Forward Address must be set.
2.4 Originating Type-7 LSAs
NSSA AS boundary routers may only originate Type-7 LSAs into NSSAs.
An NSSA internal AS boundary router must set the P-bit in the LSA
header's option field of any Type-7 LSA whose network it wants
advertised into the OSPF domain's full transit topology. The LSAs of
these networks must have a valid non-zero forwarding address. If the
P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA
border routers.
The P-bit in the Type-7 LSA is set so R2 is allowed to translate this LSA into a Type-7 LSA,
let's verify the LSDB of R2, we can see below that the Type-7 LSA is translated into a Type-5
LSA and the Forward Address is copied as shown bythe RFC 3101.
Per RFC 3101 section 2.3 Type-7 LSAs
Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7
LSAs' non-zero forwarding addresses.
R1 should receive the Type-5 LSA's R2 as shown below:
R1#sh ip os data ex
Type-5 AS External Link States

LS age: 910
Options: (No TOS-capability, DC, Upward)
Checksum: 0x97E3
Length: 36
Network Mask: /24
MTID: 0
Metric: 20
R1#
Since the Forward Address is non-zero 23.0.0.3 in the Type-5 LSA, R1 look up the best inter-
area route toward 23.0.0.3, and it will use this path to reach the external prefix 3.3.3.0/24. As
per RFC 3101 section 2.5:
2.5 Calculating Type-7 AS External Routes
If the forwarding address is non-zero look up the forwarding
address in the routing table. For a Type-5 LSA the matching
routing table entry must specify an intra-area or inter-area
path through a Type-5 capable area. For a Type-7 LSA the
matching routing table entry must specify an intra-area path
through the LSA's originating NSSA.
Now why the Forward Address must be set in the Type-7 LSA and must copied into the Type-5
LSA when an NSSA ABR performs a translation ?
In a regular areas, any internal router can see an ASBR in another area through a Type-4 LSA,
to verify, let's remove the area 23 nssa command on R2 and R3:
R2(config-if)#router ospf 1
R2(config-router)#no area 23 nssa
R3(config-router)#no area 23 nssa
Let's verify on R1, the show ip os border command shown that R1 sees the ASBR R3 0.0.0.3
located in area 23 through R2 12.0.0.2, R1 knows than it need to go through an Inter-area route
(or a Type-4 LSA) to reach it.
R1#sh ip os border-routers
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
I 0.0.0.3 [2] via 12.0.0.2, FastEthernet0/0, ASBR, Area 0, SPF 3
i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3

R1#
Now let's reconfigure area 23 as NSSA:
R2(config-router)#area 23 nssa
R3(config-router)#area 23 nssa
Let's verify with the show ip os border command:
We can see below that the NSSA ASBR R3 0.0.0.3 is no longer present in the routers table,
instead it sees only R2 as an ABR and as a pseudo ASBR (because it origintes a Type-5 LSA).
R1#sh ip os border-routers
i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR/ASBR, Area 0, SPF 4
R1#
Since the router R1 does not have the visibility about the ASBR R3 in the NSSA AREA 23,
without the Forward Address 23.0.0.3, R1 loses any informations about the NSSA ASBR, the
Forward Address 23.0.0.3 helps R1 to have a visibility of the ASBR R3 undirectly because
23.0.0.3 belongs to R3. In a scenario where there are multiple NSSA ABRs, the absence of the
Forward Address can cause a suboptimal routing. This is why the RFC 3101 states that the
Forward Address is mandatory in order to perform efficient routing as shown in the section 2.3
Type-7 LSAs
Per RFC 3101 section 2.3 Type-7 LSAs
Non-zero forwarding addresses produce
efficient inter-area routing to an NSSA's AS external destinations
when it has multiple border routers. Also the non-zero forwarding
addresses of Type-7 LSAs ease the process of their translation into
Type-5 LSAs, as NSSA border routers are not required to compute them.
So since the Forward Address 23.0.0.3 is set in the Type-5 LSA, according to RFC 3101 section
2.5 Calculating Type-7 AS External Routes, R1 look up the best inter-area route to reach
23.0.0.3 in its routing table, let's verify:
R1#sh ip route 23.0.0.0
Routing entry for 23.0.0.0/24, 1 known subnets
O IA 23.0.0.0 [110/2] via 12.0.0.2, 01:08:34, FastEthernet0/0
R1#
R1 has a valid inter-area route toward 23.0.0.0/24 through R2 with a cost 2, and it installs the
external route to 3.3.3.0/24 successfully in its routing table:
Routing entry for 3.3.3.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 12.0.0.2 on FastEthernet0/0, 00:38:46 ago
Routing Descriptor Blocks:
* 12.0.0.2, from 0.0.0.2, 00:38:46 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
R1#
Now the challenge is: configure R2 to filter all inter-area routes coming from area 23 using the
filter-list.
First we need to identity all the inter-area routes using a prefix-list and associate the prefix-lis
with filter-list:
R2(config)#ip prefix-list TEST seq 5 deny 0.0.0.0/0 le 32
R2(config)#router os 1
R2(config-router)# area 23 filter-list prefix TEST out
Let's verify the routing table for 3.3.3.0/24.
The external route is no longer present in the routing table:
% Network not in table
R1#
Let's verify the LSDB of R1, the Type-5 LSA is still there:
R1#sh ip os data ex
LS age: 1215
Checksum: 0x95E4
Length: 36
Network Mask: /24
MTID: 0
Metric: 20
R1#
The external route to 3.3.3.0/24 is not present in the routing table even if the Type-5 LSA is still
in the LSDB, why ?
Let's verify the entry for 23.0.0.0/24:
The inter-area route to 23.0.0.0/24 is no longer present in the routing table because the Type-3
LSA filtering done previously with filter list:

% Network not in table
R1#
The reason why the external route is not present in the routing table is that the Forward
Address is unreachable, R1 does not have any inter-area route to reach the Forward Address
23.0.0.3, and therefore it does not install the external route to 3.3.3.0/24.
Keep in mind that if the forwarding addresses is filtered out of Area 23, R1 located in area 0
cannot reach the prefix 3.3.3.0/24 advertised in the translated Type-5 LSAs.
To solve this problem, we should suppress the forwarding address on the ABR so that the
forwarding address is set to 0.0.0.0 in the translated Type-5 LSAs. A forwarding address set to
0.0.0.0 indicates that packets for the external destination should be forwarded to the
advertising OSPF router, in this case, the translating NSSA ABR R2.
The OSPF Forwarding Address Suppression in Translated Type-5 LSAs feature using the area
23 nssa translate type7 suppress-fa command causes the NSSA ABR R2 to translate Type-7
LSA to Type-5 LSAs, but to use the address 0.0.0.0 for the forwarding address instead of that
specified in the Type-7 LSA. This feature causes R1 to direct forwarded traffic toward
3.3.3.0/24 to the translating NSSA ABR R2.
But as specified in RFC 3101 section 2.3 Type-7 LSAs, the Forward Address produce efficient
routing and avoid suboptimal route, so suppressing the Forward Address should be used
carefully.
Cisco says: Configuring this feature causes the router to be noncompliant with RFC 1587.
Also, suboptimal routing might result because there might be better paths to reach the
destination’s forwarding address. This feature should not be configured without careful
consideration and not until the network topology is understood.
Let's suppress the FA:
R2(config)#router osp 1
R2(config-router)#area 23 nssa translate type7 suppress-fa
Let's verify the Type-5 LSA originated by R2, the Forward Address now is 0.0.0.0:
R1#sh ip os data ext
LS age: 2
Checksum: 0x6F26
Length: 36
Network Mask: /24
MTID: 0
Metric: 20

R1#
The Forward Address 0.0.0.0 means that to reach the the external prefix 3.3.3.0/24, R1 will
redirect the traffic to the Type-5 LSA's originator, let's verify the routing table of R1, the
external route to 3.3.3.0/24 is installed successfully and the forward metric represents the cost
to reach the NSSA ABR'translator R2:
R1#
To confirm, let's display the show ip os bor output, the NSSA ABR R2 is reachable with a cost
1, this is the forward metric displayed in the show ip route 3.3.3.0 command:
R1#sh ip os bord
i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR/ASBR, Area 0, SPF 2
R1#
Remove the previously command and use another method to suppress the FA in order to
solve the problem.
R2(config)#router osp 1
R2(config-router)#no area 23 nssa translate type7 suppress-fa
The second method to suppress the Forward Address is to aggregate the Type-7 LSA prefixes
on the NSSA ABR R2 using the summary-address command, keep in mind that this command
should be executed on the ASBR, and R2 is a pseudo ASBR since it is originating a Type-5
LSA, this causes R2 to generate a Type-5 LSA for the summary prefix with a Forward Address
0.0.0.0.
Per RFC 3101 , the sections Type-7 LSAs and Translating Type-7 LSAs into Type-5 LSAs
explain that the FA is set to 0.0.0.0 in the translated Type-5 LSA when performing
summarization on the NSSA ABR for the Type-7 LSAs.
2.3 Type-7 LSAs
Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7
LSAs' non-zero forwarding addresses. Only those Type-5 LSAs that are
aggregations of Type-7 LSAs may have 0.0.0.0 as a forwarding address.
(See Section 3.2 for details.)
3.2 Translating Type-7 LSAs into Type-5 LSAs
The newly generated Type-5 LSA will have a link-state ID equal

to the Type-7 address range's address (in the case of multiple
originations of Type-5 LSAs with the same network address but
different mask, the link-state ID can also have one or more of
the range's "host" bits set). The advertising router field
will be the router ID of this area border router. The network
mask and the external route tag are set to the range's
configured values. The forwarding address is set to 0.0.0.0.
The path type and metric are set to the range's path type and
metric as defined and computed above.
Let's configure the summary-address 3.3.3.0 255.255.255.0 command on R2:
R2(config-router)#router osp 1
R2(config-router)#summary-address 3.3.3.0 255.255.255.0
Let's verify the Type-5 LSA originated by R2, the Forward Address is set to 0.0.0.0:
R1#sh ip os data ext
LS age: 186
Checksum: 0x6B28
Length: 36
Network Mask: /24
MTID: 0
Metric: 20
R1#
Let's verify the routing table of R1, now the external route is installed successfully, R1 looks
the best path to reach the NSSA ABR translator, the traffic should be forwarded to the
advertising OSPF router, in this case, the translating NSSA ABR R2.
R1#
Using the summary-address 3.3.3.0 255.255.255.0 command on the NSSA ABR has the same
effect with the area 23 nssa translate type7 suppress-fa command, it sets the Forward Address
to 0.0.0.0.

When we perform a summarization of external prefixes on an NSSA ABR (which is a pseudo
ASBR), the NSSA ABR must clear the FA, the FA is not copied from Type-7 LSA into Type-5
LSA. As explained in RFC 3101, it seems logic, since it is the router which performs the
summarization, it should tell to other router (R1 in this case), to reach the external route, send
the traffic to me.

NSSA external route with Forwarding Address demystified with RFC 3101

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to NSSA external route with Forwarding Address demystified with RFC 3101

Similar to NSSA external route with Forwarding Address demystified with RFC 3101 (20)

Recently uploaded

Recently uploaded (20)

NSSA external route with Forwarding Address demystified with RFC 3101