This section discusses the concepts and implementation of OSPFv3 in somewhat detail due to greater emphasis on IPv6 in CCNA version 2 exams.
The following steps are involved in the OSPFv3 configuration on a Cisco router:
- Enable IPv6 routing using the ipv6 unicast-routing command from global configuration mode.
- Create an OSPFv3 routing process and enter OSPFv3 configuration mode using the ipv6 router ospf process-id from global configuration mode.
- Make sure that the router obtains an OSPFv3 router ID through one of available mechanisms for this.
- Enable OSPFv3 on interfaces using the ipv6 ospf process-id area area-number command in interface configuration mode, thus also setting the OSPFv3 area for the interface.
In addition to the four steps, you may also configure one or more OSPFv3 interfaces as passive using the passive-interface interface-type interface-number command in router configuration mode.
The OSPFv3 coverage in the new CCNA version 2 exams is mostly limited to single-area scenarios. However, you may also encounter multi-area scenarios occasionally. That’s why we will also briefly cover multi-area concepts and configuration. If you understand single area concepts and configuration well, you will usually find it easy to understand multi-area details.
OSPFv3 Single-Area Configuration
We will present complete IPv6 configuration, including addressing and OSPFv3, on three routers in a single-area OSPFv3 domain, as shown in Figure 13-6.
Figure 13-6 OSPFv3 Single-Area Domain
The following configuration steps are performed on each router, in accordance with Figure 13-6:
- Enable IPv6 routing
- Create an OSPFv3 process with ID 1
- Explicitly define OSPFv3 RID
- Enable OSPFv3 on interfaces, placing all interfaces in area 0
The ipv6 router ospf process-id command creates the OSPV3 process and gives it a number called process ID. We have used the same process ID on all three routers, but please keep in mind that OSPFv3 process ID is only locally important. We could have used difference process IDs on routers without any problems. In practice, most enterprises would use the same process ID on all routers for the sake of consistency.
The ipv6 ospf process-id area area-id enables OSPFv3 on individual interfaces also assigning the area number. In this case, we are configuring a single-area OSPFv3 domain so all interfaces in all routers are placed in area 0, the backbone area.
There is one completely optional feature that is relevant to your CCNA version 2 exams: OSPFv3 passive interface. This feature is quite similar in concepts and configuration to its OSPFv2 counterpart. If you want a router not to form OSPFv3 neighbor relationships on an interface, that interface may be made passive. In this case, we do not want any interface to passive as we want each router to make two OSPFv3 neighbor relationships, so there is no passive interface configuration.
Finally, you need to configure OSPFv3 RID (router ID) to identify the router in the OSPFv3 routing domain. In this case, we set the OSPFv3 router ID on all three routers using the router-id command in router configuration mode.
OSPFv3 Multi-Area Configuration
We will now build on the single-area configuration to create a multi-area OSPFv3 configuration as shown in Figure 12-x. The router R1 is the ABR (area border router), with OSPFv3 process ID 1, and OSPFv3 enabled on four interfaces:
- Area 0: Serial0/0 and Serial0/1
- Area 1: FastEthernet0/0
- Area 14: FastEthernet0/1
There is nothing in the configuration of R1 that explicitly sets it as ABR. We will configure interfaces of R1 in different OSPFv3 areas automatically making R1 and ABR. We will also configure FastEthernet0/0 of R1 as passive because there are no OSPFv3 routers off this interface and R1 will not make any neighbor relationships on this interface any way.
Figure 13-7 OSPFv3 Multi-Area Domain
We add two OSPFv3 areas and a single OSPFv3 router R4 to the single-area scenario presented in the last section, as shown in Figure 14-7. You have to perform additional configuration on FasEthernet0/0 and FastEthernet0/1 of R1. You also have to configure R4 from scratch assigning OSPF areas to interfaces as shown in Figure 13-7. We will configure FastEthernet0/0 of R4 as passive as there are not any OSPFv3 neighbors off this interface.
Additional OSPFv3 Configuration
The core OSPFv3 configuration is complete by now. However, we will configure some additional OSPFv3 features that are very similar to corresponding OSPF features for IPv4.
OSPFv3 Interface Cost
OSPFv3 is very much like OSPFv2 when it comes to calculation of route metric, with minor differences in concepts, configuration commands, and verification commands.
The SPF (shortest path first) algorithm on a router finds all possible routes to a subnet and then calculates the cost of each route by adding the OSPF interface cost for all outgoing interfaces on the path from the router to the subnet. You can influence OSPFv3 route selection using methods that are just similar to the corresponding rules for OSPFv2:
- Set the interface cost explicitly using the ipv6 ospf cost x command in interface configuration mode. The permissible values of interface cost are between 1 and 65,535, both inclusive.
- Change the nominal interface bandwidth in kbps (kilo bits per second) using the bandwidth speed command, and let the router calculate the OSPFv3 interface cost by the formula reference-bandwidth / interface-bandwidth.
- Change the reference bandwidth in Mbps (mega bits per second) for the interface cost calculation formula, using the auto-cost reference-bandwidth ref-bw command.
OSPFv3 Load Balancing
The OSPFv3 load balancing concept is again similar to the corresponding OSPFv2 concept. Also, the exact same command is used to make equal-cost load balancing happen. When an OSPFv3 router has multiple routes to reach one subnet, each with the same metric, the router can put multiple equal-cost routes in the routing table. The maximum-paths number command is used in router configuration mode to define just how many such routes can be added by OSPFv3 to the IPv6 routing table. For example, if a network has six equal-cost routes, and you want all routes to be used, you should configure the router with maximum-paths 6 subcommand under the ipv6 router ospf command.
Injecting Default Routes
OSPFv3 can advertise a default route and the feature again works much like OSPFv2. This feature allows an OSPFv3 router to have a default route and then tell all other routers, to use that default route.
If a company has a single IPv6 enabled Internet connection, it can use a default IPv6 route to send all IPv6 traffic out that one link to the Internet. All the internal routers need to send traffic to the single Internet facing router:
- All routers learn specific routes to subnets inside the company network, so the default route is not used for destinations inside the company.
- The router facing the Internet has a static default IPv6 route that points all IPv6 traffic not matching any other specific route to the Internet.
- All routers learn the default route from the Internet facing routers over OSFPv3 and send all IPv6 packets not matching specific routes to the Internet facing router that, in turn, sends them to the Internet.
The default-information originate command is used in OSPFv3 configuration mode to originate a default route from the router facing the Internet. The IPv6 default route is represented as ::/0 with a prefix length 0, and it is analogous to the 0.0.0.0/0, the default route used with IPv4.
This completes our discussion of OSPFv3 configuration. You may have noticed that we frequently referred to OSPFv2 when introducing OSPFv3 concepts. The reason was that OSPFv3 is so similar to OSPFv2 with certain differences in some areas. It is probably the right time to recap the similarities and differences between OSPFv3 and OSPFv2.
OSPFv3 works much like OSPFv2 with regard to:
- Design of areas and related terminology.
- The general idea of enabling the OSPF process and assigning areas to individual router interfaces.
- The neighbor discovery process making use of Hello messages
- Transitioning through neighbor states and echange of topology information through LSAs (Link State Advertisement)
- The role of full and 2-way states as the normal stable states for functional neighbor relationships, with other states being temporary pointing to some problem.
- The ideas of Type 1, 2, and 3 LSAs and the LSDB (link-state database).
- The formula used by SPF (shortest-path first) algorithm to calculate interface cost.
- OSPF messages sent to reserved multicast addresses (FF02::5 for all OSPFv3 routers and FF02::6 for all DR/BDR routers) similar to the use of 126.96.36.199 and 188.8.131.52 with OSPFv2.
You understand now how similar the two protocols are, but still they are not exactly the same. There are many differences as presented in the following list, but the good news for you as a CCNA candidate is that most of the differences are outside the scope of this book and your CCNA exams:
- The Type 3 LSA name.
- The OSPFv3 neighbors do not have to have their IPv6 addresses in the same IPv6 subnet, while OSPFv2 neighbors must have their IP addresses in the same subnet to form neighbor relationships.
- There are some new LSA types used by OSPFv3 only and not by OSPFv2, but these are beyond scope as we mentioned.
- The details inside LSA types 1, 2, and 3 are also different for OSPFv3 and OSPFv2 but these are again outside scope here.
So, as you can see there are more similarities than differences and the few differences that exist are also out of scope for your CCNA exams. So you can reuse most of your OSPFv2 concepts for OSPFv3.
In the next section, we will cover OSPFv3 verification and troubleshooting with associated concepts.
OSPFv3 Verification and Troubleshooting
The OSPFv3 show commands used for verification and troubleshooting are also very similar to OSPFv2 commands mostly the ip keyword getting replaced by ipv6. When the OSPFv3 process first comes up on a router, the IOS reads the OSPFv3 configuration and then enables OSPFv3 on interfaces. So, we will start our OSPF verification and troubleshooting by examining OSPFv3 interfaces. If the interfaces look good, you can move on to OSPFv3 neighbors, and then to the OSPFv3 topology database, and finally to OSPFv3 routes added to the IPv6 routing table.
For verification and troubleshooting examples, we will use the OSPFv3 multi-area topology presented and configured earlier in this chapter.
The ip ospf process-id area area-id command is used in interface configuration mode to make OSPFv3 run on an interface. You can quickly scan the output of show running-config to identify the OSPFv3 interfaces as well as the area number for each.
You can be much more effective at verification and troubleshooting by using the respective show commands than trying to read the configuration. And that’s not the only reason to favor specific show commands over the show running-config command. Many simlet questions on the CCNA exams do not even let you into the enable mode of the router, so you just cannot use the show running-config command to see the configuration. So, if you think your good configuration skills alone can help you verify and troubleshoot OSPFv3 for CCNA, think again.
There are three show commands that can provide you useful information about interfaces enabled for OSPFv3:
- show ipv6 protocols
- show ipv6 ospf interface brief
- show ipv6 ospf interface
All three commands list the interfaces, both non-passive and passive, on which OSPFv3 has been enabled, but with different level of details. In our case, there is no passive interface, but you can make any interface passive by using the passive-interface command in interface configuration mode.
As you can see from the output of show ipv6 protocols command above, four interfaces of R1 with associated areas are listed.
Most OSPFv3 problems are caused by mistakes in configuration that prevent routers from making neighbor relationships. Some of the configuration mistakes you can encounter are:
- Configuring the wrong area with the ip ospf process-id area area-id command in the interface configuration mode, prevents the router from making OSPFv3 neighbor relationships off that interface.
- Making an OSPFv3 interface passive by mistake can prevent the router from making neighbor relationships off such interface.
You must understand that all routers on the same data link must be assigned to the same OSPFv3 area in order to form neighbor relationships. In order to find out which interfaces have actually been assigned to which area, you should use the show ipv6 ospf interface brief and show ipv6 ospf interface commands. Also, you should not make an interface passive if you want the router make neighbor relationships off that interface. The show ipv6 ospf interface command can also tell you which OSPFv3 interfaces happen to be passive at the time.
The FastEthernet0/0 of R1 is configured as passive but what if you configured FastEthernet0/1 instead of FastEthernet0/0 as passive, by mistake. Let’s do the mistake and see what happens.
As soon as you make FastEthernet0/1 passive, the neighbor relationship with R4 is lost. That’s the reason you should make only that interface passive that has no other OSPFv3 routers connected to it.
The OSPFv3 neighbors also function like OSPFv2 neighbors following course. The same concepts, message names, and neighbor states are used by OSPFv3. In this section, we look at issues related to OSPFv3 neighbor relationships, especially the issues that prevent routers from becoming neighbors.
When you are examining the output of debug commands we present, do not get overwhelmed by details, as you don’t have to understand all of them at this point. Just focus on the highlighted portions for relevant and familiar concepts. First, we show the output of debug ipv6 ospf adj command executed on R1, which lists OSPFv3 adjacency messages as the router marches through various adjacency states with R4 off interface FastEthernet0/1. We highlight some of the OSPFv3 neighbor states like 2-way, exstar, exchange, loading, and full that is final desired state.
We can use the show ipv6 ospf neighbor command to confirm if R1 has established neighbor relationship with R4.
As you can see, R4 has stabilized in a full neighbor state with R1. In fact working OSPFv3 neighbors, just like OSPFv2) will stabilize in either a full state or a 2-way state. A neighbor reaches full state when it has fully exchanged its LSDB (link-state database) to/from a neighbor. However, for OSPF network types that use a DR (designated router) or BDR (backup designated router), only the DR and BDR reach full neighbor relationships with DROthers (routers that are neither DR nor BDR). Neighbor relationships between two DROther routers will stabilize in a 2-way state only and will not reach the full state.
If you ever find yourself in a situation where OSPF fails to learn routes that it should be learning, you should look at the expected OSPFv3 neighbor relationships using show commands. If you find a relationship that either does not exist or does not exist in the right state (full or 2-way), you can troubleshoot the reasons that prevent neighbor relationships from forming.
Table 13-4 Neighbor Requirements for OSPFv2 and OSPFv3
|Interfaces must be in up/up state||Yes||Yes|
|Interfaces must be in the same subnet||Yes||No|
|Hello and dead timers must match||Yes||Yes|
|Router IDs must be unique||Yes||Yes|
|Process ID must be the same on both routers||No||No|
|Must pass routing protocol authentication (if configured)||Yes||Yes|
|Interfaces must not be passive||Yes||Yes|
The neighbor requirements listed in Table 13-4 must all be met for neighbor relationships to successfully form. You can use the commands listed in Table13-5 below to quickly find out which setting is preventing neighbor relationships from forming.
Table 13-5 Commands to Verify Neighbor Requirements
|Neighbor Requirement||Best Command for Fault Isolation|
|Interfaces must be in up/up state||show ipv6 interface brief|
|Interfaces must be in the same subnet||show ipv6 interface|
|Hello and dead timers must match||show ipv6 ospf interface|
|Router IDs must be unique||show ipv6 ospf|
|Must pass routing protocol authentication||show ipv6 ospf interface|
|Interfaces must not be passive||show ipv6 ospf interface|
OSPFv3 LSDB (Link-state Database)
OSPFv3 routers exchange their LSDBs, made up of LSAs (link-state advertisement), as part of the OSPFv3 adjacency establishment process. Once the two routers are in the full state, they should have exactly the same LSAs for that area in their LSDBs. In this section, we take a brief look at the LSDB and LSAs in an area and also some configuration issues that can cause the LSA exchange process to fail prematurely.
OSPFv3 uses the Type 1 router LSA and Type 2 network LSA to define the topology inside an area just like OSPFv2. The Type 3 LSA describes an inter-area subnet, that is, a subnet that exists in some other area. OSPFv3 renames the Type 3 LSA to inter-area prefix LSA as compared to OSPFv2. For the sake of your CCNA exams, you are normally concerned with only these three types of LSAs:
- Type 1 LSA (Router LSA): Each router generates one Type 1 LSA in its area. An ABR is connected to more than one areas, so it generates one Type 1 LSA for each area it’s connected to.
- Type 2 LSA (Network LSA): One Type 2 LSA is generated for each network that has a DR plus at leaset one neighbor of the DR. The DR is responsible for generating a Type 2 LSA for the subnet it acts as the DR for.
- Type 3 LSA (Inter Area Prefix LSA): The ABR generate one Type 3 LSA for each IPv6 subnet (prefix) that exists in a different area.
The following graphic demonstrates these LSA concepts for area 14 in the multi-area OSPFv3 topology presented earlier in the chapter.
Figure 13-8 OSPFv3 LSDB
R1 and R4 are the only two routers in area 14 and each generates one Type 1 LSA. There is a single subnet (between R1 and R4) in area 14 that has a DR, so a single Type 2 LSA is generated by the DR, that is, R4 for that subnet. Finally, the router R1 being the ABR generates four Type 3 LSAs into area 14 to represent four subnets (prefixes) in areas 0 and 1 .
You can actually view the LSAs shown in the graphic above using the show ipv6 ospf database command:
OSPFv3 Metrics and Routes
OSPFv3 is a dynamic routing protocol for IPv6 and all the end goal of OSPFv3 like any other routing protocol is to have viable routes that you can actually install in the routing table for actual forwarding of packets.
The SPF algorithm considers all the paths or routes available on the local router to reach each and every subnet. When there are more than one available routes on the local router to reach a remote subnet, the SPF algorithm must select the best route based on the lowest metric. The best route selected by OSPFv3 on the basis of lowest metric is then added to the IPv6 routing table.
When you display the IPv6 routing table, the metric for the route is second of the two numbers in square brackets for the route. The first number in brackets is the AD (administrative distance) that is 110 for OSPFv3 as well as OSPFv2. In fact, all IPv6 routing protocols use the same AD values as their IPv4 counterparts. You can view the IPv6 routing table using the show ipv6 route command:
The router R1 has two routes to the IPv6 subnet 2001:DB8:1:23::/64, as shown in the above output. One route goes through R2 off interface Serial0/0 while the other goes through R3 off interface Serial0/1. The default setting of maximum-paths 4 allows for up to four equal cost routes to be installed in the routing table. There is no surprise that two routes to the subnet can be seen in the IPv6 routing table of R1. You may have noticed that link-local addresses for the next hop are used in the routing table.
Let’s focus on the router R2 now that has two possible paths to reach the subnet 2001:DB8:1:1::/64. The first path goes directly through R1 while the second path takes the longer route through R3 and R1 to reach the subnet.
The OI code at the left of the subnet identifies the method used to learn the router. The O identifies the route as being learned by OSPFv3, and the I indicates the route as an inter-area route.