OSPF for IPv6 (OSPFv3)
Module Introduction
Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:
student@tour:~/trainings_resources/robot$ robot ospf_ipv6/ospf_ipv6_setup.robotIn order to get a better understanding, the lab setup is shown in the picture below.
OSPFv3 Overview
OSPFv2 is a widely used link-state routing protocol that was originally designed to support IPv4. OSPFv3, as defined in RFC 5340, is an enhancement of OSPFv2 in order to support IPv6 routing. OSPFv3 retains much of the OSPFv2 mechanims but adds some modification to address IPv6-specific protocol requirements.
In OSPFv2, a link can only be associated with one OSPF process, and there is no mechanism for multiple OSPF instances on the same link. OSPFv3 introduces the concept of an instance ID field, which allows multiple OSPFv3 instances to run on a single link. This is useful for networks that may require different routing instances or policies for different traffic types.
OSPFv3 uses IPv6 link-local addresses to exchange routing information between neighbors. This simplifies neighbor discovery, as OSPFv3 does not require global or unique-local IPv6 addresses for neighbor communications.
In OSPFv2, link state advertisements (LSAs) are tightly bound to IPv4. Rather than extending certain fields in the LSAs to handle 128-bit IPv6 addresses instead of 32-bit IPv4 addresses, OSPFv3 removes the whole address semantics from Router-LSA and Network-LSA. The OSPFv3 Router-LSAs includes a list of link types, link IDs (for example, neighbor router IDs), and interface information like cost. The actual IP prefixes associated with the router are advertised in a different LSA (Intra-Area Prefix LSA). Likewise OSPFv3,Network-LSA has also been stripped of all IP address information. Similar to the Router-LSA, the prefixes are now advertised in the Intra-Area Prefix LSA.
OSPFv3 introduces some new LSA types:
-
The Link LSA (type 8) is used to advertise link-local addresses and prefixes on a specific direct conected link. It advertises the link-local address of the originating router to its OSPF neighbors on the same link and also provides the prefixes associated with the router’s interfaces, which are needed for neighbors to build the network topology. Thus, it helps associate the router’s link-local address with its global address.
-
The Intra-Area Prefix LSA (type 9) is used to advertise the IPv6 prefixes associated with a Router-LSA or Network-LSA that were previously carried in OSPFv2 Router-LSA and Network-LSA LSAs. Intra-Area Prefix LSAs are generated to describe the prefixes connected to the router itself as well as prefixes associated with a broadcast network when acting as designated router.
| Type-3 summary-LSAs have been renamed to Inter-Area Prefix LSA and type-4 summary LSAs have been renamed to Inter-Area Router LSA in OSPFv3. |
OSPFv3 introduces flooding scopes for LSAs, specifying how far they should be propagated within the network:
-
Link-local scope: LSAs are only flooded on a specific link.
-
Area scope: LSAs are only flooded within an OSPF area.
-
AS scope: LSAs are flooded across the entire Autonomous System.
| OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the size of 32 bits, i.e., they can no longer be assigned as IPv6 addresses. |
Configuring Basic OSPFv3
The configuration of OSPFv3 is very similar to OSPFv2 configuration. The main difference is that you need to assign an instance-id (set instance default protocol ospf address-family ipv6 instance-id <id>) which does not exist in OSPFv2. Other than that, the configuration semantic is the same.
Configure OSPFv3 protocol in instance default with area 0.0.0.0 and include the interfaces hostif-0/0/1/0, hostif-0/0/2/0 and lo-0/0/0/0 in the configuration. The instance-id is 1. Set the network-type of the interfaces to point-to-point and assign an interface metric of 100 to the links.
Click to reveal the answer
cfg> set instance default address-family ipv6 unicast
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 router-id 192.168.0.1
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 hostname R1
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 interface hostif-0/0/1/0 metric 100
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 interface hostif-0/0/1/0 network-type p2p
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 interface hostif-0/0/2/0 metric 100
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 interface hostif-0/0/2/0 network-type p2p
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 interface lo-0/0/0/0
cfg> commitWith OSPFv3, the operational commands remain the same in RBFS, i.e., there is OSPFv3-specific syntax. Let’s have a look at some basic commands:
cfg> show ospf interface
Instance: default, Address family: ipv6, Instance ID: 1
Interface Area IP Address State Type Cost Priority DR BDR MTU
hostif-0/0/1/0 0.0.0.0 fe80::7877:1fff:fec0:1 P2P p2p 100 1 0.0.0.0 0.0.0.0 1500
hostif-0/0/2/0 0.0.0.0 fe80::7877:1fff:fec0:2 P2P p2p 100 1 0.0.0.0 0.0.0.0 1500
lo-0/0/0/0 0.0.0.0 fc00:c0a8::192:168:0:1 P2P p2p 10000 1 0.0.0.0 0.0.0.0 0As you can see, the listed interface IP addresses are link-local IP addresses in case of physical interfaces and a unique local address (ULA) in case of the loopback interface.
cfg> show ospf neighbor
Instance: default, Address family: ipv6, Instance ID: 1
Address Interface Router Area State Priority DR BDR Uptime Expires
fe80::78fc:daff:fec0:1 hostif-0/0/1/0 192.168.0.2 0.0.0.0 Init 1 0.0.0.0 0.0.0.0 never 38s
fe80::7800:3fff:fec0:2 hostif-0/0/2/0 192.168.0.3 0.0.0.0 Init 1 0.0.0.0 0.0.0.0 never 38s
cfg> show ospf neighbor log
Instance: default
Neighbor router ID: 192.168.0.2
Event timestamp: hu Oct 17 09:02:58, Interface: hostif-0/0/1/0
Neighbor interface address: fe80::78fc:daff:fec0:1, Event: Receive one way
Current state: Down, Next state: Init
Sequence number: 2, DD flags: -|I|M|MS
Neighbor router ID: 192.168.0.3
Event timestamp: hu Oct 17 09:02:58, Interface: hostif-0/0/2/0
Neighbor interface address: fe80::7800:3fff:fec0:2, Event: Receive one way
Current state: Down, Next state: Init
Sequence number: 1, DD flags: -|I|M|MSAlthough we have configured two interfaces and we see a neighbor attached to each interface, the OSPFv3 adjacency remains down. The good news is that we already see a router ID of the neighboring routers, i.e., we must have received Hello packets. Thus, we can inspect the incoming packets:
cfg> capture interface hostif-0/0/1/0 direction in
<...>
2024-10-17T09:12:28.030921+0000 7a:fc:da:c0:00:01 > 33:33:00:00:00:05, ethertype IPv6 (0x86dd), length 170: (class 0xc0, hlim 1, next-header OSPF (89) payload length: 116) fe80::78fc:daff:fec0:1 > ff02::5: OSPFv3, Hello, length 116
Router-ID 192.168.0.2, Backbone Area, Instance 1
Options [V6, External, Router, Authentication Trailer] (1)
Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.8.6, Priority 1
Neighbor List:
Authentication Type HMAC, Length 80, SAID 1, CSN 0x00000000:6710d4f2 (1)
<...>| 1 | The router attached to interface hostif-0/0/1 is sending Hello packets with authentication enabled. |
While OSPFv2 has built-in support for MD5 and simple password authentication, but these methods are now considered outdated. Thus, OSPFv3 removes its own authentication fields and instead relies on IPsec for security, leveraging the inherent security features in IPv6. This provides stronger security mechanisms like encryption and authentication using IPsec.
Configure OSPF authentication for interface hostif-0/0/1/0 and hostif-0/0/2/0 using type hmac-sha-512 and password rtbrick. The key-id should be set to 1.
Click to reveal the answer
cfg> set authentication-profile MYOSPFAUTH
cfg> set authentication-profile MYOSPFAUTH key 1
cfg> set authentication-profile MYOSPFAUTH key 1 type hmac-sha-512
cfg> set authentication-profile MYOSPFAUTH key 1 plain-text rtbrick
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.0 authentication-profile MYOSPFAUTH
cfg> commitOnce authentication is enabled, the OSPFv3 adjacencies will come up:
cfg> show ospf neighbor
Instance: default, Address family: ipv6, Instance ID: 1
Address Interface Router Area State Priority DR BDR Uptime Expires
fe80::78fc:daff:fec0:1 hostif-0/0/1/0 R2 0.0.0.0 Full 1 0.0.0.0 0.0.0.0 0d:00h:00m:02s 39s
fe80::7800:3fff:fec0:2 hostif-0/0/2/0 R3 0.0.0.0 Full 1 0.0.0.0 0.0.0.0 0d:00h:00m:07s 39sWe already know that the link-state database (LSDB) is an important component of OSPF as all LSAs are stored in this database. With OSPFv3, there are some changes that we have already discussed earlier.
cfg> show ospf database
Instance: default, Address family: ipv6, Instance ID: 1, Area: 0.0.0.0
Type Link State ID Advertising Router Age Sequence Checksum Cost
OSPFv3-Router 0.0.0.0 R1 161 0x80000003 0xc6f3 -
OSPFv3-Router 0.0.0.0 R2 162 0x8000000a 0x1c90 -
OSPFv3-Router 0.0.0.0 R3 166 0x8000000a 0xf1aa -
Inter-Area-Prefix 1.0.0.0 R2 1563 0x80000006 0xad0b 100
Inter-Area-Prefix 1.0.0.0 R3 1563 0x80000006 0xddd6 100
Inter-Area-Prefix 2.0.0.0 R2 1558 0x80000006 0x72c6 10100
Inter-Area-Prefix 2.0.0.0 R3 1558 0x80000006 0x6ccb 10100
Inter-Area-Prefix 3.0.0.0 R2 1558 0x80000006 0x2a25 200
Inter-Area-Prefix 3.0.0.0 R3 1558 0x80000006 0xed63 200
Inter-Area-Router 192.168.0.4 R2 1558 0x80000006 0xd8b1 100
Inter-Area-Router 192.168.0.4 R3 1558 0x80000006 0xd2b6 100
Intra-Area-Prefix 1.0.0.0 R1 1126 0x80000001 0x5284 -
Intra-Area-Prefix 1.0.0.0 R2 1563 0x80000006 0x8354 -
Intra-Area-Prefix 1.0.0.0 R3 1563 0x80000006 0xf9d8 -
OSPFv3-Router-Information 0.0.0.0 R1 724 0x80000003 0x7d3f -
OSPFv3-Router-Information 0.0.0.0 R2 1568 0x80000006 0x793e -
OSPFv3-Router-Information 0.0.0.0 R3 1568 0x80000006 0x7b3a -
Link 6.8.0.0 R1 166 0x80000002 0xd7e0 -
Link 6.8.0.0 R2 1562 0x80000006 0x99d8 -
Link 6.16.0.0 R1 166 0x80000002 0xe1cb -
Link 6.16.0.0 R3 1563 0x80000006 0x7886 -
Instance: default, Address family: ipv6, Instance ID: 1
Type Link State ID Advertising Router Age Sequence Checksum Cost
OSPFv3-External 1.0.0.0 192.168.0.4 1561 0x80000006 0x4d39 16777214The most important difference is the value of link state IDs which are not bound to IP address any more. We can also verify that, for instance, the router LSA does not carry any IP address related information.
cfg> show ospf database advertising-router 192.168.0.1 ls-type router detail
Instance: default, Address family: ipv6, Area: 0.0.0.0, Instance ID: 1 LSAs
LSA ID: 0.0.0.0
Advertising router: R1, LSA type: OSPFv3-Router
Sequence number: 0x80000003, Checksum: 0xc6f3, LSA age: 802s
Length: 56, Options: -|V6|E|-|-|R|-|-, Flags: -|-|-|-
Number of links: 2
Link Entry: 1
Type: P2P, Metric: 100
Local interface ID: 4102, Neighbor interface ID: 4102, Neighbor router ID: 192.168.0.3
Link Entry: 2
Type: P2P, Metric: 100
Local interface ID: 2054, Neighbor interface ID: 2054, Neighbor router ID: 192.168.0.2When looking at the advertising router, we notice that the router IDs are resolved using hostname information. However, for R4 (RID: 192.168.0.4) this is not the case. The reason is that R4 is located in another area and the hostname resolution is bound to the local area.
cfg> show ospf hostname
Instance AFI Instance ID Router ID Hostname
default ipv6 1 192.168.0.1 R1
default ipv6 1 192.168.0.2 R2
default ipv6 1 192.168.0.3 R3The show ospf spf result and show ospf route command work the same way as in OSPFv2:
cfg> show ospf spf result
Instance: default, Address family: ipv6, Area: 0.0.0.0, Instance ID: 1
Node ID Type Cost Advertising Router Flags Neighbor Node Interface Nexthop
192.168.0.1 router 0 R1 -|-|-|- - local -
192.168.0.2 router 100 R2 -|-|-|B 192.168.0.2 hostif-0/0/1/0 fe80::78fc:daff:fec0:1
192.168.0.3 router 100 R3 -|-|-|B 192.168.0.3 hostif-0/0/2/0 fe80::7800:3fff:fec0:2
cfg> show ospf route
Instance: default, AFI: ipv6, SAFI: unicast, Instance ID: 1
Prefix Area Type Cost Next Hop Interface
2001:db8:104::/48 external-type-1 16777215 fe80::7800:3fff:fec0:2 hostif-0/0/2/0
fe80::78fc:daff:fec0:1 hostif-0/0/1/0
fc00:c0a8::192:168:0:1/128 0.0.0.0 ospf-direct 10000 n/a local
fc00:c0a8::192:168:0:2/128 0.0.0.0 intra-area 10100 fe80::78fc:daff:fec0:1 hostif-0/0/1/0
fc00:c0a8::192:168:0:3/128 0.0.0.0 intra-area 10100 fe80::7800:3fff:fec0:2 hostif-0/0/2/0
fc00:c0a8::192:168:0:4/128 0.0.0.0 inter-area 10200 fe80::78fc:daff:fec0:1 hostif-0/0/1/0
<...>Configuring Route Redistribution
Similar to OSPFv2, OSPFv3 allows external protocols to be redistributed into OSPF. These routes are than carried as type-5 external LSAs across the network.
Configure a static route in instance default for destination 2001:db8:101::/48 pointing to interface null0 and then redistribute it using the command set instance default protocol ospf address-family ipv6 instance-id 1 redistribute static.
Click to reveal the answer
cfg> set instance default static nexthop-profile DISCARD exit-interface null0
cfg> set instance default static route ipv6 2001:db8:101::/48 unicast DISCARD
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 redistribute static
cfg> commitcfg> sh ospf database ls-type external
Instance: default, Address family: ipv6, Instance ID: 1
Type Link State ID Advertising Router Age Sequence Checksum Cost
OSPFv3-External 1.0.0.0 R1 144 0x80000001 0x3958 16777214
OSPFv3-External 1.0.0.0 192.168.0.4 975 0x80000007 0x4b3a 16777214
cfg> sh ospf database ls-type external detail
Instance: default, Address family: ipv6, Instance ID: 1 LSAs
LSA ID: 1.0.0.0
Advertising router: R1, LSA type: OSPFv3-External
Sequence number: 0x80000001, Checksum: 0x3958, LSA age: 171s
Length: 36
Prefix: 2001:db8:101::/48, Prefix options: -|-|-|-|-|-
Metric: 16777214, Metric type: EXTERNAL_TYPE_1
<...>Configuring Non-Backbone Area
We have already discussed the pro and cons of OSPF areas in OSPF Multiarea Networks. There is no difference in OSPFv3 regarding the supported area types and their related behaviour.
Configure a new unit for interface lo-0/0/0 and assign the IPv6 address of fc00:c0a8:0:0:192:168:0:101/128 to it. Configure a new OSPFv3 area 1 and associate the newly created loopback-interface to it. Make the area 1 a totally-stub area.
Click to reveal the answer
cfg> set interface lo-0/0/0 unit 101 instance default
cfg> set interface lo-0/0/0 unit 101 address ipv6 fc00:c0a8:0:0:192:168:0:101/128
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.1 area-type totally-stub
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.1 authentication-profile MYOSPFAUTH
cfg> set instance default protocol ospf address-family ipv6 instance-id 1 area 0.0.0.1 interface lo-0/0/0/101
cfg> commitcfg> show ospf database area 0.0.0.1
Instance: default, Address family: ipv6, Instance ID: 1, Area: 0.0.0.1
Type Link State ID Advertising Router Age Sequence Checksum Cost
OSPFv3-Router 0.0.0.0 R1 19 0x80000001 0x13b5 -
Inter-Area-Prefix 1.0.0.0 R1 19 0x80000001 0xafec 10000 (1)
Intra-Area-Prefix 1.0.0.0 R1 19 0x80000001 0x8782 -
OSPFv3-Router-Information 0.0.0.0 R1 19 0x80000001 0x813d -
cfg> show ospf database area 0.0.0.1 ls-type inter-area-prefix detail
Instance: default, Address family: ipv6, Area: 0.0.0.1, Instance ID: 1 LSAs
LSA ID: 1.0.0.0
Advertising router: R1, LSA type: Inter-Area-Prefix
Sequence number: 0x80000001, Checksum: 0xafec, LSA age: 52s
Length: 28
Metric: 10000, Prefix options: -|-|-|-|-|-, Prefix: ::/0 (2)| 1 | As area 0.0.0.1 is a totally stub area, there is only one Inter-Area-Prefix LSA generated by the ABR, which is R1 itself. |
| 2 | Due to the nature of the area, the only prefix that is advertised is the default prefix. |