As you have seen in previous chapters, routing IPv6 requires modifications to a protocol; primarily, the protocol messages must be modified to carry addresses four times as long as IPv4 addresses. In theory, this also could be done with Open Shortest Path First (OSPF), either by modifying the existing Link State Advertisements (LSA) or by defining new LSAs. But development of OSPF began in the very late 1980s, when router performance was low, latency was high, and memory was expensive. None of these are valid now, and several characteristics of OSPFv2 that were intended to accommodate or compensate for those early networking realities are now irrelevant. Further, extensive operational experience with OSPFv2 revealed several areas of inefficiency.
So when extension of OSPF to support IPv6 was first considered, it was recognized that there was an opportunity to improve the protocol itself. The result is that rather than just extending OSPFv2 for IPv6, a new and improved version of OSPF—OSPF version 3—has been created.
OSPFv3 is specified in RFC 2740. There are some high-level similarities between the relationships of RIPng to RIPv2 and OSPFv3 to OSPFv2. Most important, OSPFv3 uses the same fundamental mechanisms as OSPFv2—the SPF algorithm, flooding, DR election, areas, and so on. Constants and variables such as timers and metrics are also the same.
Another similarity to the relationship of RIPng to RIPv2 is that OSPFv3 is not backward-compatible with OSPFv2. So if you want to use OSPF to route both IPv4 and IPv6, you must run both OSPFv2 and OSPFv3. As this chapter is being written, there is discussion of adding IPv4 support to OSPFv3, but no specifications have yet been completed. I, for one, hope this support is added, because OSPFv3 is a significantly improved protocol.
It is assumed that you have read the previous chapter and understand the operation of OSPFv2. This section does not repeat that information, but presents the significant differences—primarily operational and LSA formats—of OSPFv3.
In addition to the changes in LSAs, described in the next section, there are several changes to OSPF procedures themselves. This section describes the most important of those changes:
Per link protocol processing—. You have already seen that an interface to a link can have more than one IPv6 address. In fact, a single link can belong to multiple subnets, and two interfaces attached to the same link but belonging to different IPv6 subnets can still communicate. OSPFv3 changes the OSPFv2 language of “subnet” to “link,” and allows the exchange of packets between two neighbors on the same link but belonging to different IPv6 subnets.
Removal of addressing semantics—. As you will see in the subsequent sections, OSPFv3 Router and Network LSAs do not carry IP addresses. A new LSA is defined for that purpose. This has some scaling advantages. However, 32-bit RIDs, AIDs, and LSA IDs are maintained in IPv6. Keep in mind that although these IDs are written in dotted decimal, and are often derived in OSPFv2 networks from working IPv4 addresses, they are not IPv4 addresses. These OSPFv3 IDs are still expressed in dotted decimal, allowing easy overlay of an OSPFv3 network on an existing OSPFv2 network.
Neighbors are always identified by Router ID—. OSPFv2 neighbors on broadcast and NBMA links are identified by their interface addresses, whereas neighbors on other types of links are identified by RID. OSPFv3 removes this inconsistency, so that all neighbors on all link types are identified by RID.
Addition of a link-local flooding scope—. OSPFv3 retains the domain (or AS) and area flooding scopes of OSPFv2, but adds a link-local flooding scope. You already know—particularly from Chapter 2, “IPv6 Overview”—that IPv6 makes much use of the link-local scope. As you will see in the subsequent sections, a new LSA—the Link LSA—has been added, for carrying information that is only relevant to neighbors on a single link. This LSA has link-local flooding scope, meaning it cannot be flooded beyond any attached router.
Use of link-local addresses—. You already know that OSPFv2 packets have a link-local scope; they are not forwarded by any router. OSPFv3 uses a router’s link-local IPv6 address (recall from Chapter 2 that these addresses always begin with FF80::/10) as the source address, and as next-hop addresses.
Support for multiple instances per link—. There are applications in which multiple OSPF routers can be attached to a single broadcast link but should not form a single adjacency among them. An example of this is a shared Network Access Point (NAP). For example, suppose four routers are attached to an Ethernet link. Routers 1 and 2 belong to one OSPF domain, and routers 3 and 4 belong to a different OSPF domain. There should be adjacencies between 1 and 2 and between 3 and 4, but not, for instance, between 1 and 3. You can accomplish this kind of separation of adjacencies with OSPFv2 by manipulating authentication, but it is not ideal. Among other things, the routers belonging to one adjacency will be continuously logging authentication failures from the rejected Hellos of the other adjacency. OSPFv3 allows for multiple instances per link by adding an Instance ID to the OSPF packet header to distinguish instances. An interface assigned to a given Instance ID will drop OSPF packets whose Instance ID does not match.
Removal of OSPF-specific authentication—. IPv6 has, using the Authentication extension header, a standard authentication procedure. Because of this, OSPFv3 has no need for its own authentication of OSPFv3 packets; it just uses IPv6 authentication.
More flexible handling of unknown LSA types—. Where OSPFv2 always discards unknown LSA types, OSPFv3 can either treat them as having link-local flooding scope, or store and flood them as if they are understood, while ignoring them in their own SPF algorithms. This can result in easier network changes and easier integration of new capabilities in OSPFv3 than in OSPFv2.
OSPFv2 and OSPFv3 both have the same protocol number of 89, although OSPFv3, being an IPv6 protocol, more accurately has a Next Header value of 89. And like OSPFv2, OSPFv3 uses multicast whenever possible. The IPv6 AllSPFRouters multicast address is FF02::5, and the AllDRouters multicast address is FF02::6. Both have link-local scope. You can easily see the similarity in the last bits with the OSPFv2 addresses of 224.0.0.5 and 224.0.0.6.
OSPFv3 uses the same five message types—Hello, DD, LS Database Request, LS Database Update, and LS Acknowledgment—as OSPFv2, and numbers them the same. The message header, shown in Figure 9-1, is somewhat different from the OSPFv2 message header. The version number, of course, is 3 rather than 2. But more important, there are no fields for authentication. As discussed in the previous section, OSPFv3 uses the Authentication extension header of the IPv6 packet itself rather than its own authentication process. And there is an Instance ID, which allows multiple OSPFv3 instances to run on the same link. The Instance ID has local link significance only, because the OSPFv3 message is not forwarded beyond the link on which it is originated.
Aside from the message header, the format of only two of the OSPFv3 messages is different from their OSPFv2 counterparts: Hellos and Database Description messages.
Figure 9-2 shows the format of the OSPFv3 Hello message. Unlike OSPFv2, there is no Network Mask field because IPv6 has no need for it. Beyond that, the same fields (below the header) appear in both packets. The Options field increases in size to 24 bits, and the Router Dead Interval is decreased from 32 bits to 16 bits. The implication of this second field is that the theoretical maximum Router Dead interval is decreased from 4.3 billion seconds to 65,535 seconds. This change has little or no bearing on operational networks. The maximum configurable Router Dead interval on the most common OSPF implementations has long been 65,535 anyway, and intelligent OSPF designs do not approach even this maximum; so the change in the field size is only for conservation of unused space.
Figure 9-3 shows the format of the OSPFv3 Database Description packet. It differs from its OSPFv2 counterpart only in the larger Options field.
The other three message types—Link State Request, Link State Update, and Link State Acknowledgment—have formats that do not differ from those of OSPFv2, and so are not shown in this chapter.
The OSPFv3 LSA header is shown in Figure 9-4. Comparing it with the OSPFv2 LSA header in Figure 8-54, you can see that it is almost identical, except that there is no Options field, and the Link State Type field is 16 bits rather than the 8-bit Type field of OSPFv2.
The reason that the Link State Type field is longer is that it includes three preceding bits, as shown in Figure 9-5.
U indicates how a router should handle the LSA if it does not recognize the LSA’s Function Code. If the bit is cleared, the unknown LSA is to be treated as if it had link-local flooding scope. If the U bit is set, the unknown LSA is to be stored and flooded as if it is understood.
S2 and S1 indicate the LSA’s flooding scope. Table 9-1 shows the possible values of these two bits and the associated flooding scopes.
LSA Function Code, the last 13 bits of the LS Type field, corresponds to the OSPFv2 Type field. Table 9-2 shows the common LSA types used by OSPFv3 and the values of their corresponding LS Types. If you decode the hex values, you will see that the default U bit of all of them is 0. The S bits of all LSAs except two indicate area scope. Of the remaining two, AS External LSAs have an AS flooding scope and Link LSAs have a link-local flooding scope. Most of the OSPFv3 LSAs have functional counterparts in OSPFv2; these OSPFv2 LSAs and their types are also shown in Table 9-2.
Table 9-2. OSPFv3 LSA types and their OSPFv2 counterparts.
OSPFv3 LSAs | OSPFv2 LSAs | ||
|---|---|---|---|
LS Type | Name | Type | Name |
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 |
0x0008 | Link LSA | No Corresponding LSA | |
0x2009 | Intra-Area Prefix LSA | No Corresponding LSA | |
Although Router and Network LSAs have the same names, there is a significant difference in how the OSPFv3 and OSPFv2 Router and Network LSAs function. Specifically, OSPFv3 Router and Network LSAs do not advertise prefixes. This is an important improvement in the scaling of the protocol. These LSAs are, as you know from Chapter 8, “OSPFv2,” primarily to represent the router as a node on the SPF tree. So when a Router or Network LSA is flooded, there is an assumption that a topological change has taken place and all routers in the area, on receipt of the LSA, rerun SPF. But because OSPFv2 routers also use these LSAs to advertise their connected subnets, if a subnet changes, the LSA must also be flooded to advertise the change. Even though something like an address change does not affect the SPF topology, the reception of a Router or Network LSA triggers an SPF run anyway. This can be particularly problematic for edge or access routers that have many stub links that change regularly.
OSPFv3 removes the prefix advertisement function from Router and Network LSAs, and puts it in the new Intra-Area Prefix LSA. Now Router and Network LSAs only represent the router’s node information for SPF and are only flooded if information pertinent to the SPF algorithm changes. If a prefix changes, or the state of a stub link changes, that information is flooded in an Intra-Area Prefix LSA that does not trigger an SPF run.
Another difference between Router and Network LSAs between OSPFv2 and OSPFv3 is in the exchange of some information that is only relevant to directly connected neighbors. OSPFv2 puts this information in Router or Network LSAs; and although only the directly connected neighbors care about the information, it is flooded with the LSAs throughout the area. OSPFv3 takes this neighbor-specific information and puts it in the new Link LSA, which has link-local flooding scope. Although minor, the introduction of the Link LSA does add an efficiency improvement over OSPFv2.
Inter-Area Prefix, Inter-Area Router, and Type-7 LSAs, although their names have changed, have the same function as OSPFv2 Network Summary, ASBR Summary, and NSSA LSAs, respectively. AS-External and Group Membership LSAs have both the same names and the same functions in both OSPFv2 and OSPFv3.
This section details the formats of the first five OSPFv3 LSA types, and the two new LSA types shown in Table 9-2. Although there is a specified Group Membership LSA for Multicast OSPF (MOSPF), that protocol is not covered in this book, and so the LSA is also not detailed. In most cases, only fields that differ from their OSPFv2 counterparts are discussed; you are encouraged to compare those LSAs that have corresponding OSPFv2 LSAs with the figures in Chapter 8.
Figure 9-6 shows the format of the OSPFv3 Router LSA. As discussed in the previous section, prefix information is not included in the Router LSA as it is in its OSPFv2 counterpart. The OSPFv3 Router LSA only describes the originating router and its links to neighbors, for use in SPF calculations. Prefix information is carried in the Intra-Area Prefix LSA.
Also notice that the ToS metric fields, obsolete already in OSPFv2, are not included in this LSA.
Options, although in a different position within the LSA format and a longer length (24 bits) than the OSPFv2 Options field, performs the same function of identifying optional capabilities. The Options field, carried in several packets and LSAs, is described separately in a later section.
Following the Options field is a set of fields that can appear multiple times, to describe each of the attached interfaces:
Type specifies the interface type. Table 9-3 lists the possible interface type values.
Metric specifies the outbound cost of the interface.
Interface ID is a 32-bit value distinguishing the interface from other interfaces on the originating router.
Neighbor Interface ID is the Interface ID advertised by neighbors on the link in their Hellos or, in the case of type 2 links, the Interface ID of the link’s DR.
Neighbor Router ID is the neighbor’s RID or, in the case of type 2 links, the DR’s RID.
The OSPFv3 Network LSA is shown in Figure 9-7. Functionally it is identical to the OSPFv2 Network LSA (originated by the DR to represent a pseudonode, 0 cost to attached neighbors is assumed, and so on). The only significant differences are the location of the Options field and the elimination of the Network Mask field, which has no meaning in IPv6.
The Inter-Area Prefix LSA (Figure 9-8) performs the same function as the OSPFv2 type 3 Summary LSA—ABRs originate them into an area to advertise networks that are outside the area but inside the OSPF domain. Only the name, more descriptive in OSPFv3, has changed. An ABR originates a separate Inter-Area Prefix LSA for each IPv6 prefix that must be advertised into an area. An ABR can also originate an Inter-Area Prefix LSA to advertise a default route into a stub area.
The Inter-Area Router LSA performs the same duties for OSPFv3 as the type 4 Summary LSA performs for OSPFv2. An ABR originates an Inter-Area Router LSA into an area to advertise an ASBR that resides outside of the area. The ABR originates a separate Inter-Area Router LSA for each ASBR it advertises.
Figure 9-9 shows the format of the Inter-Area Router LSA. Even though the OSPFv2 type 3 and type 4 Summary LSAs have the same formats, you can see by comparing Figure 9-8 and Figure 9-9 that the Inter-Area Network and Inter-Area Router LSAs are different. The fields are self-descriptive:
Options specifies optional capabilities of the ASBR.
Metric specifies the cost to the ASBR.
Destination Router ID is the ASBR RID.
As with OSPFv2, the AS-External LSA advertises prefixes external to the OSPF routing domain; one LSA is required for each external prefix advertised. However, the format of the OSPFv3 As-External LSA (Figure 9-10) is different from its OSPFv2 counterpart.
The E flag performs the same function in the OSPFv3 LSA as in the OSPFv2 LSA. If set, the metric is a type 2 external metric. If the bit is cleared, the metric is a type 1 external metric.
The F flag indicates, when set, that a forwarding address is included in the LSA.
The T flag indicates, when set, that an external route tag is included in the LSA.
Metric, of course, specifies the cost of the route. Whether it is type 1 or type 2 depends on the value of the E flag.
Prefix Length, Prefix Options, and Address Prefix completely describe the enclosed prefix.
Forwarding Address, if included, is a fully specified 128-bit IPv6 address representing the next-hop address to the destination prefix. It is included only if the F flag is set.
External Route Tag, if included, performs the same function as the External Route Tag field in the OSPFv2 AS-External LSA. It is included only if the T flag is set.
Referenced Link State ID and Referenced Link State Type, if included, allow additional information about the prefix to be included in another LSA. If used, these two fields describe the link state ID and the type of the LSA carrying the additional information. The Advertising Router field of the referenced LSA must also match the value of the Advertising Router field in the AS-External LSA. The additional information has, as with the External Route Tag, no relevance to OSPFv3 itself, but is used to communicate information across the OSPF domain between border routers. If this function is not used, the Referenced Link State Type field is set to all zeroes.
The Link LSA is used for communicating information that is significant only to two directly connected neighbors. The format of the Link LSA is shown in Figure 9-11. A separate Link LSA is originated on each of a router’s attached links belonging to an OSPFv3 domain, and a receiving router, because of the link-local flooding scope, never forwards the LSA to any other link.
The LSA performs three functions:
Router Priority specifies the router priority assigned to the interface of the originating router.
Options specifies the options bits that the originating router would like to set in the Network LSA that will be originated for the link. This is the same 24-bit Options field carried in OSPFv3 Hello and DD packets, in a number of OSPFv3 LSAs. The Options field is detailed in the later section, “The Options Field.”
Link-Local Prefix Address specifies the 128-bit link-local prefix of the originating router’s interface attached to the link.
Number of Prefixes specifies the number of IPv6 prefixes contained in the LSA, as described by the following Prefix Length, Prefix Options, and Address Prefix fields.
Prefix Length, Prefix Options, and Address Prefix describe one or more IPv6 prefixes associated with the link by the originating router. This set of fields is used not only in the Link LSA, but also the Intra-Area-Prefix, Inter-Area-Prefix, and AS-External LSAs. The advertised prefix can be any length between 0 and 128. When the prefix is not an even multiple of 32 bits, it is padded out with zeroes to fit the 32-bit boundaries of the Address Prefix field. The Prefix Length field specifies the length of the unpadded prefix, in bits. The Prefix Options field, shown in Figure 9-12, specifies optional handling of the prefix during routing calculations.
The Propagate (P) bit is set on NSSA area prefixes that should be re-advertised at the NSSA area border.
The Multicast (MC) bit, when set, specifies that the prefix should be included in multicast routing calculations.
The Local Address (LA) bit, when set, specifies that the prefix is an interface address of the advertising router.
The No Unicast (NU) bit, when set, specifies that the prefix should be excluded from unicast route calculations.
The Intra-Area Prefix LSA is shown in Figure 9-13. Recall from the previous discussion of this LSA that attached prefixes, which in OSPFv2 are carried in Router and Network LSAs, in OSPFv3 are carried in Intra-Area Prefix LSAs. Prefix changes—including additions and deletions—do not influence the branches of the SPF tree in any way. But OSPFv2 advertises prefixes in Router and Network LSAs, causing an SPF calculation in all routers in the area whenever a prefix change occurs. With OSPFv3, however, when a link or its prefix changes, the connected router originates an Intra-Area Prefix LSA to flood the information throughout the area. This LSA does not trigger an SPF calculation; the receiving routers simply associate the new prefix information with the originating router. Router and Network LSAs, in OSPFv3, serve only to provide topological information. As a result, this new LSA should make OSPFv3 significantly more scalable for networks with large numbers of frequently changing prefixes.
Number of Prefixes specifies the number of prefixes contained in the LSA.
Referenced Link State Type, Referenced Link State ID, and Referenced Advertising Router identify the Router or Network LSA with which the contained prefixes should be associated.
If the prefixes are associated with a Router LSA, the Referenced Link State Type is 1, the Referenced Link State ID is 0, and the Referenced Advertising Router is the RID of the originating router. If the prefixes should be associated with a network LSA, the Referenced Link State Type is 2, the Referenced Link State ID is the interface ID[1] of the link’s DR, and the Referenced Advertising Router is the RID of the DR.
Each prefix is then represented by a Prefix Length, Prefix Options, and Address Prefix field, as described previously for the Link LSA. Added to these three fields is the Metric field, which is the cost of the prefix.
The 24-bit Options field, specifying optional capabilities of the originating router, is carried in Router, Network, Inter-Area Router, and Link LSAs. This field is also carried in the Hello and Database Description packets. Figure 9-14 shows the format of the Options field. As of this writing, only the six rightmost bits are defined as options flags, and most of those are the same flags you are familiar with from OSPFv2. OSPFv3 routers ignore unrecognized options flags.
DC specifies support for demand circuits capability.
R indicates whether the originator is an active router. When cleared, routes transiting the originating node cannot be computed. The R flag therefore adds a capability similar to the IS-IS Overload bit, described in Chapter 10, “Integrated IS-IS.”
N specifies support for NSSA LSAs.
MC specifies support for MOSPF.
E specifies how AS-External LSAs are flooded, for the formation of stub areas.
V6, if clear, specifies that the router or link should be excluded from IPv6 routing calculations.
The configuration options of OSPFv3 are the same as those for OSPFv2. Process IDs and areas need to be specified. Interfaces and addresses need to be included in the process. Areas can be defined as stubs, totally stubby or not so stubby area (NSSA). Prefixes can be summarized between areas. OSPFv3 can be configured over demand circuits and on NBMA networks. Much of the configuration for OSPFv3 is the same as for OSPFv2. An IPv6 keyword is added in some cases, and an IPv6 prefix or address is used in place of the IPv4 subnet or address. This section contains case studies that show the OSPFv3 configurations that are different from OSPFv2 and some that are very similar, but need to be emphasized.
The configuration of OSPFv3 is similar to OSPFv2 with two exceptions. Recall from Chapter 8 that to configure OSPFv2 on a router and an interface, you first create the OSPF process using the router ospf command. Then, you specify address ranges that encompass interface addresses that are to participate in OSPF, using the network area command. The interfaces configured with IPv4 addresses that fall within the address range specified with the network area command participate in OSPFv2. If an interface has an IPv4 address that is not part of the address range, that interface, or that address (if there is more then one IPv4 address on an interface) will not participate in the OSPFv2 process. OSPFv3 for IPv6 is enabled by specifying an OSPF process ID and an area at the interface configuration level. If an OSPFv3 process has not yet been created, it is created automatically. All IPv6 addresses configured on the interface are included in the specified OSPF process. Figure 9-15 displays an OSPFv3 network.
Hedwig’s and Pigwidgeon’s configurations are displayed in Example 9-1 and Example 9-2.
Example 9-1. OSPFv3 is configured on Hedwig with the interface command ipv6 ospf 1 area 1.
interface Serial 0/0 ipv6 address 2001:db8:0:8::1/64 ipv6 ospf 1 area 1 interface Ethernet0/0 ipv6 address 2001:db8:0:4::1/64 ipv6 ospf 1 area 0
Example 9-2. Pigwidgeon is configured for OSPFv3.
interface Ethernet 0/0 ipv6 address 2001:db8:0:5::3/64 ipv6 ospf 1 area 0 interface Serial 0/0 ipv6 address 2001:db8:0:10::1/64 ipv6 ospf 1 area 0
The command ipv6 ospf area enables OSPFv3 on Serial0/0 and Ethernet0/0, places Hedwig’s serial interface in area 1 and the Ethernet interface in area 0, and creates the OSPFv3 process with ID ‘1’ on the router, as shown in Example 9-3. With OSPFv2, two commands are required to accomplish the same tasks: the router ospf 1 command creates the OSPF process, then the network area command enables OSPFv2 on interfaces. One thing to note, though, is that the network area command can enable OSPFv2 on multiple interfaces with the single command, whereas the ipv6 ospf area command has to be configured on each interface that will be running OSPFv3.
Example 9-3. show ipv6 protocol displays the OSPF for IPv6 process ID and the interfaces configured in each area on the router.
Hedwig#show ipv6 protocol
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
Interfaces (Area 0):
Ethernet0/0
Interfaces (Area 1):
Serial0/0
Redistribution:
None
Hedwig#All IPv6 addresses on an interface are included in the OSPF process that is created on the interface. For example, a second IPv6 address is added to Hedwig’s Ethernet port in Example 9-4.
Example 9-4. A second IPv6 address is added to Hedwig’s Ethernet0/0. Both IPv6 addresses are included in the OSPFv3 process because OSPFv3 is configured on that interface.
interface Ethernet0/0 ipv6 address 2001:db8:0:4::1/64 ipv6 address 2001:db8:0:5::1/64 ipv6 ospf 1 area 0
This second address is included automatically in the OSPFv3 process that is configured on the interface. No additional OSPFv3 commands need to be entered to make the new address part of the routing process. IPv6 addresses on an interface cannot be selectively included in OSPFv3. Either all the addresses are included, by configuring the interface with OSPFv3, or OSPFV3 is not configured on the interface and none of the addresses are included.
OSPFv3 routers use their link-local addresses as the source of hello packets. No IPv6 prefix information is contained in hello packets. Multiple IPv6 addresses can be configured on a link. None of the addresses are defined as secondary addresses, as is done with IPv4 to configure multiple addresses on a single link. Two routers will become adjacent even if no IPv6 prefix is common between the neighbors except the link-local address. This is different from OSPFv2 for IPv4. OSPFv2 neighbors will only become adjacent if the neighbors belong to the same IP subnet, and the common subnet is configured as the primary IP address on the neighboring interfaces. In Figure 9-15, Hedwig is configured with both 2001:db8:0:4::/64 and 2001:db8:0:5::/64 on its Ethernet interface. Pigwidgeon is configured with 2001:db8:0:5::/64 and Crookshanks is configured with 2001:db8:0:4::/64 on their Ethernet interfaces. Example 9-5 shows that Crookshanks is adjacent to both Hedwig (10.1.1.1) and Pigwidgeon (10.1.3.1). Pigwidgeon is the backup designated router.
Example 9-5. show ipv6 ospf neighbor shows Crookshanks’s neighbors are all in the FULL state, even though they don’t share a common IPv6 prefix, other then the link-local address.
Crookshanks#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
10.1.1.1 1 FULL/DROTHER 00:00:30 3 Ethernet0/0
10.1.3.1 1 FULL/BDR 00:00:37 3 Ethernet0/0
Crookshanks#Other parameters must match between two neighbors before they will become adjacent. These parameters are the same as IPv4: The neighbors must share the same area id, they must have the same Hello interval and dead time, and they both must have the same value in the E-bit, indicating whether the area is a stub area or not. An OSPFv3 packet must also have the same Instance ID as the receiving interface, or the OSPFv3 packets will be dropped. Instance ID will be discussed later in this chapter, in the case study, Multiple Instances on a Link.
OSPFv3 uses a 32-bit number for a Router ID. If IPv4 is configured on the router, by default, the RID is chosen in the same way it is by OSPFv2 for IPv4. The highest IPv4 address configured on a loopback interface will become the RID, or if no loopback interfaces are configured, the highest address on any other interface will become the RID.
IPv6 neighbors are always known by their RIDs, unlike IPv4, where point-to-point network neighbors are known by RIDs and broadcast, NBMA and point-to-multipoint network neighbors are known by their interface IP addresses. The neighbor IDs shown in Example 9-5 show that the router IDs are obtained from configured IPv4 addresses.
If IPv4 is not configured in the network, and you don’t want to configure IPv4 just to establish a router ID, the router ID must be configured using the IPv6 OSPF routing process command router-id before the OSPF process will start.
When OSPFv3 is configured on an interface, the routing process is created. Interface parameters, such as the cost of a link, are modified at the interface configuration, but global parameters are modified at the OSPF process level.
The ipv6 router ospf command takes you into the global process configuration mode, just as router ospf does for IPv4. The same configuration customization can be done with IPv6 as with IPv4. Stub, NSSA, and totally stubby are supported and configured in the exact same way as for OSPFv2 for IPv4, using the area stub, area nssa, and area stub no-summary commands. Area 1 in Figure 9-15 is configured as a totally stubby area with the configurations in Example 9-6 and Example 9-7 at Hedwig and Scabbers.
Example 9-6. On Hedwig, area 1 is configured as a totally stubby area. no-summary is only configured on the ABR.
ipv6 router ospf 1 area 1 stub no-summary
Example 9-7. Area 1 on Scabbers is also configured as a stub because all routers in the stub area must be configured as a stub.
ipv6 router ospf 1 area 1 stub
Example 9-8 shows Scabbers’s IPv6 route table before area 1 becomes totally stubby, and Example 9-9 shows the route table of Scabbers as part of the totally stubby area.
Example 9-8. The IPv6 route table at Scabbers contains 10 OSPF entries, all known via Hedwig.
Scabbers#show ipv6 route
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
OI 2001:DB8:0:4::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:5::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
C 2001:DB8:0:8::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:8::2/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:9::/64 [0/0]
via ::, Ethernet0/0
L 2001:DB8:0:9::2/128 [0/0]
via ::, Ethernet0/0
OI 2001:DB8:0:10::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:11::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:12::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:13::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:200::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:201::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:202::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:203::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Scabbers#Example 9-9. As part of a totally stubby area, Scabbers now has only a single OSPF entry, the default route.
Scabbers#show ipv6 route
IPv6 Routing Table - 7 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
OI ::/0 [110/65]
via FE80::202:FDFF:FE5A:E40, Serial0/0
C 2001:DB8:0:8::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:8::2/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:9::/64 [0/0]
via ::, Ethernet0/0
L 2001:DB8:0:9::2/128 [0/0]
via ::, Ethernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Scabbers#A new router, Hermes, has been added to the Ethernet segment in Figure 9-16. The desired OSPF design is to separate Pigwidgeon’s and Hermes’s OSPFv3 traffic from Hedwig’s and Crookshanks’s traffic. As the configuration stands, the DR and BDR are chosen among the four routers, and each router becomes adjacent with the DR and BDR. OSPFv3 Hellos contain a field for an Instance ID. The Instance ID can be used to segment the two OSPF processes running on the LAN segment. The Instance ID received in a Hello packet must match the Instance ID configured on the receiving interface or the Hello packet will be discarded. Instance ID 0 is used when none other is specified. By configuring Pigwidgeon and Hermes with a different Instance ID than is configured on Hedwig and Crookshanks, the desired adjacencies will be established.
Pigwidgeon’s configuration is modified as displayed in Example 9-10.
Example 9-10. Pigwidgeon’s Instance ID is modified from the default of 0 to create a distinct OSPF process on the Ethernet.
interface Ethernet 0/0 ipv6 address 2001:db8:0:5::3/64 ipv6 ospf 1 area 0 instance 1
Pigwidgeon’s Instance ID is changed from the default of 0 to 1. Hedwig and Crookshanks continue to use the default Instance ID of zero. Hermes is configured similarly to Pigwidgeon to use instance ID 1. Looking at the IPv6 OSPF configuration running on Hermes’s Ethernet0/0 interface, shown in Example 9-11, only Pigwidgeon (10.1.3.1) is adjacent.
Although multiple OSPFv3 processes can run on a router, only a single process or instance can run on an interface.
Example 9-11. Hermes’s IPv6 OSPF Ethernet interface configuration shows that Pigwidgeon, the only other router on the Ethernet segment using instance ID 1, is adjacent.
Hermes#show ipv6 ospf interface ethernet 0/0
Ethernet0/0 is up, line protocol is up
Link Local Address FE80::206:28FF:FEB6:5BC0, Interface ID 3
Area 0, Process ID 1, Instance ID 1, Router ID 10.1.5.1
Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.5.1, local address FE80::206:28FF:FEB6:5BC0
Backup Designated router (ID) 10.1.3.1, local address FE80::201:42FF:FE79:E500
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:09
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 4
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.1.3.1 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Hermes#OSPFv3 on NBMA networks has the same configuration options as does OSPFv2, that is, the network, from OSPF’s point of view, can remain NBMA, can be configured as broadcast or point-to-multipoint, or point-to-point networks can be configured using subinterfaces. Point-to-point links are straightforward to configure. They are configured the same way as routers connected directly via serial links. Hedwig and Scabbers, in the first case study in this chapter, called “A basic OSPFv3 configuration,” are configured with directly connected serial links. If these two routers were connected with point-to-point Frame-relay subinterfaces, the OSPFv3 configuration would remain the same. The NBMA, broadcast, and point-to-multipoint networks will be discussed in this section.
Before OSPFv3 can learn about neighbors, the neighbor addresses that OSPF will use must be associated with specific virtual circuits traversing the NBMA network. Frame Relay maps are created to identify a remote IPv6 address with one of the PVCs connected to the local router.[2] Because IPv6 can have multiple addresses configured on a single interface, many map statements for each PVC might be required. All OSPFv3 packets use the Link-local address as the source address. It is also the link-local address that is used as the destination address for unicast OSPFv3 packets, and as the next-hop to which to forward a packet when routing. At a minimum, therefore, the link-local addresses must be mapped. Figure 9-17 shows a Frame Relay network with four attached routers.
The first method of configuring the routers for OSPFv3 is to manually configure OSPFv3 neighbors. The remote routers’ link-local addresses are mapped to the correct DLCI, and the IPv6 OSPFv3 neighbors are defined, both as part of the interface’s configuration. Skrewt’s configuration is shown in Example 9-12.
Example 9-12. OSPFv3 neighbors are configured on Skrewt manually.
interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf 1 area 1 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 ipv6 ospf neighbor fe80::206:28ff:feb6:5bc0 priority 5 ipv6 ospf neighbor fe80::202:fdff:fe5a:e40 priority 10 ipv6 ospf neighbor fe80::201:42ff:fe79:e500
Notice that the Link-local addresses are used in the frame-relay map statements and in the ospf neighbor statements. To specify which routers are to become the DR and BDR, assign priorities using an optional keyword with ipv6 ospf neighbor command.
Another configuration option is to enable OSPFv3 to dynamically discover neighbors. Two configuration items are required: The OSPF network gets defined as a broadcast network using the command ipv6 ospf network broadcast, and the frame-relay map statements are configured to forward broadcasts over the PVC using the broadcast keyword on the map statement. Skrewt’s configuration changes to Example 9-13.
Example 9-13. Skrewt’s PVCs are configured as broadcast PVCs, and the OSPFv3 network running over the Frame Relay link is configured as a broadcast network.
interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 ipv6 ospf priority 20 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast
The other routers on the multiaccess network are configured similarly. Notice that there is no longer any need to define IPv6 OSPF neighbors. If the underlying NBMA network is not fully meshed (a PVC from every router to every other router), the DR and BDR must be carefully selected. Both the DR and BDRs must have full virtual circuit connectivity to every other router so the correct adjacencies are formed. Use the interface command ipv6 ospf priority to specify a high priority on the router you wish to be the DR. This method of assigning the DR is discussed in the case study, OSPF on NBMA Networks, in Chapter 8. Example 9-14 shows Skrewt’s IPv6 OSPF configuration on serial 0/0.
Example 9-14. An interface’s OSPFv3 for IPv6 configuration is displayed using the show ipv6 ospf interface command.
Skrewt#show ipv6 ospf interface serial 0/0
Serial0/0 is up, line protocol is up
Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4
Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 20
Designated Router (ID) 1.1.1.1, local address FE80::207:85FF:FE6B:EA20
Backup Designated router (ID) 10.1.3.1, local address FE80::202:FDFF:FE5A:E40
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:08
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 4
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 3, Adjacent neighbor count is 3
Adjacent with neighbor 10.1.1.23
Adjacent with neighbor 10.1.3.1 (Backup Designated Router)
Adjacent with neighbor 192.2.2.9
Suppress hello for 0 neighbor(s)
Skrewt#Note that the network type is BROADCAST. Also note that the neighbor count is 3, and there are 3 adjacent neighbors. This router is the DR, so it has become adjacent to all other routers on the network. The neighbors that are not DR or BDR, such as Flobberworm, have three neighbors, but only two adjacent neighbors, as shown in Example 9-15, because routers on broadcast networks become adjacent to the DR and BDR only.
Example 9-15. With four routers on a broadcast network, a non-DR or BDR router will have three neighbors, but only be fully adjacent to two of the neighbors.
Flobberworm#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
1.1.1.1 20 FULL/DR 00:00:36 3 Ethernet0/0
10.1.1.23 1 2WAY/DROTHER 00:00:36 3 Ethernet0/0
10.1.3.1 15 FULL/BDR 00:00:37 3 Ethernet0/0
Flobberworm#To avoid the DR/BDR election process, the OSPF network type can be changed to point-to-multipoint, as can be seen in Skrewt’s modified configuration in Example 9-16.
Example 9-16. Skrewt’s configuration shows that the PVCs continue to broadcast, and that the OSPFv3 network type has been changed to point-to-multipoint.
Interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network point-to-multipoint ipv6 ospf 1 area 1 ipv6 ospf priority 20 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast
Skrewt’s IPv6 OSPF interface configuration (Example 9-17) shows that the default timers are different for point-to-multipoint networks then they are for broadcast networks. Hellos are sent every 30 seconds on point-to-multipoint networks and every 10 seconds on broadcast networks. The OSPFv3 interface configuration also does not show any DR, and the router is adjacent with all three neighbors.
Example 9-17. The IPv6 OSPF interface configuration of an OSPF point-to-multipoint network is displayed with the command show ipv6 ospf interface.
Skrewt#show ipv6 ospf interface serial 0/0
Serial0/0 is up, line protocol is up
Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4
Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:13
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 2, maximum is 4
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 3, Adjacent neighbor count is 3
Adjacent with neighbor 10.1.1.23
Adjacent with neighbor 10.1.3.1
Adjacent with neighbor 192.2.2.9
Suppress hello for 0 neighbor(s)
Skrewt#An NBMA network configured as an OSPF point-to-multipoint network need not have a full mesh of underlying PVCs. Figure 9-18 shows that some PVCs have been removed from the network in Figure 9-17. The map statement for DLCI 202 has been removed from Skrewt in Example 9-18.
Example 9-18. Skrewt’s Frame Relay configuration maps IPv6 addresses to the remaining two PVCs.
interface Serial0/0 no ip address encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network point-to-multipoint ipv6 ospf priority 20 ipv6 ospf 1 area 1 frame-relay map ipv6 FE80::201:42FF:FE79:E500 203 broadcast frame-relay map ipv6 FE80::206:28FF:FEB6:5BC0 201 broadcast
Hippogriff and the IPv6 prefixes known to Hippogriff are all accessible from Skrewt, as can be seen in Skrewt’s IPv6 route table shown in Example 9-19. Skrewt and Hippogriff are both adjacent to both Thestral and Flobberworm, and Hippogriff’s IPv6 serial0/0 IPv6 address, 2001:db8:0:1::3, in addition to the IPv6 prefixes advertised by Hippogriff, are routed to via Skrewt’s serial0/0 interface, and to the next-hop link-local addresses FE80::206:28FF:FEB6:5BC0 and FE80::201:42FF:FE79:E500.
Example 9-19. Skrewt’s route table shows that even the router that does not have a connected PVC to Skrewt is still accessible via the routers that do have connected PVCs in the point-to-multipoint network.
Skrewt#show ipv6 route IPv6 Routing Table - 16 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 C 2001:DB8:0:1::/64 [0/0] via ::, Serial0/0 L 2001:DB8:0:1::1/128 [0/0] via ::, Serial0/0 O 2001:DB8:0:1::2/128 [110/64] via FE80::206:28FF:FEB6:5BC0, Serial0/0 O 2001:DB8:0:1::3/128 [110/128] via FE80::206:28FF:FEB6:5BC0, Serial0/0 via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:1::4/128 [110/64] via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:5::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, Serial0/0 O 2001:DB8:0:A::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, Serial0/0 via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:B::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, Serial0/0 via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:C::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, Serial0/0 via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:D::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, Serial0/0 via FE80::201:42FF:FE79:E500, Serial0/0 O 2001:DB8:0:50::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, Serial0/0 O 2001:DB8:0:51::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, Serial0/0 O 2001:DB8:0:52::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, Serial0/0 O 2001:DB8:0:53::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, Serial0/0 L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0 Skrewt#
The IPv6 addresses 2001:db8:0:1::2/64, 2001:db8:0:1::3/64, and 2001:db8:0:1::4/64, that have been configured on the Frame Relay point-to-multipoint interfaces are all advertised by OSPF with 128-bit prefix lengths. These addresses, along with the other IPv6 prefixes advertised by Hippogriff into OSPF, are reachable via the link-local addresses of Skrewt’s two adjacent routers.
Troubleshooting OSPFv3 for IPv6 should be handled in the same way as OSPFv2 for IPv4. The major difference will be the addressing: OSPFv3 uses the link-local addresses as the source and, when sending directly to a neighbor, destination of packets.
Upon initial configuration of Figure 9-17, Skrewt and Hippogriff are configured with the configurations in Example 9-20 and Example 9-21.
Example 9-20. Skrewt’s initial Frame Relay mapping configuration.
interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 frame-relay map ipv6 2001:db8:0:1::2 201 broadcast frame-relay map ipv6 2001:db8:0:1::3 202 broadcast frame-relay map ipv6 2001:db8:0:1::4 203 broadcast ipv6 ospf 1 area 1
Example 9-21. Hippogriff’s initial Frame Relay mapping configuration.
interface Serial0/0 no ip address encapsulation frame-relay ipv6 address 2001:DB8:0:1::3/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 frame-relay map ipv6 2001:DB8:0:1::1 220 broadcast frame-relay map ipv6 2001:DB8:0:1::2 221 broadcast frame-relay map ipv6 2001:DB8:0:1::4 223 broadcast
The other routers are configured similarly.
The routers are not becoming adjacent, as shown in Skrewt’s OSPFv3 neighbor table in Example 9-22.
Example 9-22. Skrewt is not becoming adjacent to the DR or BDR.
Skrewt#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
10.1.3.1 1 EXSTART/DR 00:00:34 4 Serial0/0
10.1.1.23 1 EXSTART/BDR 00:00:31 4 Serial0/0
192.2.2.9 1 2WAY/DROTHER 00:00:36 4 Serial0/0
Skrewt#Debugging IPv6 OSPF Hellos and adjacencies, Example 9-23, show that Hellos are being received and two-way communication is established. The DR and BDR are elected. Database synchronization is attempted to complete the adjacencies with the DR and BDR. Skrewt attempts to send database description packets (DBD) to the potential DR, but never receives an acknowledgment, although Skrewt does continue to receive Hellos from the potential DR. The neighbor state EXSTART with the DR and BDR indicates that a master/slave relationship is being established and an initial DBD packet has been sent.
Example 9-23. debug ipv6 ospf hello and debug ipv6 ospf adj show Hellos, two-way communication establishment, DR/BDR election, and the sending of DBD packets.
Skrewt#debug ipv6 ospf hello Skrewt#debug ipv6 ospf adj OSPFv3: Rcv hello from 10.1.1.23 area 1 from Serial0/0 FE80::202:FDFF:FE5A:E40 interface ID 4 OSPFv3: 2 Way Communication to 10.1.1.23 on Serial0/0, state 2WAY OSPFv3: Neighbor change Event on interface Serial0/0 OSPFv3: DR/BDR election on Serial0/0 OSPFv3: Elect BDR 10.1.1.23 OSPFv3: Elect DR 10.1.1.23 DR: 10.1.1.23 (Id) BDR: 10.1.1.23 (Id) OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28 OSPFv3: Rcv hello from 10.1.3.1 area 1 from Serial0/0 FE80::201:42FF:FE79:E500 interface ID 4 OSPFv3: 2 Way Communication to 10.1.3.1 on Serial0/0, state 2WAY OSPFv3: Neighbor change Event on interface Serial0/0 OSPFv3: DR/BDR election on Serial0/0 OSPFv3: Elect BDR 10.1.1.23 OSPFv3: Elect DR 10.1.3.1 DR: 10.1.3.1 (Id) BDR: 10.1.1.23 (Id) OSPFv3: Send DBD to 10.1.3.1 on Serial0/0 seq 0x1C93 opt 0x0013 flag 0x7 len 28 OSPFv3: Remember old DR 10.1.1.23 (id) OSPFv3: End of hello processing OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28 OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [1] OSPFv3: Send DBD to 10.1.3.1 on Serial0/0 seq 0x1C93 opt 0x0013 flag 0x7 len 28 OSPFv3: Retransmitting DBD to 10.1.3.1 on Serial0/0 [1] OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28 OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [2] OSPFv3: Rcv hello from 10.1.1.23 area 1 from Serial0/0 FE80::202:FDFF:FE5A:E40 interface ID 4 OSPFv3: End of hello processing Skrewt#
No acknowledgments are being received. Adding a debug of IPv6 OSPF packets shows additional information about the DBD packets being sent[3] (Example 9-24).
Example 9-24. Adding debug ipv6 ospf packet shows packet encapsulation failures.
Skrewt#debug ipv6 ospf packet
OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0x2422 opt 0x0013 flag 0x7 len 28
IPV6: source FE80::207:85FF:FE6B:EA20 (local)
dest FE80::202:FDFF:FE5A:E40 (Serial0/0)
traffic class 224, flow 0x0, len 68+0, prot 89, hops 1, originating
IPv6: Encapsulation failed
OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [4]The DBD packets are not multicast, as Hellos are. They are sent to the IPv6 address of the neighbor router. Recall that OSPFv3 uses the link-local addresses for packet exchange, as can be seen in the output of the IPv6 packet debug. Skrewt does not have a Frame Relay map to FE80::202:FDFF:FE5A:E40 on interface Serial0/0. This is why the encapsulation failed. Frame Relay maps must be configured mapping the link-local address of the neighbor routers to the local DLCI.
To easily obtain the link-local addresses of an IPv6 interface, use show ipv6 interface serial0/0, as shown in Example 9-25 .
Example 9-25. IPv6 information pertinent to an interface can be viewed with the command show ipv6 interface.
Skrewt#show ipv6 interface serial0/0 Serial0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::207:85FF:FE6B:EA20 Global unicast address(es): 2001:DB8:0:1::1, subnet is 2001:DB8:0:1::/64 Joined group address(es): FF02::1 FF02::2 FF02::5 FF02::1:FF00:1 FF02::1:FF6B:EA20 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Skrewt#
Skrewt’s and Hippogriff’s configurations are changed as displayed in Example 9-26 and Example 9-27.
Example 9-26. Skrewt’s Frame Relay mapping statements are changed to the link-local IPv6 addresses.
interface Serial0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast
Example 9-27. Hippogriff’s Frame Relay mapping statements are changed to the IPv6 link-local addresses.
interface Serial0/0 no ip address encapsulation frame-relay ipv6 address 2001:DB8:0:1::3/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 frame-relay map ipv6 fe80::207:85ff:fe6b:ea20 220 broadcast frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 221 broadcast frame-relay map ipv6 fe80::201:42ff:fe79:e500 223 broadcast
The IPv6 address that must be mapped to the DLCI is the neighbor’s link-local address. Skrewt’s correct IPv6 OSPF neighbor table is shown in Example 9-28 .
Example 9-28. After mapping the neighbors’ link-local addresses to the local DLCIs, Skrewt is fully adjacent to the DR and BDR.
Skrewt#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
192.2.2.9 1 FULL/DR 00:00:32 4 Serial0/0
10.1.1.23 1 2WAY/DROTHER 00:00:37 4 Serial0/0
10.1.3.1 1 FULL/BDR 00:00:38 4 Serial0/0
Skrewt#We have spent two chapters—one of them very long—describing the major aspects of OSPF, which is not only the most well-known of the link-state routing protocols, but probably the most widely used IP routing protocol. In the next chapter we will look at a less-known link-state protocol: IS-IS. Some might call this a “more exotic” protocol, but as you will see, it is actually much simpler than OSPF.
Command | Description |
|---|---|
area area-id nssa [no-redistribution] [default-information-originate [metric] [metric-type]] [no-summary] | Defines an area as a not so stubby area and gives the option of configuring related parameters. |
area area-id range {ipv6-prefix / prefix-length} [advertise | not-advertise] [cost cost] | Creates a summary prefix out of more specific routes in the specified area. The summary is flooded (or not flooded, depending on the advertise | not-advertise option) to the other areas. |
area area-id stub [no-summary] | Defines an area as a stub or totally stubby area. |
debug ipv6 ospf packet | Provides debugging information about each IPv6 OSPF packet received. |
debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission] | Provides debugging information about specific OSPF packet types. |
ipv6 ospf process-id area area-id [instance instance-id] | Creates the OSPFv3 process (if it is not already created) and enables OSPF on an interface. |
ipv6 ospf neighbor ipv6-address [priority number] [poll-interval seconds] [cost number] [database-filter all out] | Manually configures OSPFv3 neighbors. |
ipv6 ospf network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast] | point-to-point}} | Configures the OSPF network type to a type other then the default for a given medium. |
ipv6 ospf priority number-value | Configures the OSPFv3 priority to give to a router for use in DR and BDR election. |
ipv6 router ospf process-id | Enables OSPFv3 router level configuration. |
show ipv6 ospf [process-id] [area-id] | Displays general information about the OSPFv3 process. |
show ipv6 ospf [process-id] [area-id] neighbor [interface-type interface-number] [neighbor-id] [detail] | Displays information about OSPFv3 neighbors. |
show ipv6 ospf [process-id] [area-id] interface [interface-type interface-number] | Displays OSPFv3 information related to the specified interface. |
summary-prefix prefix [not-advertise | tag tag-value] | Summarizes prefixes that are redistributed into OSPFv3. |
Which OSPFv3 command is required to include a second IPv6 prefix that has been configured on an interface in the OSPFv3 process? | |
Can two routers become adjacent if one is configured with the IPv6 address 2001:db8:0:1::1/64, and the other is configured with the address 2001:db8:0:100::1/126? | |
Provide the IPv6 OSPFv3 configuration of the routers in Figure 9-19. | |
Configure area 1 in Figure 9-19 as a totally stubby area and summarize addresses into area 0. |
[1] The interface ID used in this and other OSPFv3 LSAs should not be confused with the 64-bit Interface ID portion of an IPv6 address. This field is a 32-bit value distinguishing this interface from other interfaces on the originating router. RFC 2740 suggests using the MIB-II If Index for the interface ID value.
[2] IPv4 uses Frame Relay inverse ARP to dynamically map addresses. IPv6’s functionality to dynamically map addresses to Frame Relay PVCs is not supported in IOS at the time of this writing.
[3] Debugging IPv6 packets in a live network is not recommended.