Chapter 9: OSPFv3

Cisco Press

1 2 3 4 5 Page 2
Page 2 of 5
  • Type specifies the interface type. Table 9-3 lists the possible interface type values.

    Table 9-3 Interface types specified in the Type field of the Router LSA.

    TypeDescription
    1Point-to-point connection to another router
    2Connection to a transit network
    3Reserved
    4Virtual link

    Figure 9-6

    Figure 9-6

    OSPFv3 Router LSA.

  • 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.

Network LSA

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.

Figure 9-7

Figure 9-7

OSPFv3 Network LSA.

Inter-Area Prefix LSA

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.

Figure 9-8

Figure 9-8

OSPFv3 Inter-Area Prefix LSA.

Inter-Area Router LSA

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.

Figure 9-9

Figure 9-9

OSPFv3 Inter-Area Router LSA.

AS-External LSA

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.

Figure 9-10

Figure 9-10

OSPFv3 AS-External LSA.

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.

Link LSA

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.

Figure 9-11

Figure 9-11

OSPFv3 Link LSA.

The LSA performs three functions:

  • It provides the originating router's link-local address to all other routers attached to the link.

  • It provides a list of IPv6 prefixes associated with the link.

  • It provides a set of Option bits to associate with Network LSAs originated on the link.

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.

Figure 9-12

Figure 9-12

Prefix Options field.

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.

Intra-Area Prefix LSA

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.

Figure 9-13

Figure 9-13

Intra-Area Prefix LSA.

  • 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.

Options Field

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.

Figure 9.14

Figure 9-14

Options field.

  • 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.

Configuring OSPFv3

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.

Case Study: A Basic OSPFv3 Configuration

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.

Figure 9-15

Figure 9-15

Example of 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.

Related:
1 2 3 4 5 Page 2
Page 2 of 5
SD-WAN buyers guide: Key questions to ask vendors (and yourself)