This latest lab asks you to configure OSPFv3 to exchange routes in an IPv6 network. Amazingly, you can almost ignore the IPv6 addresses, at least once you believe that the addresses have been pre-configured, as is the case in this lab. Jump into the lab, create your own answers, and then come back to this post to check your work.
Answers
Figure 1: Four Router with Unicast IPv6 Addresses
Example 5: R1 Config
interface GigabitEthernet0/1 ipv6 ospf 10 area 0 ! interface GigabitEthernet0/2 ipv6 ospf 10 area 0 ! interface GigabitEthernet0/3 ipv6 ospf 10 area 0 ! ipv6 router ospf 10 router-id 1.1.1.1 maximum-paths 1
Example 6: R2 Config
interface GigabitEthernet0/1 ipv6 ospf 10 area 0 ipv6 ospf cost 10 ! interface GigabitEthernet0/2 ipv6 ospf 10 area 0 ! ipv6 router ospf 10 router-id 2.2.2.2
Example 7: R3 Config
interface GigabitEthernet0/1 ipv6 ospf 10 area 0 bandwidth 10000 ! interface GigabitEthernet0/2 ipv6 ospf 10 area 0 ! ipv6 router ospf 10 router-id 3.3.3.3
Example 8: R4 Config
interface GigabitEthernet0/1 ipv6 ospf 10 area 0 ipv6 ospf 10 cost 10 ! interface GigabitEthernet0/2 ipv6 ospf 10 area 0 ! interface GigabitEthernet0/3 ipv6 ospf 10 area 0 bandwidth 10000 ! ipv6 router ospf 10 router-id 4.4.4.4
Commentary
First, for the requirement to enable OSPFv3, scan all four example configurations, looking for the following:
- All four routers create the OSPFv3 process, with process ID 10 (ipv6 ospf router 10), and with an obvious router ID (router-id value), in the last few lines of each example. Note that if you followed the lab literally, the initial configuration had no IPv4 configuration, so OSPFv3 would require the explicit configuration of a router ID, because none of the routers have a IPv4 address to use to create the OSPFv3 router ID.
- All interfaces include the ipv6 ospf 10 area 0 subcommand, enabling that OSPFv3 process on each interface.
- Note that while all four routers used the same OSPFv3 process ID (10), they did not have to all use that number as the lab did not specify that they had to match.
Beyond that base configuration, the labs asks you to change metrics. By default, OSPFv3’s metric works like normal OSPF; it is calculated using the bandwidth. The default metric formula is 100 Mbps/interface_bandwidth. Notice that the default metric still uses 100 Mbps as a reference, this can be a problem on a modern network where gigabit (and faster) interfaces are common. Left unchanged, in any topology with only FastEthernet and faster interfaces, all the OSPF interface costs would tie at 1. Notably, the OSPFv3 (and OSPFv2) metric for a FastEthernet interface is the same as the metric for a GigabitEthernet interface.
To change the OSPFv3 interface costs as requested:
- R2 and R4 use the ipv6 ospf cost 10 command on the correct interfaces, directly setting the cost.
- R3 and R4 use the bandwidth 10000 command on the correct interfaces. This means “10,000 Kbps”, or 10 Mbps. In terms of calculating the OSPF cost indirectly, by default, the math is 100Mbps/Bandwidth, or 100/10, for an OSPFv3 interface cost of 10.
Finally, R1 will calculate two routes to 3500::/64. Both will have a cost of 12, with a default cost of 1 on two links, and the cost of 10 on one link as set earlier. However, the maximum-paths 1 command on R1 will cause R1 to use only one of these routes.