Understanding and Troubleshooting OSPFv3

OSPFv3 is defined in RFC 2740 and is the counterpart of OSPFv2, but is designed explicitly for the IPv6 routed protocol. The similarities shared by OSPFv2 and OSPFv3 are as follows:

• OSPFv3 continues to use the same packets that are also used by OSPFv2
• Neighbor discovery and the adjacency formation process are the same
• OSPFv3 still maintains RFC-compliant on different technologies
• Both OSPFv2 and OSPFv3 use the same LSA flooding and aging mechanisms
• Like OSPFv2, the OSPFv3 router ID still requires the use of a 32-bit IPv4 address
• The OSPFv3 Link ID is still based on a 32-bit IPv4 address like OSPFv2

While there are similarities between OSPFv2 and OSPFv3, it is important to understand that there are also some significant differences that you must be familiar with. These include:

• OSPFv3 uses the IPv6 link local not Global addresses to identify the OSPFv3 adjacencies
• OSPFv3 introduces two new OSPF LSA types which are Type 8 and Type 9 LSAs
• OSPFv3 messages are sent over (encapsulated in) IPv6 not IPv4 packets
• OSPFv3 uses standard IPv6 Multicast addresses FF02::5 and  FF02::6
• OSPFv3 leverages the inbuilt capabilities of IPSec for security and authentication

The Options field in Hello and DBD packets include the R-bit and the V6-bit

The OSPFv3 Hello contains no address information, but includes an Interface ID

NOTE: Additional detailed information on these differences and similarities can be found in the current ROUTE guide which is available online.

For all intents and purposes, and barring configuration differences, the same methods used to troubleshoot OSPFv2 are applicable when troubleshooting OSPFv3 because the protocols operate in the same manner. When troubleshooting OSPFv2, Cisco IOS software OSPF commands begin with show ip ospf. In a similar manner, the OSPFv3 show commands begin with show ipv6 ospf. This command supports the following keywords:

NOTE: The majority of the supported keywords are described in greater detail in the ROUTE exam guide which is available online. Please refer to that guide for additional information on the keywords that are not described in this section. It should also be noted that keywords that are beyond the scope of ROUTE and TSHOOT are not discussed in either study guide.

A commonly used troubleshooting command is the show ipv6 ospf <process> command. This command can be used to verify router configuration, e.g. ABR and ASBR configuration, verify the areas configured as well as the types, e.g. Stub, NSSA. Additionally, you can use this command to determine the number of times the SPF algorithm has been run in certain areas, which is useful for troubleshooting issues such as link route flapping, for example. The output that follows shows the information that is provided by this command:

From the output printed above, we can determine the RID of the local router as well as the local OSPF process. Additionally, we can also determine that the router is an ABR and ASBR, which is redistributing two different RIPng instances. By default, Cisco IOS will list the protocol name one for each instance that is redistributed into OSPF. For example, if the local router was redistributing three different RIPng instances, the word ‘rip’ listed under the redistribution column would be printed three times. Additionally, we can also determine the number of external LSAs as well as the default reference bandwidth. And finally, the different areas, the number of interfaces in those areas, and the number of times the SPF algorithm has been executed for each individual area is also included in the output that is printed by this command.

The border-routers keyword allows you to display internal OSPF routing table entries to an ABR and ASBR. As is the case with OSPFv2, this command is useful when troubleshooting connectivity issues to other areas in multi-area OSPF implementations because it can be used to confirm that the local router has a path to the ABR and ASBR (if applicable) as shown below:

In addition to verifying routes to ABR and ASBRs, the show ipv6 ospf border-routerscommand can also be used to determine if the SPF calculation is functional because it also includes the internal number of the SPF calculation that installed the route.

As is the case with OSPFv3, you can append the database keyword to view the contents of the LSDB. When viewing the OSPFv3 LSDB, keep in mind that this updated version of the OSPF routing protocol includes two new LSAs, which are Type 8 (Link LSA) and Type 9 (Intra-Area Prefix LSA). The Link-LSA provides the router’s Link-Local address and provides all the IPv6 prefixes attached to the link. There is one Link-LSA per link. There can be multiple Intra-Area-Prefix LSAs with different Link-State IDs. The Area flooding scope can therefore be an associated prefix with the transit network referencing a Network LSA or it an associated prefix with a router or stub referencing a Router LSA. Following is a sample of the OSPFv3 LSBD:

And finally, the show ipv6 ospf neighbor [detail] command is still a useful command when troubleshooting and verifying neighbor adjacencies. When using this command keep in mind that even though it is applicable to OSPFv3, the command output will include IPv4 router IDs, since these are also used by OSPFv3. Following is a sample output of the information that is printed by this command:

In addition to show commands, you can also the clear ipv6 ospf suite of commands to troubleshoot OSPFv3. The options that are available with this command are listed below:

When using the clear ipv6 ospf suite of commands, you can specify the process number you want the relevant keyword applied to. This is useful when you are performing OSPFv3 troubleshooting on a router running multiple processes and do not want to impact any of the other processes running on the router.

The counters keyword clears state change counters for the OSPFv3 neighbor(s) on a specified interface, if one is specified in conjunction with this command, for the specified OSPFv3 neighbor, if the neighbor ID is included, or for all of the OSPFv3 neighbors. The example that follows illustrates how to first verify, clear or reset, and then verify again the state change counters for neighbors off a specified interface:

Clearing counters is useful when troubleshooting adjacency flaps as it provides some indication as to how frequently they are occurring. You can then correlate this information with other events, such as Syslog messages or periods of high CPU utilization for example, when you are troubleshooting OSPFv3 problems.

The force-spf keyword simply runs the SPF algorithm again. The main difference between theclear ipv6 ospf force-spf command and the clear ipv6 ospf process command is that theclear ipv6 ospf process command will restart the OSPF process, clear the OSPFv3 database, repopulate the database, and then run the SPF algorithm. This difference in operation can be validated by enabling OSPFv3 debugging and comparing the difference in output when either command is issued. The following output shows the events that occur when the clear ipv6 ospf force-spf command is issued on the router:

Using the same debugging commands, the following shows the impact of issuing the clear ipv6 ospf process command on the same router:

In essence, the clear ipv6 ospf force-spf command has less impact on OSPFv3 than the clear ipv6 ospf process command because it starts the SPF algorithm without clearing the OSPF database. Clearing the database on a core router in the network can have a drastic impact on the network. For this reason, the clear ipv6 ospf process command should be used with caution. The same is also applicable to the clear ip ospf process command. Therefore, consider using the clear ip ospf force-spf command instead.

And finally, the redistribution keyword clears OSPFv3 redistribution. This is used when you are troubleshooting route redistribution into OSPF from other routing protocols. This command flushes and reinstalls all external LSAs; however, the when this command is issued, the SPF algorithm is not run again.

In conclusion, akin to using the debug ip ospf command to view real-time OSPFv2 events, you can use the debug ipv6 ospf command to view real-time OSPFv3 events. This command supports the same options as debug ip ospf the command. While additional OSPFv3-specific keywords, such as ipsec (for IPsec event debugging) are included, most of these options are similar to those used with OSPFv2 and perform the same function. The following shows the available options that can be included when you are debugging OSPFv3: