OSPFv2 vs OSPFv3

Lessons Discussion
14

Hello Giovanni

Ah, I see, thanks for the clarification. One of the advancements of OSPFv3 over OSPFv2 is the use of the instance ID. This instance ID is an 8 bit field within the OSPFv3 header.

The original intent for the instance ID was to support multiple instances of OSPFv3 to run on the same interface. In this way, you can manipulate which routers on a particular segment are allowed to form adjacencies. You could use an instance number of 0 through 255 to distinguish between the different OSPFv3 instances.

However, within RFC 5838, the instance ID was re-purposed to be used to support address families (AFs) with OSPFv3. The default instance of 0 is used if no other instance is defined. However, specific ranges of the instance ID map to specific AFs. According to the RFC, these ranges are:

  Instance ID # 0    -  # 31     IPv6 unicast AF
  Instance ID # 32   -  # 63     IPv6 multicast AF
  Instance ID # 64   -  # 95     IPv4 unicast AF
  Instance ID # 96   -  # 127    IPv4 multicast AF
  Instance ID # 128  -  # 255    Unassigned

As you can see, 0-31 matches with the available values for the command using IPv6 unicast, while the same is true for IPv4 unicast. Note here that OSPFv3 runs on top of IPv6 and uses IPv6 link-local addresses to form OSPFv3 adjacencies. However, OSPFv3, using these instance IDs can now advertise IPv4 routes too. Note also that Cisco routers do not support multicast OSPF, so you don’t see those instance ID values at all in any of the Cisco configuration options.

Using instances within the same process simply allows you to create a more hierarchical routing environment. Within the same segment, you can choose which routers create adjacencies and which do not. You can essentially create a more granularly configurable routing protocol. The truth is that such configurations are highly specialized and generally rare. Because of this, the instance ID was leveraged for use with multiple AFs.

I hope this has been helpful!

Laz

1 Like