OSPFv2 versus OSPFv3
By stretch | Tuesday, March 2, 2010 at 4:27 a.m. UTC
OSPFv3 is to IPv6 what OSPFv2 is to IPv4. The two versions of OSPF naturally have much in common, however there are several important differences in the way the two protocols operate. This article seeks to highlight some of the more noteworthy deviations. (For a more thorough discussion, see section 2 of RFC 5340.) For illustration, both OSPFv2 and OSPFv3 have been configured on the example topology below.
For some IOS OSPFv3 configuration fundamentals, see IPv6 and OSPFv3.
New LSA Types
OSPFv3 carries over the seven basic LSA types we're familiar with from OSPFv2. However, the type 1 and 2 LSAs have been re-purposed, as will be discussed in a bit. OSPFv3 also introduces two new LSA types: Link and Intra-area Prefix.
|0x2001||Router LSA||1||Router LSA|
|0x2002||Network LSA||2||Network LSA|
|0x2003||Inter-area Prefix LSA||3||Network Summary LSA|
|0x2004||Inter-area Router LSA||4||ASBR Summary LSA|
|0x4005||AS-External LSA||5||AS-External LSA|
|0x2006||Group Membership LSA||6||Group Membership LSA|
|0x2007||Type-7 LSA||7||NSSA External LSA|
|0x2009||Intra-area Prefix LSA|
Separation of Addressing from the SPF Tree
One of the biggest advantages of OSPFv3 over its predecessor is the separation of IP addressing from the calculation of the SPF tree. One of OSPFv3's new LSAs, the Intra-area Prefix LSA (type 9), handles intra-area network information that was previously included in OSPFv2 type 2 LSAs. Because IP addressing is communicated independent of the LSAs used for SPF tree calculation, adding or modifying IP subnets within the OSPF domain will not affect the integrity of the SPF tree (which is concerned only with nodes and the links between them) and avoid forcing an SPF recalculation.
For illustration, following are the two OSPF databases from R2 in our example topology:
R2# show ip ospf database OSPF Router with ID (126.96.36.199) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 188.8.131.52 184.108.40.206 1697 0x80000001 0x00264B 2 220.127.116.11 18.104.22.168 1693 0x80000002 0x005216 2 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.123.0 22.214.171.124 1683 0x80000002 0x00DEC5 Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count 126.96.36.199 188.8.131.52 1656 0x80000003 0x00BB55 1 184.108.40.206 220.127.116.11 1655 0x80000003 0x008086 1 18.104.22.168 22.214.171.124 1656 0x80000003 0x003FBF 1 Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 10.0.123.3 126.96.36.199 1656 0x80000001 0x007B0E Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 10.0.0.0 188.8.131.52 1694 0x80000001 0x003BB2
R2# show ipv6 ospf database OSPFv3 Router with ID (184.108.40.206) (Process ID 1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 220.127.116.11 1694 0x80000002 0 1 B 18.104.22.168 1695 0x80000002 0 1 None Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 22.214.171.124 1692 0x80000001 2001:DB8:0:123::/64 Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 126.96.36.199 1696 0x80000002 6 Se1/0 188.8.131.52 1699 0x80000002 6 Se1/0 Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 184.108.40.206 1696 0x80000001 0 0x2001 0 220.127.116.11 1699 0x80000001 0 0x2001 0 Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 18.104.22.168 1652 0x80000005 0 1 None 22.214.171.124 1652 0x80000005 0 1 B 126.96.36.199 1649 0x80000005 0 1 None Net Link States (Area 1) ADV Router Age Seq# Link ID Rtr count 188.8.131.52 1661 0x80000001 4 3 Inter Area Prefix Link States (Area 1) ADV Router Age Seq# Prefix 184.108.40.206 1693 0x80000001 2001:DB8::/64 Link (Type-8) Link States (Area 1) ADV Router Age Seq# Link ID Interface 220.127.116.11 1697 0x80000002 4 Fa0/0 18.104.22.168 1698 0x80000002 4 Fa0/0 22.214.171.124 1696 0x80000002 4 Fa0/0 Intra Area Prefix Link States (Area 1) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 126.96.36.199 1662 0x80000001 4096 0x2002 4
Note that the OSPFv3 database appears larger, because network addressing is now stored separately in the new Link and Intra-area LSAs.
LSA Flooding Scope
Looking again at the above table of LSA types, one might note that OSPFv3 LSA numbers begin with differing numbers (for example, 0x2001 versus 0x4005). The second and third most-significant bits in an LSA number (referenced as bits S2 and S1, respectively) indicate its flooding scope:
|1||0||AS (OSPF domain)|
Most LSAs begin with 0x2, indicating that they are flooded within an area. Two LSAs of note are the AS-External LSA (which advertises external routes) with a domain-wide scope, and the Link LSA with a scope appropriately restricted to the local link.
An OSPFv2 router forms adjacencies using its configured IPv4 interface address:
R1# show ip ospf neighbor detail Neighbor 188.8.131.52, interface address 10.0.123.2 In the area 1 via interface FastEthernet0/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 10.0.123.3 BDR is 10.0.123.2 Options is 0x52 LLS Options is 0x1 (LR) Dead timer due in 00:00:37 Neighbor is up for 00:15:32 Index 2/2, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec ...
OSPFv3, however, makes use of IPv6's link-local address scope (FE80::/10). All OSPFv3 adjacencies are formed using link-local addresses:
R1# show ipv6 ospf neighbor detail Neighbor 184.108.40.206 In the area 1 via interface FastEthernet0/0 Neighbor: interface-id 4, link-local address FE80::C003:7DFF:FE07:0 Neighbor priority is 1, State is FULL, 6 state changes DR is 220.127.116.11 BDR is 18.104.22.168 Options is 0x6670B96D Dead timer due in 00:00:32 Neighbor is up for 00:16:48 Index 1/1/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
Also note in the second output that neighboring routers are referred to not by IP address, but by OSPF ID, demonstrating OSPFv3's fundamental separation of the SPF tree and IP addressing. It is worth pointing out that OSPFv3 router IDs are not IPv4 addresses; they are merely unique 32-bit identifiers expressed in the familiar dotted-decimal notation.
Support for Multiple Instances Per Link
OSPFv3 includes support for multiple instances of OSPF running in parallel across a common link. This is especially handy for shared network segments such as those found in Internet exchange points. On Cisco IOS, OSPFv3 instances are configured by appending the
instance argument to the
ipv6 ospf statement:
Router(config-if)# ipv6 ospf 100 area 0 instance 1
Removal of OSPF-specific Authentication
OSPFv2 authentication is achieved by implementing a shared secret and MD5 HMAC supported as part of the OSPFv2 protocol. OSPFv3 does away its own support for authentication entirely, instead relying on the more flexible IPsec framework offered by IPv6. For more detail on how OSPFv3 authentication is configured, see OSPFv3 authentication.
Improved Handling of Unknown LSA Types
OSPFv2 routers simple discard LSAs of an unknown type. OSPFv3 LSAs may be discarded, or optionally stored and flooded as though they were understood. Which action is taken is determined by the most-significant bit (the U bit) in the LSA type number. This option allows for the introduction of new LSA types across OSPF networks where only some routers support the new types.
Cisco IOS Configuration Differences
Cisco notes some differences in the way OSPFv2 and OSPFv3 are configured here. A brief summary:
- Enabling OSPF on an IPv6 interface automatically enables OSPFv3; an explicit OSPFv3 routing process does not need to be administratively created (though it likely still will be for other purposes).
- OSPFv3 interfaces must be designated under interface configuration; there is no option to designate interfaces using the
networkcommand under router configuration.
- NBMA neighbors must be identified by link-local IPv6 address.
- Like OSPFv2, OSPFv3 will take its router ID from the highest-numbered IPv4 loopback interface; however, as this IPv4 address is likely irrelevant your IPv6 network, it is recommended to manually specify a router ID with the
router-idcommand under OSPFv3 router configuration.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Routing
March 2, 2010 at 6:31 a.m. UTC
March 2, 2010 at 1:38 p.m. UTC
Thanks a lot! I can get more out of your blog in 20 minutes than reading CP for two hours.
March 3, 2010 at 9:39 a.m. UTC
Nice one. Thanks
March 5, 2010 at 6:45 p.m. UTC
I'm currently in the process of introducing IPv6 in our network. We currently use OSPFv2 for our IPv4 network.
I was wondering if OSPV3 is exclusively used for IPv6 networks, maybe in conjunction with OSPFv2 for IPv4. Or if one could just use OSPFv3 for both IPv4 as well as IPv6.
If OSPFv3 uses ipv6 link local addresses, this probably means that all parts of the network need to support IPv6. Correct?
In our case I was wondering if we could migrate everything to OSPFv3 (ipv4 only) and then introduce IPv6. This would have the benefit of only one IP routing protocol. However doing it in this order would imply we need IPv6 support everywhere before deploying IPv6 (because of the link local requirement)?
March 5, 2010 at 7:58 p.m. UTC
@Dre: Currently, OSPFv3 only supports IPv6, however this is an Internet draft in the works to port IPv4 to the protocol as well to take advantage of its higher efficiency. The draft suggests the assignments of OSPFv3 instance ID ranges to specific address families (IPv6 unicast, IPv6 multicast, IPv4 unicast, and IPv4 multicast) not unlike MP-BGP.
For now I would suggest simply rolling out OSPFv3 in parallel to your OSPFv2 topology, but keep the draft's supposed instance ID allocations if you implement multiple instances of OSPFv3.
May 3, 2010 at 4:00 p.m. UTC
Really nice article, Stretch. However, i've spotted some little mistakes. You said that
One of OSPFv3's new LSAs, the Intra-area Prefix LSA (type 9), handles intra-area network information that was previously included in OSPFv2 type 2 LSAs.
Actually Intra-area Prefix LSA handles prefix information that is included in the OSPFv2 Router and Network LSA's. And also, about NBMA networks, you identify neighbor by it's link-local address not RID.
November 15, 2010 at 12:33 p.m. UTC
Hi, Whats exact usage of Instance ID in OSPFv3?? can a link can be given two different instance id in the same area .. or it is mandatory that it should in different area?
December 8, 2010 at 4:12 a.m. UTC
Hi, Whats exact usage of Instance ID in OSPFv3? Will there be separate routing table for each instance? if yes, then how data packets ll access that particluar Routing Table? I mean whether data packets can too support instance id.. ?
November 17, 2011 at 10:51 a.m. UTC
Rob: "Thanks a lot! I can get more out of your blog in 20 minutes than reading CP for two hours." - Second that!! Thanks.
Challenge question: How many bytes in length a UDP header? Another search on Google!!
February 20, 2013 at 7:49 p.m. UTC
really nice blog...can you explain the use of fragment id??
May 15, 2014 at 9:41 a.m. UTC
Informative, thanks a lot stretch.
March 23, 2016 at 2:29 a.m. UTC
"cisco multiple instances of OSPFv3 can be run on a link" Please advise I'm trying to create multiple instances under interface using ospfv3 with 2 pocess ID's, but as soon I add a new instance the old one -config disappears.