![LS age: 910
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 3.3.3.0 (External Network Number )
Advertising Router: 0.0.0.2
LS Seq Number: 80000001
Checksum: 0x97E3
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
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-if)#router ospf 1
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
OSPF Router with ID (0.0.0.1) (Process ID 1)
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](https://image.slidesharecdn.com/nssaexternalroutedemystifiedwithrfc3101-170623003409/85/NSSA-external-route-with-Forwarding-Address-demystified-with-RFC-3101-3-320.jpg)
![R1#
Now let's reconfigure area 23 as NSSA:
R2(config-if)#router ospf 1
R2(config-router)#area 23 nssa
R3(config-if)#router ospf 1
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
OSPF Router with ID (0.0.0.1) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
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:
R1#sh ip route 3.3.3.0
Routing entry for 3.3.3.0/24](https://image.slidesharecdn.com/nssaexternalroutedemystifiedwithrfc3101-170623003409/85/NSSA-external-route-with-Forwarding-Address-demystified-with-RFC-3101-4-320.jpg)
![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#sh ip route 3.3.3.0
Routing entry for 3.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
Last update from 12.0.0.2 on FastEthernet0/0, 00:01:55 ago
Routing Descriptor Blocks:
* 12.0.0.2, from 0.0.0.2, 00:01:55 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
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
OSPF Router with ID (0.0.0.1) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
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](https://image.slidesharecdn.com/nssaexternalroutedemystifiedwithrfc3101-170623003409/85/NSSA-external-route-with-Forwarding-Address-demystified-with-RFC-3101-7-320.jpg)
NSSA external route with Forwarding Address demystified with RFC 3101
- 1. 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: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 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 ! interface FastEthernet0/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.
- 2. 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0
- 3. LS age: 910 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x97E3 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 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-if)#router ospf 1 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 OSPF Router with ID (0.0.0.1) (Process ID 1) 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
- 4. R1# Now let's reconfigure area 23 as NSSA: R2(config-if)#router ospf 1 R2(config-router)#area 23 nssa R3(config-if)#router ospf 1 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route 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: R1#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24
- 5. 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: R1#sh ip route 3.3.3.0 % 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States LS age: 1215 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x95E4 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 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: R1#sh ip route 23.0.0.0
- 6. % 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 2 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x6F26 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0
- 7. 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#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 12.0.0.2 on FastEthernet0/0, 00:01:55 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:01:55 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route 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
- 8. 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 OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 186 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0x6B28 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 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#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 12.0.0.2 on FastEthernet0/0, 00:07:14 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:07:14 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 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.
- 9. 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.