Basic configuration of all routers:
R1:
ipv uni
!
Interface Ethernet0/0
ipv6 address 21::1/64
ipv6 ospf 1 area 12
!
interface Serial 1/0
ipv6 address 12::1/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 0.0.0.1
R2:
ipv uni
!
Interface Ethernet0/0
ipv6 address 21::2/64
ipv6 ospf 1 area 12
!
interface Serial 1/0
ipv6 address 12::2/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 0.0.0.1
!
Interface Ethernet0/1
ipv6 address 23::2/64
ipv6 ospf 1 area 1
no shut
!
interface Ethernet0/2
ipv6 address 32::2/64
ipv6 ospf 1 area 2
no shut
!
ipv6 router ospf 1
router-id 0.0.0.2
R3:
ipv uni
!
Interface Ethernet0/1
ipv6 address 23::3/64
ipv6 ospf 1 area 1
no shut
!
interface Ethernet0/2
ipv6 address 32::3/64
ipv6 ospf 1 area 2
no shut
!
ipv6 router ospf 1
router-id 0.0.0.3
redistribute connected route-map TEST
!
route-map TEST permit 10
match interface Loopback0
R3 redistributes the external prefix 3::/64 into OSPF.
Let’s verify the LSDB of R1, we can see that it is receiving one Type-5 LSA from R3 0.0.0.3.
R1#sh ipv os data ex
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 182
LS Type: AS External Link
Link State ID: 0
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0x12A4
Length: 36
Prefix Address: 3::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
R1#
Since the Forward Address is not set in the Type-5 LSA, R1 lookup how to reach the ASBR and it needs a Type-4 LSA because R3 is located in another area, the ABR R2 will give this information, remember that Type-4 LSA has an area flooding scope, in this topology R2 is connected to R1 through two different areas, therefore R2 creates two Type-4 LSAs for areas 0 and 12 as shown below, because the loop-prevention mechanism of inter-area routes, the ABR R1 ignores the Type-4 LSA learned through area 12 the non-backbone area, ABR expects summary and ASB-summary LSAs from Area 0 only. This means there should be at least one adjacency in FULL state built over Area 0 interface. In case if ABR has such adjacency, it will ignore summary-LSAs received over non-backbone areas. These LSAs will be installed in the database, but not used for SPF calculations. This why you see the line “LSA ignored in SPF calculation” in the Type-4 LSA learned through area 12 as shown below.
R1#sh ipv os data inter router adv 0.0.0.2
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Inter Area Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 249
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Inter Area Router Links
Link State ID: 3
Advertising Router: 0.0.0.2
LS Seq Number: 80000001
Checksum: 0x39BB
Length: 32
Metric: 10
Destination Router ID: 0.0.0.3
Inter Area Router Link States (Area 12)
LSA ignored in SPF calculation
LS age: 249
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Inter Area Router Links
Link State ID: 3
Advertising Router: 0.0.0.2
LS Seq Number: 80000001
Checksum: 0x39BB
Length: 32
Metric: 10
Destination Router ID: 0.0.0.3
R1#
The total and best cost to reach the ASBR R3 can be displayed with the sh ipv os bord command, we can see that R1 considers the path through s1/0 as the best path to reach the ASBR R3 with a metric of 74.
R1#sh ipv os bor
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Codes: i - Intra-area route, I - Inter-area route
I 0.0.0.3 [74] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ASBR, Area 0, SPF 5
i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR, Area 12, SPF 2
i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR, Area 0, SPF 5
R1#
Verify the routing table, R1 installs the path through s1/0, this suboptimal routing is caused by the loop prevention mechanism of inter-area route.
R1#sh ipv route 3::
Routing entry for 3::/64
Known via "ospf 1", distance 110, metric 20, type extern 2
Route count is 1/1, share count 0
Routing paths:
FE80::A8BB:CCFF:FE00:2000, Serial1/0
Last updated 00:05:24 ago
R1#
The traceroute command confirms the result:
R1#tracer 3::3
Type escape sequence to abort.
Tracing the route to 3::3
1 12::2 9 msec 9 msec 8 msec
2 23::3 9 msec 8 msec 10 msec
R1#
This is what we call, the split-horizon mechanism. When an ABR learns a Type-3 LSA or Type-4 LSA through a non-backbone area, it ignores this LSA to prevent loop.
RFC 3509 explains OSPF ABR Behavior and split-horizon mechanism in the following section:
1.2 Motivation
In OSPF domains the area topology is restricted so that there must be
a backbone area (area 0) and all other areas must have either
physical or virtual connections to the backbone. The reason for this
star-like topology is that OSPF inter-area routing uses the
distance-vector approach and a strict area hierarchy permits
avoidance of the "counting to infinity" problem. OSPF prevents
inter-area routing loops by implementing a split-horizon mechanism,
allowing ABRs to inject into the backbone only Summary-LSAs derived
from the
intra-area routes, and limiting ABRs' SPF calculation to consider
only Summary-LSAs in the backbone area's link-state database.
The last restriction leads to a problem when an ABR has no backbone
connection (in OSPF, an ABR does not need to be attached to the
backbone).
To prevent the suboptimal routing and override the split-horizon rule, we need to block the Type-4 LSA so that the ABR R2 will not generate it for both area 12 and area 0, to do this configure areas 1 and 2 as NSSA:
R2(config)#ipv router os 1
R2(config-rtr)#area 1 nssa
R2(config-rtr)#area 2 nssa
R3(config)#ipv router os 1
R3(config-rtr)#area 1 nssa
R3(config-rtr)#area 2 nssa
Since areas 1 and 2 are configured as NSSA, R3 generates two Type-7 LSAs for areas 1 and 2 with the Forward Address 23::3 and 32::3 respectively, from the ABR R2’s perspective, to decide which Type-7 LSA, it uses the area id as the tie breaker, the largest area id will win, in this case the Type-7 LSA learned through area 2 is chosen to be translated rather than the Type-7 LSA learned through area 1, this rule is described in RFC 3101.
On R1 verify that it is receiving the Type-5 LSA with the Forward Address 32::3 from the NSSA translator R2.
R1#sh ipv os data ex
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 174
LS Type: AS External Link
Link State ID: 0
Advertising Router: 0.0.0.2
LS Seq Number: 80000001
Checksum: 0x90DF
Length: 52
Prefix Address: 3::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
Forward Address: 32::3
R1#
Verify the routing table of R1 for the prefix 3::/64, we can see that R1 is still using the slower path through the serial link to reach the external prefix.
R1#sh ipv route 3::
Routing entry for 3::/64
Known via "ospf 1", distance 110, metric 20, type extern 2
Route count is 1/1, share count 0
Routing paths:
FE80::A8BB:CCFF:FE00:2000, Serial1/0
Last updated 00:00:05 ago
R1#
The reason is the same one mentioned previously, R1 when it want to select the best path to reach the external prefix 3::/64, it will lookup the best inter-area route to reach the Forward Address 32::/64 listed in the Type-5 LSA, the routing table below shown that the inter-area route through the serial link is the best path to reach the Forward Address 32::3/64, because the inter-area loop prevention mechanism, the ABR R1 ignores the Type-3 LSA learned from the ABR R2 through area 12, a Type-3 LSA learned by an ABR through a non-backbone area is not considered in SPF calculation.
R1#sh ipv route os | beg App
lr - LISP site-registrations, ld - LISP dyn-eid, a - Application
OE2 3::/64 [110/20]
via FE80::A8BB:CCFF:FE00:2000, Serial1/0
OI 23::/64 [110/74]
via FE80::A8BB:CCFF:FE00:2000, Serial1/0
OI 32::/64 [110/74]
via FE80::A8BB:CCFF:FE00:2000, Serial1/0
R1#
To override this rule once again we should suppress the Forward Address, this causes the ABR NSSA R2 to translate Type-7 LSAs to Type-5 LSAs, but use the address 0.0.0.0 for the forwarding address instead of that specified in the Type-7 LSA. This causes R2 that are configured not to advertise forwarding addresses into area 0 and area 12 to direct forwarded traffic to the translating NSSA ABR R2:
R2(config-rtr)#ipv router os 1
R2(config-rtr)#area 2 nssa translate type7 suppress-fa
Verify the Type-5 LSA on R1, the Forward Address now is not set.
R1#sh ipv os data ex
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 6
LS Type: AS External Link
Link State ID: 0
Advertising Router: 0.0.0.2
LS Seq Number: 80000008
Checksum: 0xAA6
Length: 36
Prefix Address: 3::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
R1#
Since the FA is suppressed, R1 looks the best path to reach the NSSA ABR R2 which is also an ASBR.
There are two host intra-area routing entries for the same router-id "0.0.0.2" and with the cost 10 through area 12 and a cost 64 through area 0. the intra-area route through area 12 is better.
R1#sh ipv os bor
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Codes: i - Intra-area route, I - Inter-area route
i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR/ASBR, Area 12, SPF 3
i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR/ASBR, Area 0, SPF 6
R1#
Verify the routing table of R1, we can see that now it installs the path through area 12.
R1#sh ipv route 3::
Routing entry for 3::/64
Known via "ospf 1", distance 110, metric 20, type extern 2
Route count is 1/1, share count 0
Routing paths:
FE80::A8BB:CCFF:FE00:2000, Ethernet0/0
Last updated 00:01:21 ago
R1#
The trace route confirms the result.
R1#tracer 3::3
Type escape sequence to abort.
Tracing the route to 3::3
1 21::2 4 msec 1 msec 1 msec
2 32::3 1 msec 1 msec 1 msec
R1#
Verify the connectivity.
R1#ping 3::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms
R1#
Remove the area 2 nssa translate type7 suppress-fa command and use another solution to resolve the suboptimal routing issue.
The second method to suppress the Forward Address is to aggregate the Type-7 LSA prefixes on the NSSA ABR R2 using the summary-prefix 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 3::/64 without the Forward Address.
Per RFC 3101, the sections Type-7 LSAs and Translating Type-7 LSAs into Type-5 LSAs explain that the FA is set to zero in the translated Type-5 LSA when performing summarization on the NSSA ABR for the Type-7 LSAs.
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. 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.)
Section: 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.
So remove the area 2 nssa translate type7 suppress-fa command and configure the summary-prefix 3::/64 command.
R2(config-rtr)#no area 2 nssa translate type7 suppress-fa
R2(config-rtr)#summary-prefix 3::/64
Let’s verify the Type-5 LSA, the Forward Address is not set.
R1#sh ipv os data ex
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 6
LS Type: AS External Link
Link State ID: 0
Advertising Router: 0.0.0.2
LS Seq Number: 80000012
Checksum: 0xF5B0
Length: 36
Prefix Address: 3::
Prefix Length: 64, Options: None
Metric Type: 2 (Larger than any link state path)
Metric: 20
R1#
Let's verify the routing table of R1, now the external route to 3::/64 through area 12 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 through the best intra-area route.
R1#sh ipv route 3::
Routing entry for 3::/64
Known via "ospf 1", distance 110, metric 20, type extern 2
Route count is 1/1, share count 0
Routing paths:
FE80::A8BB:CCFF:FE00:2000, Ethernet0/0
Last updated 00:00:07 ago
R1#
Let’s verify the connectivity to 3::/64, the ping from R1 fails.
R1#ping 3::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:
XXXXX
Success rate is 0 percent (0/5)
R1#
It seems that the issue is the router R2, let’s verify the routing table of R2, WAW, R2 has no longer an NSSA external routes to 3::/64 in its routing tables, instead, it has a intra-area route via null0. And according to the OSPF path selection described by RFC 1583, an intra-area route is always preferred than an external route.
RFC 1583 section:
11.1. Routing table lookup
Reduce the set of matching entries to those having the most
preferential path-type (see Section 11). OSPF has a four
level hierarchy of paths. Intra-area paths are the most
preferred, followed in order by inter-area, type 1 external
and type 2 external paths.
R2#sh ipv rou osp | be App
lr - LISP site-registrations, ld - LISP dyn-eid, a - Application
O 3::/64 [254/20]
via Null0, directly connected
R2#
With OSPF External and internal discard-route entries pointed to the null0 interface are installed in routing tables by default when configuring route summarization, routing loops may occur when packet is sent to a prefix which is a part of the summary but this prefix is no longer reachable, and a router that is performing summarization has a default route advertised by another router. To prevent the routing loop, a discard route is installed in the routing table of the ABR or ASBR.
If you do not want to use the external for ASBR or internal for ABR discard route, you can remove the discard route using the no discard-route command with the external or internal keyword for ABR and ASBR respectively.
Since we are using the summary-prefix command on an ASBR, remove the discard route using the external keyword.
R2(config)#ipv router os 1
R2(config-rtr)#disc
R2(config-rtr)#discard-route ex
R2(config-rtr)#no discard-route external
Verify the routing table of R2, the discard route is no longer present.
R2#sh ipv rou osp | be App
lr - LISP site-registrations, ld - LISP dyn-eid, a - Application
ON2 3::/64 [110/20]
via 32::3, Ethernet0/2
via 23::3, Ethernet0/1
R2#
The ping from R1 is now successful.
R1#ping 3::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R1#
R1#trace 3::3
Type escape sequence to abort.
Tracing the route to 3::3
1 21::2 4 msec 1 msec 0 msec
2 32::3 1 msec 0 msec 0 msec
R1#
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: