OSPF Demystified With RFC: Request For Comments Translated Into Practice

By Redouane MEDDANE

OSPF Routing Protocol is the most used protocol in the world, especially in the world of service provider, through this hand-on-labs workbook, you will discover another aspect of OSPF which is the RFCs that stands for "Request For Comments", A Request for Comments (RFC) is a formal document developed by a committee of the Internet Engineering Task Force (IETF) and subsequently reviewed by interested parties. Memos in the RFC document series contain technical and organizational notes about the Internet. They cover many aspects of computer networking, including protocols.

One of these internet protocols, OSPF is described in many RFCs, and why it is important to read and understand these RFCs? because there are many differences about path selection and behaviors between them such as Type 7 translation, summary cost, forward address, and so on, this impact is very important to know it in order to interpret an OSPF behavior.
This new approach of OSPF with RFC changes drastically the traditional path selection based on: 1-ROUTE TYPE and 2-COST.
The changes are huge, another order of selection should be taken in consideration with RFC.

The goal of this atypical and unique book in the world about OSPF Routing Protocol: is to translate the RFCs into Practice through 82 uncommon scenarios.It is written with atypical scenarios and explained with another view, in constrast with other resources, the only book in the market that explains OSPF with RFCs Request For Comments, more important, demystifying the different RFC 's behavior regarding path selection, NSSA Area options with RFC 1587 and 3101, OSPFv2 and OSPFv3 's behavior when moving from RFC 1583 to RFC 2328 and from RFC 1583 to RFC 5340 respectively.

Understanding how the RFCs explain OSPF is very important, it gives you a way to look inside OSPF Packets, such as LSA Types, LSDB and NSSA Area Types and demystifying the most misunderstanding OSPF's behavior, such as LSA Types, Area Types, Network Types OSPF Path Selection, Route Filtering, Forwarding Address, Prefix Suppression, Loop-Free Alternate, Summary Routes and so on.

To understand what inside OSPF LSAs, what happen and why this happen? for example: why the P-bit should be cleared in some situations and why it should be set, why the Forward Address must be set and why it must cleared, how suboptimal routing or routing loop can occur in OSPF.

This workbook needs a solid knownledges and goes beyond the CCIE Level.

• Language: English
• Publisher: Lulu.com
• Release date: Apr 27, 2022
• ISBN: 9781435765542

Book preview

Lab 1: RFC 3101 and RFC 1587 with OSPFv2

C:\Users\Administrator\Desktop\36.PNG

Basic configuration of all routers:

R1:

interface FastEthernet0/0

ip address 12.0.0.1 255.255.255.0

ip ospf 1 area 0

ip ospf cost 65000

no shut

!

interface FastEthernet0/1

ip address 13.0.0.1 255.255.255.0

ip ospf 1 area 2

ip os cost 1

no shut

!

router ospf 1

router-id 1.1.1.1

R2:

interface FastEthernet0/0

ip address 12.0.0.2 255.255.255.0

ip ospf 1 area 0

ip os cost 1

no shut

!

interface FastEthernet0/1

ip address 24.0.0.2 255.255.255.0

ip ospf 1 area 1

ip os cost 1

no shut

!

router ospf 1

router-id 2.2.2.2

R3:

interface FastEthernet0/0

ip address 13.0.0.3 255.255.255.0

ip ospf 1 area 2

ip os cost 1

no shut

!

interface FastEthernet0/1

ip address 34.0.0.3 255.255.255.0

ip ospf 1 area 2

ip ospf cost 65000

no shut

!

router ospf 1

router-id 3.3.3.3

R4:

interface FastEthernet0/0

ip address 24.0.0.4 255.255.255.0

ip ospf 1 area 1

ip os cost 1

no shut

!

interface FastEthernet0/1

ip address 34.0.0.4 255.255.255.0

ip ospf 1 area 2

ip ospf cost 65000

no shut

!

interface FastEthernet1/0

ip address 46.0.0.4 255.255.255.0

no shut

!

router eigrp 100

network 46.0.0.0

redistribute ospf 1 metric 1 1 1 1 1

!

router ospf 1

router-id 4.4.4.4

redistribute eigrp 100 subnets

R6:

interface Loopback0

ip address 6.6.6.6 255.255.255.0

!

interface FastEthernet0/0

ip address 46.0.0.6 255.255.255.0

no shut

!

router eigrp 100

network 6.0.0.0

network 46.0.0.0

R4 is an ASBR and redistributes between OSPF and EIGRP, the EIGRP routes are redistributed with the default metric-type 2 and default metric 20 using the redistribute eigrp 100 subnets command:

The cost of the Links between the OSPF routers are modified as illustrated in the topology.

Let's verify the routing table of R1.

R1 installes an OE2 (external type 2) with next-hop R3 toward 6.6.6.0, therefore it prefers the path through R3 rather than the path through R2, why ?

R1#show ip route | inc  6.6.6.0

O E2    6.6.6.0 [110/20] via 13.0.0.3, 00:01:39, FastEthernet0/1

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.0/24

  Known via ospf 1, distance 110, metric 20, type extern 2, forward metric 65001

  Last update from 13.0.0.3 on FastEthernet0/1, 00:01:42 ago

  Routing Descriptor Blocks:

  * 13.0.0.3, from 4.4.4.4, 00:01:42 ago, via FastEthernet0/1

      Route metric is 20, traffic share count is 1

R1#

Below we can see that R1 receives an LSA Type 5 from R4 with the Forward Address 0.0.0.0, this means that R1 will look the best path to reach the ASBR R4:

R1#show ip ospf database external 6.6.6.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: 254

  Options: (No TOS-capability, DC, Upward)

  LS Type: AS External Link

Link State ID: 6.6.6.0 (External Network Number )

Advertising Router: 4.4.4.4

  LS Seq Number: 80000001

  Checksum: 0x96E7

  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#

R1 has two paths to reach R4:

An intra-area route via R3 with a cost 65001. The cost 65001 is displayed by the show ip ospf border-routers command below.

An inter-area route via R2 with a cost 2. This cost is the cummulative of the cost 1 to reach the ABR R2 as shown by the show ip ospf border-routers command and the cost 1 listed in the LSA Type 4 advertised by R2 as shown by the show ip ospf database asbr-summary adv 2.2.2.2 command (the LSA Type 4 is created by the ABR R2 to tell to R1 how to reach the ASBR R4 and it lists the cost from the ABR R2's perspective toward the ASBR R4).

R1 chooses the intra-area route rather than the inter-area route because the intra-area route is always preferred than the inter-area route regardless the cost and even if the intra-area route has a cost 65001 higher than the cost 2 of the inter-area route.

The forward metric 65001 listed in the shown ip route 6.6.6.0 command represents the metric to reach the ASBR R4 via the intra-area route through R3.

R1#show ip os border-routers

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

                Base Topology (MTID 0)

Internal Router Routing Table

Codes: i - Intra-area route, I - Inter-area route

i4.4.4.4 [65001] via 13.0.0.3, FastEthernet0/1, ASBR, Area 2, SPF 9

i 2.2.2.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 11

R1#

R1#show ip ospf database asbr-summary adv 2.2.2.2

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

Summary ASB Link States (Area 0)

  LS age: 1026

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(AS Boundary Router)

Link State ID: 4.4.4.4 (AS Boundary Router address)

Advertising Router: 2.2.2.2

  LS Seq Number: 80000001

  Checksum: 0x9092

  Length: 28

  Network Mask: /0

        MTID: 0        Metric: 1

R1#

The traceroute issued on R1 shows that the packet goes through R3:

R1#tracer 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

VRF info: (vrf in name/id, vrf out name/id)

  1 13.0.0.3 68 msec 48 msec 56 msec

  2 34.0.0.4 96 msec 96 msec 88 msec

  3 46.0.0.6 96 msec 116 msec 96 msec

R1#

Now let's disable the link R1--R3:

R1(config)#int fa0/1

R1(config-if)#shutdown

Let's verify the routing table about the prefix 6.6.6.0/24, R1 installs the backup path through R2 with a forward metric 2 which is the cost of the inter-area route to reach the ASBR R4:

R1#show ip route | incl 6.6.6.0

O E2    6.6.6.0 [110/20] via 12.0.0.2, 00:00:16, FastEthernet0/0

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.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:00:24 ago

  Routing Descriptor Blocks:

  * 12.0.0.2, from 4.4.4.4, 00:00:24 ago, via FastEthernet0/0

      Route metric is 20, traffic share count is 1

R1#

This forward metric can be seen through the show ip ospf border-routers command as shown below, notice the code I for Inter-area route and the cost 2 to reach the R4 with RID 4.4.4.4:

R1#show ip ospf border-routers

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

                Base Topology (MTID 0)

Internal Router Routing Table

Codes: i - Intra-area route, I - Inter-area route

I4.4.4.4 [2] via 12.0.0.2, FastEthernet0/0, ASBR, Area 0, SPF 12

i 2.2.2.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 12

R1#

Now what happen if we configure area 1 and area 2 as Not-So-Stubby-Area NSSA ?

C:\Users\Administrator\Desktop\publication\36.PNG

Let's configure area 1 and area 2 as NSSA and verify the routing table of R1:

On R2 and R4:

Rx(config)#router os 1

Rx(config-router)#area 1 nssa

On R1, R3 and R4:

Rx(config)#router os 1

Rx(config-router)#area 2 nssa

R1 installs an OE2 route toward 6.6.6.0/24 via R2:

R1#show ip route | inc 6.6.6.0

O E2    6.6.6.0 [110/20] via 12.0.0.2, 00:00:58, FastEthernet0/0

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.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:01:06 ago

  Routing Descriptor Blocks:

  * 12.0.0.2, from 2.2.2.2, 00:01:06 ago, via FastEthernet0/0

      Route metric is 20, traffic share count is 1

R1#

Why R1 is installing an OE2 route through R2 rather than an ON2 route through R3 ?

R4 creates and advertises two LSAs Type 7.

An LSA Type 7 with Forward Address 24.0.0.4 (the ip address of R4's fa0/0) and floods this LSA into area 1 NSSA. The ABR R2 translates this LSA Type 7 into LSA Type 5 and copies the same Forward Address and floods this LSA Type 5 into area 0.

An LSA Type 7 with Forward Address 34.0.0.4 (the ip address of R4's Fa0/1) and floods this LSA into area 2 NSSA

R1 receives an LSA 5 from R2 via area 0 with FA 24.0.0.4 , it receives also an LSA Type 7 from R4 via area 2 with FA 34.0.0.4.

R1#show ip ospf database nssa-external 6.6.6.0

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

Type-7 AS External Link States (Area 2)

  LS age: 356

  Options: (No TOS-capability, Type 7/5 translation, DC, Upward)

  LS Type: AS External Link

Link State ID: 6.6.6.0 (External Network Number )

Advertising Router: 4.4.4.4

  LS Seq Number: 80000001

  Checksum: 0xB19C

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        MTID: 0

        Metric: 20

Forward Address: 34.0.0.4

        External Route Tag: 0

R1#

R1#show ip ospf database external 6.6.6.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: 417

  Options: (No TOS-capability, DC, Upward)

  LS Type: AS External Link

Link State ID: 6.6.6.0 (External Network Number )

Advertising Router: 2.2.2.2

  LS Seq Number: 80000001

  Checksum: 0x1456

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        MTID: 0

        Metric: 20

Forward Address: 24.0.0.4

        External Route Tag: 0

R1#

R1 looks the best path OSPF to reach the Forward Addresses 24.0.0.4 and 34.0.0.4.

R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 2 as shown by the show ip route 24.0.0.0 command.

R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as

shown by the show ip route 34.0.0.0 command.

R1#show ip route 24.0.0.0

Routing entry for 24.0.0.0/24, 1 known subnets

O IA    24.0.0.0 [110/2] via 12.0.0.2, 00:05:39, FastEthernet0/0

R1#

R1#show ip route 34.0.0.0

Routing entry for 34.0.0.0/24, 1 known subnets

O        34.0.0.0 [110/65001] via 13.0.0.3, 00:04:34, FastEthernet0/1

R1#

Since the two ospf routes (intra and inter areas routes) are pointed to different destination, it cannot prefer the intra-area route over the inter-area route, therefore R1 looks the best metric and the cost 2 of the inter-area route via R2 is better than the cost 65001 of the intra-area route via R3, as a result it prefers the OE2 route learned from R2 rather than the ON2 route learned from R4, in other words in this case intra-area and inter-area routes do not matter because they area different destinations, the traceroute shows that the packet goes through R2:

R1#traceroute 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

VRF info: (vrf in name/id, vrf out name/id)

  1 12.0.0.2 60 msec 68 msec 76 msec

  2 24.0.0.4 92 msec 84 msec 100 msec

  3 46.0.0.6 104 msec 112 msec 116 msec

R1#

Remember that the best cost 2 of the inter-area route to 24.0.0.0/24 is displayed as forward metric 2 in the show ip route 6.6.6.0/24.

Now let's change the cost of fa0/0 interface's R1 toward R2 to 65002:

R1(config)#int fa0/0

R1(config-if)#ip ospf cost 65002

R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 65003 as shown by the show ip route 24.0.0.0 command.

R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as

shown by the show ip route 34.0.0.0 command.

The cost 65001 of the intra-area route via R3 is better than the cost 65003 of the inter-area route via R2 and as a result R1 installs an ON2 route through R3:

R1#show ip route 24.0.0.0

Routing entry for 24.0.0.0/24, 1 known subnets

O IA    24.0.0.0 [110/65003] via 12.0.0.2, 00:00:17, FastEthernet0/0

R1#

R1#show ip route 34.0.0.0

Routing entry for 34.0.0.0/24, 1 known subnets

O        34.0.0.0 [110/65001] via 13.0.0.3, 00:08:32, FastEthernet0/1

R1#

The routing table of R1 displays an ON2 route, the forward metric 65001 is the cost of the intra-area route toward 34.0.0.3/24 and the packet goes through R3 as shown by the traceroute below:

R1#show ip route | inc 6.6.6.0

O N2    6.6.6.0 [110/20] via 13.0.0.3, 00:04:06, FastEthernet0/1

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.0/24

  Known via ospf 1, distance 110, metric 20, type NSSA extern 2, forward metric 65001

  Last update from 13.0.0.3 on FastEthernet0/1, 00:04:12 ago

  Routing Descriptor Blocks:

  * 13.0.0.3, from 4.4.4.4, 00:04:12 ago, via FastEthernet0/1

      Route metric is 20, traffic share count is 1

R1#

R1#tracer 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

VRF info: (vrf in name/id, vrf out name/id)

  1 13.0.0.3 368 msec 316 msec 300 msec

  2 34.0.0.4 324 msec 360 msec 208 msec

  3 46.0.0.6 104 msec 108 msec 116 msec

R1#

Let's change the cost of the fa0/0 interface's R1 to 65000:

R1(config)#int fa0/0

R1(config-if)#ip ospf cost 65000

R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 65001 as shown by the show ip route 24.0.0.0 command.

R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as shown by the show ip route 34.0.0.0 command.

R1#show ip route 24.0.0.0

Routing entry for 24.0.0.0/24, 1 known subnets

O IA    24.0.0.0 [110/65001] via 12.0.0.2, 00:00:20, FastEthernet0/0

R1#

R1#show ip route 34.0.0.0

Routing entry for 34.0.0.0/24, 1 known subnets

O        34.0.0.0 [110/65001] via 13.0.0.3, 00:14:28, FastEthernet0/1

R1#

Since the two ospf routes (intra-area and inter-area routes) are pointed to different destinations 24.0.0.0/24 and 34.0.0.0/24, R1 cannot prefer the intra-area route over the inter-area route. And since the Forward Addresses 24.0.0.4 and 34.0.0.4 are reachable with the same cost 65001, and because R1 is implementing the RFC 3101 as shown by the show ip ospf command, the following priorities in deciding which LSA (Type 5 or Type 7) is preferred are defined in the RFC 3101:

If the current LSA is functionally the same as an

              installed LSA (i.e., same destination, cost and non-zero

              forwarding address) then apply the following priorities in

              deciding which LSA is preferred:

                1. A Type-7 LSA with the P-bit set.

                2. A Type-5 LSA.

                3. The LSA with the higher router ID.

R1#show ip ospf | inc RFC

Supports NSSA (compatible with RFC 3101)

R1#

Conclusion R1 installs the NSSA external Type 2 route ON2 through R3 because the LSA Type 7 advertised by R4 is preferred than the LSA Type 5 advertised by R2 according to the RFC 3101:

R1#show ip route | inc 6.6.6.0

O N2    6.6.6.0 [110/20] via 13.0.0.3, 00:08:51, FastEthernet0/1

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.0/24

  Known via ospf 1, distance 110, metric 20, type NSSA extern 2, forward metric 65001

  Last update from 13.0.0.3 on FastEthernet0/1, 00:08:55 ago

  Routing Descriptor Blocks:

  * 13.0.0.3, from 4.4.4.4, 00:08:55 ago, via FastEthernet0/1

      Route metric is 20, traffic share count is 1

R1#

The traceroute confirms that the packet goes through R3:

R1#tracer 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

VRF info: (vrf in name/id, vrf out name/id)

  1 13.0.0.3 72 msec 76 msec 52 msec

  2 34.0.0.4 108 msec 104 msec 72 msec

  3 46.0.0.6 132 msec 136 msec 128 msec

R1#

If we enable RFC 1587 with the compatible rfc1587 command, R1 should prefer the LSA Type 5 , in other words the path through R2, since the RFC 1587 says:

When a type-5 LSA and a type-7 LSA are found to have the

        same type and an equal distance, the following priorities

        apply (listed from highest to lowest) for breaking the tie.

                a. Any type 5 LSA.

                b. A type-7 LSA with the P-bit set and the forwarding

                    address non-zero.

                c. Any other type-7 LSA.

R1(config)#router ospf 1

R1(config-router)#compatible rfc1587

Let's verify that R1is now implementing RFC 1587 using the show ip ospf command:

R1#show ip ospf | inc RFC

Supports NSSA (compatible with RFC 1587)

R1#

Now R1 installs an OSPF external type 2 OE2 through R2, in other words R1 prefers the LSA Type 5 advertised by R2 rather than the LSA Type 7 advertised by R4:

R1#show ip route | inc 6.6.6.0

O E2    6.6.6.0 [110/20] via 12.0.0.2, 00:01:12, FastEthernet0/0

R1#

R1#show ip route 6.6.6.0

Routing entry for 6.6.6.0/24

  Known via ospf 1, distance 110, metric 20, type extern 2, forward metric 65001

  Last update from 12.0.0.2 on FastEthernet0/0, 00:01:18 ago

  Routing Descriptor Blocks:

  * 12.0.0.2, from 2.2.2.2, 00:01:18 ago, via FastEthernet0/0

      Route metric is 20, traffic share count is 1

R1#

The traceroute confirms that the packet goes through R2:

R1#tracer 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

VRF info: (vrf in name/id, vrf out name/id)

  1 12.0.0.2 80 msec 56 msec 20 msec

  2 24.0.0.4 120 msec 80 msec 52 msec

  3 46.0.0.6 120 msec 112 msec 112 msec

R1#

Lab 2: RFC 3101 and RFC 1587 with OSPFv3 Address Family

C:\Users\Administrator\Desktop\ospfv3\topo.PNG

Basic configuration of all routers:

R1:

int lo0

ip address 1.1.1.1 255.255.255.0

ipv6 1:1:1::1/64

ipv6 enable

ospfv3 1 ipv6 area 0

ospfv3 1 ipv4 area 0

!

interface G0/0

ip address 12.0.0.1 255.255.255.0

ipv6 address 12::1/64

ipv6 enable

ospfv3 1 ipv6 area 12

ospfv3 1 ipv4 area 12

!

interface g0/1

ip address 21.0.0.1 255.255.255.0

ipv6 address 21::1/64

ipv6 enable

ospfv3 1 ipv4 area 21

ospfv3 1 ipv6 area 21

!

router ospfv3 1

!

address-family ipv4 unicast

  router-id 0.0.0.1

exit-address-family

!

address-family ipv6 unicast

  router-id 0.0.0.11

exit-address-family

R2:

interface G0/0

ip address 12.0.0.2 255.255.255.0

ipv6 address 12::2/64

ipv6 enable

ospfv3 1 ipv6 area 12

ospfv3 1 ipv4 area 12

!

interface g0/1

ip address 21.0.0.2 255.255.255.0

ipv6 address 21::2/64

ipv6 enable

ospfv3 1 ipv4 area 21

ospfv3 1 ipv6 area 21

!

router ospfv3 1

!

address-family ipv4 unicast

  router-id 0.0.0.2

exit-address-family

!

address-family ipv6 unicast

  router-id 0.0.0.22

exit-address-family

Let's configure area 12 as NSSA for both IPv4 and IPv6:

R1(config)#router ospfv 1

R1(config-router)#address-family ipv4 unicast

R1(config-router-af)#area 12 nssa

R1(config-router-af)#address-family ipv6 unicast

R1(config-router-af)#area 12 nssa

R2(config)#router ospfv 1

R2(config-router)#address-family ipv4 unicast

R2(config-router-af)#area 12 nssa

R2(config-router-af)#address-family ipv6 unicast

R2(config-router-af)#area 12 nssa

Let's verify the LSDB:

R1 learns an LSA Type 5 for both 2.2.2.0/24 and 2:2:2::/64 prefixes through area 21:

R1#show ospfv3 ipv4 data ext adv 0.0.0.2

OSPFv3 1 address-family ipv4 (router-id 0.0.0.1)

Type-5 AS External Link States

  LS age: 662

  LS Type: AS External Link

  Link State ID: 0

Advertising Router: 0.0.0.2

  LS Seq Number: 80000001

  Checksum: 0x1BC5

  Length: 32

Prefix Address: 2.2.2.0

  Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

R1#

R1#show ospfv3 ipv6 data ext adv 0.0.0.22

OSPFv3 1 address-family ipv6 (router-id 0.0.0.11)

Type-5 AS External Link States

  LS age: 664

  LS Type: AS External Link

  Link State ID: 0

Advertising Router: 0.0.0.22

  LS Seq Number: 80000001

  Checksum: 0xCFD0

  Length: 36

Prefix Address: 2:2:2::

  Prefix Length: 64, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

R1#

R1 learns an LSA Type 5 for both 2.2.2.0/24 and 2:2:2::/64 prefixes through area 12:

The difference is big, the LSA Type 7 for the IPv6 prefix has the P-bit set while the LSA Type 7 for the IPv4 prefix has the P-bit cleared:

The RFC 1587 in section 3.4  Originating Type-7 LSAs and the RFC 3101 in section 2.4 Originating Type-7 LSAs say that when an ASBR originates an LSA Type 5 and an LSA Type 7 for the same destination, the P-bit in the Type-7 LSA must be cleared so that this LSA 7 isn't translated.

The RFC 3101 section 2.4 Originating Type-7 LSAs says:

When an NSSA border router originates both a Type-5 LSA and a Type-7

  LSA for the same network, then the P-bit must be clear in the Type-7

  LSA so that it isn't translated into a Type-5 LSA by another NSSA

  border router.

The RFC 1587 section 3.4  Originating Type-7 LSAs says:

If a router is attached to another AS and is also an NSSA area border

  router, it may originate a both a type-5 and a type-7 LSA for the

  same network.  The type-5 LSA will be flooded to the backbone (and

  all attached type-5 capable areas) and the type-7 will be flooded

  into the NSSA.  If this is the case, the P-bit must be reset in the

  type-7 NSSA so the type-7 LSA isn't again translated into a type-5

  LSA by another NSSA area border router

Apparently the rule is only valid for OSPFv3 AF over IPv4.

R1#show ospfv3 ipv4 data nssa adv 0.0.0.2

OSPFv3 1 address-family ipv4 (router-id 0.0.0.1)

Type-7 AS External Link States (Area 12)

  LS age: 407

  LS Type: AS External Link

  Link State ID: 1

Advertising Router: 0.0.0.2

  LS Seq Number: 80000002

  Checksum: 0xD428

  Length: 32

Prefix Address: 2.2.2.0

  Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

R1#

R1#show ospfv3 ipv6 data nssa adv 0.0.0.22

OSPFv3 1 address-family ipv6 (router-id 0.0.0.11)

Type-7 AS External Link States (Area 12)

  LS age: 443

  LS Type: AS External Link

  Link State ID: 1

Advertising Router: 0.0.0.22

  LS Seq Number: 80000001

  Checksum: 0x9FEF

  Length: 52

Prefix Address: 2:2:2::

  Prefix Length: 64, Options: P

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

  Forward Address: 12::2

R1#

Now let's verify the IPv4 routing table of R1:

The IPv4 routing table shown an OE2 route through area 21, it's logic, the LSA Type 5 is preferred than the LSA Type 7 with P-bit cleared.

If we follow RFC 3101, it says that :

If the current LSA is functionally the same as an

              installed LSA (i.e., same destination, cost and non-zero

              forwarding address) then apply the following priorities in

              deciding which LSA is preferred:

                1. A Type-7 LSA with the P-bit set.

                2. A Type-5 LSA.

                3. The LSA with the higher router ID.

R1#show ip route ospfv3 | beg Gate

Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets

O E2    2.2.2.0 [110/20] via 21.0.0.2, 00:08:16, GigabitEthernet0/1

R1#

Now let's verify the IPv6 routing table of R1:

The IPv6 routing table shown an ON2 route through area 12, it's also logic according to the priorities defined by RFC 3101 above, an LSA Type 7 with P-bit set is preferred than an LSA Type 5:

R1#show ipv6 route ospf | s 2:2:2::/64

ON2 2:2:2::/64 [110/20]

    via 12::2, GigabitEthernet0/0

R1#

By default the routers R1 and R2 are running RFC 3101 as shown by the outputs below:

R1#show ospfv3 ipv4 | inc RFC

Supports NSSA (compatible with RFC 3101)

RFC1583 compatibility enabled

R1#

R1#show ospfv3 ipv6 | inc RFC

Supports NSSA (compatible with RFC 3101)

RFC1583 compatibility enabled

R1#

Let's enable RFC 1587 for both address families:

R1(config)#router ospfv 1

R1(config-router)#address-family ipv4 unicast

R1(config-router-af)#address-family ipv6 unicast

R1(config-router-af)#compatible rfc1587

R2(config)#router ospfv 1

R2(config-router)#address-family ipv4 unicast

R2(config-router-af)#address-family ipv6 unicast

R2(config-router-af)#compatible rfc1587

R1#show ospfv3 ipv4 | inc RFC

Supports NSSA (compatible with RFC 1587)

RFC1583 compatibility enabled

R1#

R1#show ospfv3 ipv6 | inc RFC

Supports NSSA (compatible with RFC 1587)

RFC1583 compatibility enabled

R1#

Let's verify the LSDB of R1, the result is the same, the LSA Type 7 for IPv4 prefix 2.2.2.0/24 has the P-bit cleared while the LSA Type 7 for the IPv6 prefix 2:2:2::/64 has the P-bit set:

R1#show ospfv3 ipv4 data nssa adv 0.0.0.2 | i Options|Router

  Advertising Router: 0.0.0.2

  Prefix Length: 24, Options: None

R1#

R1#show ospfv3 ipv6 data nssa adv 0.0.0.22 | i Options|Router

  Advertising Router: 0.0.0.22

  Prefix Length: 64, Options: P

R1#

Let's verify the IPv4 routing table:

The LSA Type 5 is preferred than the LSA Type with P-bit cleared, so the OE2 is still the preferred route:

R1#show ip route ospfv3 | beg Gate

Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets

O E2    2.2.2.0 [110/20] via 21.0.0.2, 00:14:05, GigabitEthernet0/1

R1#

But the RFC 1587 instructs R1 to prefer the LSA Type 5 instead of the LSA Type with P-bit set:

R1#show ipv6 route ospf | s 2:2:2::/64

OE2 2:2:2::/64 [110/20]

    via FE80::8AF0:31FF:FED0:74C1, GigabitEthernet0/1

R1#

RFC 1587 says:

When a type-5 LSA and a type-7 LSA are found to have the

        same type and an equal distance, the following priorities

        apply (listed from highest to lowest) for breaking the tie.

                a. Any type 5 LSA.

                b. A type-7 LSA with the P-bit set and the forwarding

                    address non-zero.

                c. Any other type-7 LSA.

To conclude after this Lab:

In OSPFv3 Address Family with IPv6 when an ASBR originates Type-LSA 5 and Type-7 for the same destination, the P-bit of the Type-7 LSA is set.

In OSPFv3 Address Family with IPv4 when an ASBR originates Type-LSA 5 and Type-7 for the same destination, the P-bit of the Type-7 LSA is cleared.

Lab 3: NSSA ABRs translator with RFC 3101 and 1587 and Nt bit

C:\Users\Administrator\Desktop\Lab CCNP Route\OSPFv3 translator RFC compatible\topo2.PNG

Basic configuration of all routers:

R1:

ipv uni

!

interface FastEthernet0/0

ip address 123.0.0.1 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 0

no shut

!

router ospfv3 1

!

address-family ipv4 unicast

  router-id 1.1.1.1

exit-address-family

R2:

ipv uni

!

interface FastEthernet0/0

ip address 123.0.0.2 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 0

no shut

!

interface Serial1/0

ip address 24.0.0.2 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 1

no shut

!

router ospfv3 1

!

address-family ipv4 unicast

  router-id 2.2.2.2

exit-address-family

R3:

ipv uni

!

interface FastEthernet0/0

ip address 123.0.0.3 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 0

no shut

!

interface Serial1/0

ip address 34.0.0.3 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 1

no shut

!

router ospfv3 1

!

address-family ipv4 unicast

  router-id 3.3.3.3

exit-address-family

R4:

ipv uni

!

interface Loopback0

ip address 4.4.4.4 255.255.255.0

!

interface Serial1/0

ip address 24.0.0.4 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 1

no shut

!

interface Serial1/1

ip address 34.0.0.4 255.255.255.0

ipv6 enable

ospfv3 1 ipv4 area 1

no shut

!

router ospfv3 1

router-id 4.4.4.4

!

address-family ipv4 unicast

  redistribute connected route-map CONNECTED

  area 1 nssa

exit-address-family

!

route-map CONNECTED permit 10

match interface Loopback0

Area 1 an NSSA.

R2 and R3 are ABRs NSSA.

R4 is ASBR NSSA and redistributes the prefix 4.4.4.0/24 into NSSA:

We can see below that R4 creates LSA Type 7 for the prefix 4.4.4.0/24:

R4#show ospfv3 database nssa-external

          OSPFv3 1 address-family ipv4 (router-id 4.4.4.4)

Type-7 AS External Link States (Area 1)

  LS age: 63

  LS Type: AS External Link

  Link State ID: 1

Advertising Router: 4.4.4.4

  LS Seq Number: 80000001

  Checksum: 0x6148

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: P

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R4#

From RFC 3101, If there are multiple NSSA ABRs capable of performing Type 7-to-5 translation, the router advertising with higher Router ID is elected as the translator. The NSSA ABR that is no longer required to perform translation, flushes its Type 5 LSAs. In this case the RID of R2 is 2.2.2.2 and the RID of R3 is 3.3.3.3 thus R3 wins and performs the translation of LSA 7 into LSA5, the show ospv3 data ext command below shown the LSA Type 5 originated by R3:

R3#show ospfv3 database external

          OSPFv3 1 address-family ipv4 (router-id 3.3.3.3)

Type-5 AS External Link States

  LS age: 116

  LS Type: AS External Link

  Link State ID: 0

Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x8315

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R3#

We can verify that R2 does not originate LSA Type 5 using the show ospfv3 database external self-originate command and it learns the LSA Type 5 from R3 as shown by the show ospfv3 database external adv 3.3.3.3 command:

R2#show ospfv3 database external self-originate

          OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

R2#

R2#show ospfv3 database external adv 3.3.3.3

          OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

Type-5 AS External Link States

  LS age: 286

  LS Type: AS External Link

  Link State ID: 0

Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x8315

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R2#

R3#show ospfv3 database external self-originate

          OSPFv3 1 address-family ipv4 (router-id 3.3.3.3)

Type-5 AS External Link States

  LS age: 217

  LS Type: AS External Link

  Link State ID: 0

Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x8315

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R3#

The show ospfv3 is another way to verify which NSSA ABR is performing the translation, below the output displayed on R3 shown that it is the translator, notice line Perform type-7/type-5 LSA translation :

R3#show ospfv3

OSPFv3 1 address-family ipv4

Router ID 3.3.3.3

Supports NSSA (compatible with RFC 3101)

Event-log enabled, Maximum number of events: 1000, Mode: cyclic

It is an area border and autonomous system boundary router

Redistributing External Routes from,

Router is not originating router-LSAs with maximum metric

Initial SPF schedule delay 5000 msecs

Minimum hold time between two consecutive SPFs 10000 msecs

Maximum wait time between two consecutive SPFs 10000 msecs

Minimum LSA interval 5 secs

Minimum LSA arrival 1000 msecs

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

Retransmission limit dc 24 non-dc 24

Number of external LSA 1. Checksum Sum 0x00791E

Number of areas in this router is 2. 1 normal 0 stub 1 nssa

Graceful restart helper support enabled

Reference bandwidth unit is 100 mbps

RFC1583 compatibility enabled

    Area BACKBONE(0)

        Number of interfaces in this area is 1

        SPF algorithm executed 7 times

        Number of LSA 12. Checksum Sum 0x065EE8

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

    Area 1

        Number of interfaces in this area is 1

It is a NSSA area

Perform type-7/type-5 LSA translation

        SPF algorithm executed 10 times

        Number of LSA 11. Checksum Sum 0x0551F8

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R3#

The same command show ospfv3 can be used on R2 to verify that there is no mention of the message Perform type-7/type-5 LSA translation:

R2#show ospfv3

OSPFv3 1 address-family ipv4

Router ID 2.2.2.2

Supports NSSA (compatible with RFC 3101)

Event-log enabled, Maximum number of events: 1000, Mode: cyclic

It is an area border and autonomous system boundary router

Redistributing External Routes from,

Router is not originating router-LSAs with maximum metric

Initial SPF schedule delay 5000 msecs

Minimum hold time between two consecutive SPFs 10000 msecs

Maximum wait time between two consecutive SPFs 10000 msecs

Minimum LSA interval 5 secs

Minimum LSA arrival 1000 msecs

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

Retransmission limit dc 24 non-dc 24

Number of external LSA 1. Checksum Sum 0x009704

Number of areas in this router is 2. 1 normal 0 stub 1 nssa

Graceful restart helper support enabled

Reference bandwidth unit is 100 mbps

RFC1583 compatibility enabled

    Area BACKBONE(0)

        Number of interfaces in this area is 1

        SPF algorithm executed 12 times

        Number of LSA 12. Checksum Sum 0x065EE8

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

    Area 1

        Number of interfaces in this area is 1

It is a NSSA area

        SPF algorithm executed 17 times

        Number of LSA 11. Checksum Sum 0x057503

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R2#

In the outputs of the show ospfv3 command displayed above on R2 and R3, we can see that the RFC 3101 is enabled as shown by the line Supports NSSA (compatible with RFC 3101).

We can Configure the NSSA ABR R2 as a forced NSSA LSA 7 translator using the area 1 nssa translate type7 always command, the always keyword configures an NSSA ABR as a forced NSSA LSA  7 translator:

R2(config)#router ospfv3 1

R2(config-router)#address-family ipv4 unicast

R2(config-router-af)#area 1 nssa translate type7 always

Below we can see that R2 is originating the LSA Type 5:

R2#show ospfv3 database external

          OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

Type-5 AS External Link States

  LS age: 31

  LS Type: AS External Link

  Link State ID: 2

Advertising Router: 2.2.2.2

  LS Seq Number: 80000001

  Checksum: 0x8D0D

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R2#

Let's confirm with the show ospfv3 command that R2 is the translator:

1-The line Configured to translate Type-7 LSAs tells us that R2 is configured as a forced NSSA

ABR translator.

2-The line Perform type-7/type-5 LSA translation tells us that R2 is NSSA ABR performing the

translation.

R2#show ospfv3 | incl 7

Configured to translate Type-7 LSAs

Perform type-7/type-5 LSA translation

R2#

RFC 5340 defines a new bit Nt bit (Nt stands for NSSA translation) in the Type-1 LSA for OSPFv3.

RFC 5340 section: A.4.3.  Router-LSAs

Bit Nt

      When set, the router is an NSSA border router that is

      unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt

      stands for NSSA translation).  Note that such routers have their

      NSSATranslatorRole area configuration parameter set to Always.

      (See [NSSA].)

RFC 3101 includes also the Nt Bit explained in the following option:

Appendix B: Router-LSAs

bit Nt

          When set, the router is an NSSA border router that is

          unconditionally translating Type-7 LSAs into Type-5 LSAs (Nt

          stands for NSSA translation).  Note that such routers have

          their NSSATranslatorRole area configuration parameter set to

          Always.  (See Appendix D and Section 3.1.)

Appendix D:  Configuration Parameters

      NSSATranslatorRole

        Specifies whether or not an NSSA border router will

        unconditionally translate Type-7 LSAs into Type-5 LSAs.  When

        it is set to Always, an NSSA border router always translates

        Type-7 LSAs into Type-5 LSAs regardless of the translator state

        of other NSSA border routers.  When it is set to Candidate, an

        NSSA border router participates in the translator election

        process described in Section 3.1.  The default setting is

        Candidate.

The LSA Type 1 originated by R2 in Area 1 shows the line The Unconditional NSSA translator", it indicates that the status of the NSSA ASBR router is as a forced NSSA LSA translator. This means that the Nt-Bit is set in LSA Type 1:

R2#show ospfv data router self | beg Area 1

Router Link States (Area 1)

  LS age: 226

  Options: (N-Bit, R-bit, DC-Bit, AF-Bit)

  LS Type: Router Links

  Link State ID: 0

Advertising Router: 2.2.2.2

  LS Seq Number: 80000002

  Checksum: 0x8006

  Length: 40

  Area Border Router

  AS Boundary Router

Unconditional NSSA translator

  Number of Links: 1

    Link connected to: another Router (point-to-point)

      Link Metric: 64

      Local Interface ID: 4

      Neighbor Interface ID: 4

      Neighbor Router ID: 4.4.4.4

R2#

By default the RFC 3101 is enabled on R2, let's enable RFC 1587 using the compatible rfc1587 command:

R2(config)#router ospfv 1

R2(config-router)#address-family ipv4 uni

R2(config-router-af)#compatible rfc1587

Let's see what happen for the translation, below we can see that R3 is originating the LSA Type 5 and it is the translator:

R2#show ospfv3 database external

          OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

Type-5 AS External Link States

  Routing Bit Set on this LSA

  LS age: 13

  LS Type: AS External Link

  Link State ID: 2

Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x6F27

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

Forward Address: 34.0.0.4

R2#

Let's verify the always keyword on R2, it's clear the area 1 nssa translate type7 always command is still here:

R2#show run | s router

router ospfv3 1

!

address-family ipv4 unicast

  router-id 2.2.2.2

  compatible rfc1587

area 1 nssa translate type7 always

exit-address-family

R2#

Let's confirm that R3 is the translator using the show ospfv3 command:

R3#show ospfv3 | incl 7|RFC

Supports NSSA (compatible with RFC 3101)

Number of external LSA 1. Checksum Sum 0x006F27

RFC1583 compatibility enabled

        SPF algorithm executed 7 times

Perform type-7/type-5 LSA translation

R3#

Why R3 is the translator even though R2 is the forced NSSA ABR translator ?

Let's see the show ospfv3 command on R2, two things we can deduce from the output:

From cisco:

1-the line Supports NSSA (compatible with RFC 1587) Specifies that RFC 1587 is active or that the OSPFv3 NSSA area is RFC 1587 compatible.

2-the line Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled) Specifies that the OSPFv3 NSSA area has an ABR device configured to act as a forced translator of Type 7 LSA. However, it is inactive because RFC 3101 is disabled.

As a result, because R2 is implementing the RFC 1587 and the RFC 3101 is disabled, OSPFv3 ignores the area 1 nssa translate type7 always command, and the tie breaker is the router-id:

R2#show ospfv3

OSPFv3 1 address-family ipv4

Router ID 2.2.2.2

Supports NSSA (compatible with RFC 1587)

Event-log enabled, Maximum number of events: 1000, Mode: cyclic

It is an area border and autonomous system boundary router

Redistributing External Routes from,

Router is not originating router-LSAs with maximum metric

Initial SPF schedule delay 5000 msecs

Minimum hold time between two consecutive SPFs 10000 msecs

Maximum wait time between two consecutive SPFs 10000 msecs

Minimum LSA interval 5 secs

Minimum LSA arrival 1000 msecs

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

Retransmission limit dc 24 non-dc 24

Number of external LSA 1. Checksum Sum 0x006F27

Number of areas in this router is 2. 1 normal 0 stub 1 nssa

Graceful restart helper support enabled

Reference bandwidth unit is 100 mbps

RFC1583 compatibility enabled

    Area BACKBONE(0)

        Number of interfaces in this area is 1

        SPF algorithm executed 13 times

        Number of LSA 12. Checksum Sum 0x065EE8

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

    Area 1

        Number of interfaces in this area is 1

        It is a NSSA area

Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled)

        SPF algorithm executed 21 times

        Number of LSA 11. Checksum Sum 0x057105

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R2#

Let's enable RFC 1587 on R3:

R3(config)#router ospfv 1

R3(config-router)#address-family ipv4 unicast

R3(config-router-af)#compatible rfc1587

The show ospfv3 command shown that R3 is the translator because it has a higher router-id:

R3#show ospfv3 | sec type-7|RFC

Supports NSSA (compatible with RFC 1587)

RFC1583 compatibility enabled

    Area BACKBONE(0)

Perform type-7/type-5 LSA translation

R3#

Therefore R3 originates LSA Type 5 as shown by the show ospfv3 database external command:

R3#show ospfv3 database external

          OSPFv3 1 address-family ipv4 (router-id 3.3.3.3)

Type-5 AS External Link States

  LS age: 709

  LS Type: AS External Link

  Link State ID: 2

Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x6F27

  Length: 48

Prefix Address: 4.4.4.0

Prefix Length: 24, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

  Forward Address: 34.0.0.4

R3#

Let's confirm by changing the router-id of R2 to be higher than 3.3.3.3, for example 22.22.22.22, clear the OSPFv3 process using the clear ospfv3 process command:

R2(config)#router ospfv 1

R2(config-router)#address-family ipv4 unicast

R2(config-router-af)#router-id 22.22.22.22

% OSPFv3-1-IPv4: Reload or use clear ospfv3 process command, for this to take effect

R2(config-router-af)#do clea ospfv3 pro

Reset selected OSPFv3 processes? [no]: y

R2(config-router-af)#

*Sep 18 08:57:51.563: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 1.1.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

*Sep 18 08:57:51.567: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 3.3.3.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

*Sep 18 08:57:51.647: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 4.4.4.4 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached

*Sep 18 08:57:52.375: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 4.4.4.4 on Serial1/0 from LOADING to FULL, Loading Done

Now R2 is the Translator because it has a higher router-id:

R2#show ospfv3 | incl 7|RFC

Supports NSSA (compatible with RFC 1587)

RFC1583 compatibility enabled

Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled)

Perform type-7/type-5 LSA translation

R2#

R3#show ospfv3 | beg Area 1

    Area 1

        Number of interfaces in this area is 1

It is a NSSA area

        SPF algorithm executed 17 times

        Number of LSA 11. Checksum Sum 0x049B1A

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R3#

Lab 4: RFC 5340 and the next-hop for OSPFv3 routes

C:\Users\Administrator\Desktop\Lab CCNP Route\OSPFv3 next hop\topo1.PNG

Basic configuration of all routers:

R1:

ipv uni

!

interface FastEthernet0/0

ipv6 address 12::1/64

ipv6 ospf 1 area 0

no shu

!

interface FastEthernet1/0

ipv6 address 13::1/64

ipv6 ospf 1 area 0

no shu

!

ipv6 router ospf 1

router-id 1.1.1.1

R2:

ipv uni

!

interface FastEthernet0/0

ipv6 address 12::2/64

ipv6 ospf 1 area 0

no shu

!

interface FastEthernet1/1

ipv6 address 24::2/64

ipv6 ospf 1 area 1

no shu

!

ipv6 router ospf 1

router-id 2.2.2.2

area 1 nssa

area 1 nssa default-information-originate

R3:

ipv uni

!

interface FastEthernet1/1

ipv6 address 13::3/64

ipv6 ospf 1 area 0

no shu

!

interface FastEthernet0/0

ipv6 address 34::3/64

ipv6 ospf 1 area 1

no shu

!

ipv6 router ospf 1

router-id 3.3.3.3

area 1 nssa

area 1 nssa default-information-originate

R4:

ipv uni

!

int lo0

ipv add 4::4/64

!

interface FastEthernet1/0

ipv6 address 24::4/64

ipv6 ospf 1 area 1

no shu

!

interface FastEthernet0/0

ipv6 address 34::4/64

ipv6 ospf 1 area 1

no shu

!

ipv6 router ospf 1

router-id 4.4.4.4

area 1 nssa

By definition We know that the routing protocols with IPv6 use the Link-Local Address as the source of the routing updates and as the next-hop for the routes installed in the routing table, But in OSPFv3 , this is not the case when using NSSA and the Forward Address is set in the LSA Type 7.

In this topology R2 and R3 inject a default routes using the area 1 nssa default-information originate command.

We can see below that they advertise two LSAs Type 7 default route with the Forward Address 24::2 and 34::3 respectively:

R2#show ipv6 os data nssa self | inc Address

  Prefix Address: ::

Forward Address: 24::2

R2#

R3#show ipv6 os data nssa self | inc Address

  Prefix Address: ::

Forward Address: 34::3

R3#

Let's verify the routing table of R4:

R4 looks that the two Forward Addresses belong to the two links directly connected therefore it installs two default routes with the next-hops 24::2 and 34::3 (Global IPv6 Addresses), so R4 uses the Forward Addresses included in the LSAs Type 7 as the next-hops for the default routes.

R4#show ipv route ::/0

Routing entry for ::/0

  Known via ospf 1, distance 110, metric 1, type NSSA extern 2

  Route count is 2/2, share count 0

  Routing paths:

24::2, FastEthernet0/0

      Last updated 00:15:58 ago

34::3, FastEthernet1/0

      Last updated 00:14:53 ago

R4#

The RFC 5340 , section: A.4.7.  AS-External-LSAs says:

Forwarding address

      A fully qualified IPv6 address (128 bits).  Included in the LSA if

      and only if bit F has been set.  If included, data traffic for the

      advertised destination will be forwarded to this address.  It MUST

      NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an

      IPv6 Link-Local Address (Prefix FE80/10).  While OSPFv3 routes are

      normally installed with link-local addresses, an OSPFv3

      implementation advertising a forwarding address MUST advertise a

      global IPv6 address.  This global IPv6 address may be the next-hop

      gateway for an external prefix or may be obtained through some

      other method (e.g., configuration).

Per RFC 3101 section: 2.3  Type-7 LSAs

  Normally the next hop address of an installed AS external route

  learned by an NSSA ASBR from an adjacent AS points at one of the

  adjacent AS's gateway routers.  If this address belongs to a network

  connected to the NSSA ASBR via one of its NSSAs' active interfaces,

  then the NSSA ASBR copies this next hop address into the forwarding

  address field of the route's Type-7 LSA that is originated into this

  NSSA, as is currently done with Type-5 LSAs.

But what if the Forward Address is not in the same subnet as the Links of the router ?

In this case let's look at the LSA Type 7 generated by R4 for the external prefix 4::/64, this LSA Type 7 has a Forward Address 34::4, therefore R3 uses the FA as the next-hop in the routing table while R2 will use the Link-Local Address of R4 as the next-hop in the routing table.

Let's redistribute the loopback 4::/64 into NSSA on R4.

ipv6 router ospf 1

redistribute connected route-map CONNECTED

!

route-map CONNECTED permit 10

match interface Loopback0

R4 creates an LSA Type 7 for the prefix 4::/64 et includes a non zero Forward Address 34::4 as shown by the show ipv6 os data nssa adv 4.4.4.4 issued on R2 and R3:

R3#show ipv6 os data nssa adv 4.4.4.4 | inc Forward Address

Forward Address: 34::4

R3#

R2#show ipv6 os data nssa adv 4.4.4.4 | inc Forward Address

Forward Address: 34::4

R2#

Let's look the routing table of R3, it installs an NSSA type 2 route with next-hop 34::4 which is the Forward Address included in the LSA Type 7 described above, it's a global IPv6 address not a Link-local address:

R3#show ipv6 route 4::/64

Routing entry for 4::/64

  Known via ospf 1, distance 110, metric 20, type NSSA extern 2

  Route count is 1/1, share count 0

  Routing paths:

34::4, FastEthernet1/1

      Last updated 00:09:13 ago

R3#

Now Let's look the routing table of R2, it installs an NSSA type 2 route with next-hop FE80::C804:FFF:FE68:0which is the Link-local address of R4's fa1/0 connected to R2:

R2#show ipv6 route 4::/64

Routing entry for 4::/64

  Known via ospf 1, distance 110, metric 20, type NSSA extern 2

  Route count is 1/1, share count 0

Routing paths:

FE80::C804:FFF:FE68:0, FastEthernet0/0

      Last updated 00:11:06 ago

R2#

The RFC says" an OSPFv3

      implementation advertising a forwarding address MUST advertise a

      global IPv6 address.  This global IPv6 address may be the next-hop

      gateway for an external prefix"

In this case the LSA Type 7 generated by R4 for the external prefix 4::/64 has a Forward Address 34::4, therefore R3 uses the FA as the next-hop in the routing table while R2 will use the Link-Local Address of R4 as the next-hop in the routing table.

Lab 5: RFC 1583 and RFC 2328 for the Summary route

C:\Users\Administrator\Desktop\Lab CCNP Route\OSPF RFC 1583\topo1.PNG

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 shut

!

interface FastEthernet0/1

ip address 13.0.0.1 255.255.255.0

ip ospf 1 area 0

no shut

!

router ospf 1

router-id 0.0.0.1

R2:

interface Loopback0

ip address 172.16.2.2 255.255.255.0

ip ospf network point-to-point

ip ospf 1 area 1

!

interface FastEthernet0/0

ip address 12.0.0.2 255.255.255.0

ip ospf 1 area 0

no shut

!

interface Serial1/0

ip address 24.0.0.2 255.255.255.0

ip ospf 1 area 1

no shut

!

router ospf 1

router-id 0.0.0.2

area 1 range 172.16.0.0 255.255.0.0

R3:

interface Loopback0

ip address 172.16.3.3 255.255.255.0

ip ospf network point-to-point

ip ospf 1 area 1

!

interface FastEthernet0/0

ip address 13.0.0.3 255.255.255.0

ip ospf 1 area 0

no shut

!

interface FastEthernet0/1

ip address 34.0.0.3 255.255.255.0

ip ospf 1 area 1

no shut

!

router ospf 1

router-id 0.0.0.3

area 1 range 172.16.0.0 255.255.0.0

R4:

interface Loopback0

ip address 172.16.4.4 255.255.255.0

ip ospf network point-to-point

ip ospf 1 area 1

!

interface FastEthernet0/0

ip address 34.0.0.4 255.255.255.0

ip ospf 1 area 1

no shut

!

interface Serial1/0

ip address 24.0.0.4 255.255.255.0

ip ospf 1 area 1

no shut

!

router ospf 1

router-id 0.0.0.4

R2 and R3 are ABRs, and they are summarizing the networks 172.16.2.0/24, 172.16.3.0/24 and 172.16.4.0/24 into area 0

using the area 1 range 172.16.0.0 255.255.0.0 command.

Therefore both R2 and R3 advertise a summary route 172.16.0.0/16 for the network 172.16.2.0/24, 172.16.3.0/24 and 172.16.4.0/24:

The routing table below shown that R1 installing a load balancing for the summary route:

R1# show ip route ospf | beg Gate

Gateway of last resort is not set

      24.0.0.0/24 is subnetted, 1 subnets

O IA    24.0.0.0 [110/65] via 12.0.0.2, 00:01:41, FastEthernet0/0

      34.0.0.0/24 is subnetted, 1 subnets

O IA    34.0.0.0 [110/2] via 13.0.0.3, 00:01:36, FastEthernet0/1

O IA  172.16.0.0/16 [110/2] via 13.0.0.3, 00:01:36, FastEthernet0/1

[110/2] via 12.0.0.2, 00:00:30, FastEthernet0/0

R1#

Let's verify the LSDB of R1, we can see below thatR1 is receiving two LSAs Type 3 for the summary route from R2 and R3, the metric listed in these LSA Type 3 is 1:

R1#show ip os data summ 172.16.0.0

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

Summary Net Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 178

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

Link State ID: 172.16.0.0 (summary Network Number)

Advertising Router: 0.0.0.2

  LS Seq Number: 80000003

  Checksum: 0xFD7D

  Length: 28

  Network Mask: /16

        MTID: 0        Metric: 1

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 281

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

Link State ID: 172.16.0.0 (summary Network Number)

Advertising Router: 0.0.0.3

  LS Seq Number: 80000001

  Checksum: 0xFB80

  Length: 28

  Network Mask: /16

        MTID: 0        Metric: 1

R1#

R1 looks the cost to reach the ABRs R2 and R3 as shown by show ip ospf border-routers command, the cost is 1 toward R2 and R3, therefore R1 adds this cost to the metric listed in the LSAs Type 3:

to calculate the total cost to the summary route: 1+1=2.

R1#show ip ospf 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 [1] via 13.0.0.3, FastEthernet0/1, ABR, Area 0, SPF 3

i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3

R1#

Another useful command to see all intra-area and inter-area routes/intra-area and inter-area routers is the show ip ospf route command which is hidden in IOS:

R1#show ip ospf route

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

                Base Topology (MTID 0)

    Area BACKBONE(0)

    Intra-area Route List

*  13.0.0.0/24, Intra, cost 1, area 0, Connected

      via 13.0.0.1, FastEthernet0/1

*  12.0.0.0/24, Intra, cost 1, area 0, Connected

      via 12.0.0.1, FastEthernet0/0

    Intra-area Router Path List

i 0.0.0.3 [1] via 13.0.0.3, FastEthernet0/1, ABR, Area 0, SPF 3

i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3

    Inter-area Route List

*>  172.16.0.0/16, Inter, cost 2, area 0

via 12.0.0.2, FastEthernet0/0

via 13.0.0.3, FastEthernet0/1

*>  24.0.0.0/24, Inter, cost 65, area 0

      via 12.0.0.2, FastEthernet0/0

*>  34.0.0.0/24, Inter, cost 2, area 0

      via 13.0.0.3, FastEthernet0/1

R1#

The show ip ospf command executed below on R2 and R3 shown that the cost of the summary route is 1, which is the same listed in the LSAs Type 3:

R2#show ip ospf | beg Area 1

    Area 1

        Number of interfaces in this area is 2

        Area has no authentication

        SPF algorithm last executed 00:07:57.336 ago

        SPF algorithm executed 5 times

        Area ranges are

172.16.0.0/16 Active(1) Advertise

        Number of LSA 8. Checksum Sum 0x06DEB4

        Number of opaque link LSA 0. Checksum Sum 0x000000

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R2#

R3#show ip ospf | beg Area 1

    Area 1

        Number of interfaces in this area is 2

        Area has no authentication

        SPF algorithm last executed 00:09:53.628 ago

        SPF algorithm executed 4 times

        Area ranges are

172.16.0.0/16 Active(1) Advertise

        Number of LSA 8. Checksum Sum 0x06DEB4

        Number of opaque link LSA 0. Checksum Sum 0x000000

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R3#

Why the cost 1 of the summary route ?

-By default the routers implement the old RFC 1583, which means the cost of the summary route is the lowest metric of the summarized routes.

RFC 1583 says in Section 3.5:

The OSPF area concept is modelled after an IP subnetted network.

  OSPF areas have been loosely defined to be a collection of

  networks.  In actuality, an OSPF area is specified to be a list

  of address ranges (see Section C.2 for more details).  Each

  address range is defined as an [address,mask] pair.  Many

  separate networks may then be contained in a single address

  range, just as a subnetted network is composed of many separate

  subnets.  Area border routers then summarize the area contents

  (for distribution to the backbone) by advertising a single route

  for each address range.  The cost of the route is the minimum

  cost to any of the networks falling in the specified range.

In this topology:

R2 has three intra-area routes toward:

1-172.16.3.0/24 with cost 66.

2-172.16.4.0/24 with cost 65.

3-172.16.2.0/24 with cost 1.

R2 has three intra-area routes toward:

1-172.16.3.0/24 with cost 1.

2-172.16.4.0/24 with cost 2.

3-172.16.2.0/24 with cost 66.

According to the RFC 1583, when an ABR summarizes intra-area routes with different cost, it selects the lowest cost for the summary route, as result:

R2 chooses the cost 1 for its summary route.

R3 chooses the cost 1 for its summary route.

Cisco defines the no compatible rfc1583 command. The no compatible rfc1583 instructs the router to disable RFC 1583, and it activates the new RFC 2228, which means the cost of the summary route is the highest metric of the summarized routes.

RFC 2328 says in Section 3.5:

In order to get better aggregation at area boundaries, area address

  ranges can be employed (see Section C.2 for