OSPFv3 is a routing protocol for IPv4 and IPv6. It is a link-state protocol, as opposed to a distance-vector protocol. Think of a link as being an interface on a networking device. A link-state protocol makes its routing decisions based on the states of the links that connect source and destination machines. The state of a link is a description of that interface and its relationship to its neighboring networking devices. The interface information includes the IPv6 prefix of the interface, the network mask, the type of network it is connected to, the devices connected to that network, and so on. This information is propagated in various type of link-state advertisements (LSAs).

A device's collection of LSA data is stored in a link-state database. The contents of the database, when subjected to the Dijkstra algorithm, result in the creation of the OSPF routing table. The difference between the database and the routing table is that the database contains a complete collection of raw data; the routing table contains a list of shortest paths to known destinations via specific device interface ports.

OSPFv3, which is described in RFC 5340, supports IPv6 and IPv4 unicast AFs.

Much of the OSPFv3 feature is the same as in OSPF version 2. OSPFv3, which is described in RFC 5340, expands on OSPF version 2 to provide support for IPv6 routing prefixes and the larger size of IPv6 addresses.

In OSPFv3, a routing process does not need to be explicitly created. Enabling OSPFv3 on an interface will cause a routing process, and its associated configuration, to be created.

In OSPFv3, each interface must be enabled using commands in interface configuration mode. This feature is different from OSPF version 2, in which interfaces are indirectly enabled using the router configuration mode.

In IPv6, users can configure many address prefixes on an interface. In OSPFv3, all address prefixes on an interface are included by default. Users cannot select some address prefixes to be imported into OSPFv3; either all address prefixes on an interface are imported, or no address prefixes on an interface are imported.

Unlike OSPF version 2, multiple instances of OSPFv3 can be run on a link.

In OSPFv3, it is possible that no IPv4 addresses will be configured on any interface. In this case, the user must use the router-id command to configure a router ID before the OSPF process will be started. A router ID is a 32-bit opaque number. OSPF version 2 takes advantage of the 32-bit IPv4 address to pick an IPv4 address as the router ID. If an IPv4 address does exist when OSPFv3 is enabled on an interface, then that IPv4 address is used for the router ID. If more than one IPv4 address is available, a router ID is chosen using the same rules as for OSPF version 2.

OSPF automatically prefers a loopback interface over any other kind, and it chooses the highest IP address among all loopback interfaces. If no loopback interfaces are present, the highest IP address in the router is chosen. You cannot tell OSPF to use any particular interface.

The OSPFv3 address families feature enables both IPv4 and IPv6 unicast traffic to be supported. With this feature, users may have two router processes per interface, but only one process per AF. If the IPv4 AF is used, an IPv4 address must first be configured on the interface, but IPv6 must be enabled on the interface. A single IPv4 or IPv6 OSPFv3 process running multiple instances on the same interface is not supported.

Users with an IPv6 network that uses OSPFv3 as its IGP may want to use the same IGP to help carry and install IPv4 routes. All routers on this network have an IPv6 forwarding stack. Some (or all) of the links on this network may be allowed to do IPv4 forwarding and be configured with IPv4 addresses. Pockets of IPv4-only routers exist around the edges running an IPv4 static or dynamic routing protocol. In this scenario, users need the ability to forward IPv4 traffic between these pockets without tunneling overhead, which means that any IPv4 transit router has both IPv4 and IPv6 forwarding stacks (e.g., is dual stack).

This feature allows a separate (possibly incongruent) topology to be constructed for the IPv4 AF. It installs IPv4 routes in IPv4 RIB, and then the forwarding occurs natively. The OSPFv3 process fully supports an IPv4 AF topology and can redistribute routes from and into any other IPv4 routing protocol.

An OSPFv3 process can be configured to be either IPv4 or IPv6. The address-family command is used to determine which AF will run in the OSPFv3 process, and only one address family can be configured per instance. Once the AF is selected, users can enable multiple instances on a link and enable address-family-specific commands.

Different instance ID ranges are used for each AF. Each AF establishes different adjacencies, has a different link state database, and computes a different shortest path tree. The AF then installs the routes in AF-specific RIB. LSAs that carry IPv6 unicast prefixes are used without any modification in different instances to carry each AFs' prefixes.

The IPv4 subnets configured on OSPFv3-enabled interfaces are advertised through intra-area prefix LSAs, just as any IPv6 prefixes. External LSAs are used to advertise IPv4 routes redistributed from any IPv4 routing protocol, including connected and static. The IPv4 OSPFv3 process runs the SPF calculations and finds the shortest path to those IPv4 destinations. These computed routes are then inserted in the IPv4 RIB (computed routes are inserted into an IPv6 RIB for an IPv6 AF).

Because the IPv4 OSPFv3 process allocates a unique pdbindex in the IPv4 RIB, all other IPv4 routing protocols can redistribute routes from it. The parse chain for all protocols is same, so the ospfv3 keyword added to the list of IPv4 routing protocols causes OSPFv3 to appear in the redistribute command from any IPv4 routing protocol. With the ospfv3 keyword, IPv4 OSPFv3 routes can be redistributed into any other IPv4 routing protocol as defined in the redistribute ospfv3 command.

The OSPFv3 address families feature is supported as of Cisco IOS XE Release 3.4S. Cisco routers that run software older than this release and third-party routers will not neighbor with routers running the AF feature for the IPv4 AF because they do not set the AF bit. Therefore, those routers will not participate in the IPv4 AF SPF calculations and will not install the IPv4 OSPFv3 routes in the IPv6 RIB.

The following list describes LSA types, each of which has a different purpose:

• Router LSAs (Type 1)--Describes the link state and costs of a router's links to the area. These LSAs are flooded within an area only. The LSA indicates if the router is an Area Border Router (ABR) or Autonomous System Boundary Router (ASBR), and if it is one end of a virtual link. Type 1 LSAs are also used to advertise stub networks. In OSPFv3, these LSAs have no address information and are network-protocol-independent. In OSPFv3, router interface information may be spread across multiple router LSAs. Receivers must concatenate all router LSAs originated by a given router when running the SPF calculation.
• Network LSAs (Type 2)--Describes the link-state and cost information for all routers attached to the network. This LSA is an aggregation of all the link-state and cost information in the network. Only a designated router tracks this information and can generate a network LSA. In OSPFv3, network LSAs have no address information and are network-protocol-independent.
• Interarea-prefix LSAs for ABRs (Type 3)--Advertises internal networks to routers in other areas (interarea routes). Type 3 LSAs may represent a single network or a set of networks summarized into one advertisement. Only ABRs generate summary LSAs. In OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0.
• Interarea-router LSAs for ASBRs (Type 4)--Advertises the location of an ASBR. Routers that are trying to reach an external network use these advertisements to determine the best path to the next hop. Type 4 LSAs are generated by ABRs on behalf of ASBRs.
• Autonomous system external LSAs (Type 5)--Redistributes routes from another autonomous system, usually from a different routing protocol into OSPFv3. In OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0.
• Link LSAs (Type 8)--Have local-link flooding scope and are never flooded beyond the link with which they are associated. Link LSAs provide the link-local address of the router to all other routers attached to the link, inform other routers attached to the link of a list of prefixes to associate with the link, and allow the router to assert a collection of Options bits to associate with the network LSA that will be originated for the link.
• Intra-Area-Prefix LSAs (Type 9)--A router can originate multiple intra-area-prefix LSAs for each router or transit network, each with a unique link-state ID. The link-state ID for each intra-area-prefix LSA describes its association to either the router LSA or the network LSA and contains prefixes for stub and transit networks.

An address prefix occurs in almost all newly defined LSAs. The prefix is represented by three fields: PrefixLength, PrefixOptions, and Address Prefix. In OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0. Type 3 and Type 9 LSAs carry all prefix (subnet) information that, in OSPFv2, is included in router LSAs and network LSAs. The Options field in certain LSAs (router LSAs, network LSAs, interarea-router LSAs, and link LSAs) has been expanded to 24 bits to provide support for OSPFv3.

In OSPFv3, the sole function of the link-state ID in interarea-prefix LSAs, interarea-router LSAs, and autonomous-system external LSAs is to identify individual pieces of the link-state database. All addresses or router IDs that are expressed by the link-state ID in OSPF version 2 are carried in the body of the LSA in OSPFv3.

The link-state ID in network LSAs and link LSAs is always the interface ID of the originating router on the link being described. For this reason, network LSAs and link LSAs are now the only LSAs whose size cannot be limited. A network LSA must list all routers connected to the link, and a link LSA must list all of the address prefixes of a router on the link.

• OSPFv3 Max-Metric Router LSA

The OSPFv3 LSA and SPF throttling feature provides a dynamic mechanism to slow down link-state advertisement updates in OSPFv3 during times of network instability. It also allows faster OSPFv3 convergence by providing LSA rate limiting in milliseconds.

OSPFv3 can use static timers for rate-limiting SPF calculation and LSA generation. Although these timers are configurable, the values used are specified in seconds, which poses a limitation on OSPFv3 convergence. LSA and SPF throttling achieves subsecond convergence by providing a more sophisticated SPF and LSA rate-limiting mechanism that is able to react quickly to changes and also provide stability and protection during prolonged periods of instability.

When importing the set of addresses specified on an interface on which OSPFv3 is running into OSPFv3, you cannot select specific addresses to be imported. Either all addresses are imported, or no addresses are imported.

In order to ensure that OSPFv3 packets are not altered and re-sent to the router, causing the router to behave in a way not desired by its managers, OSPFv3 packets must be authenticated. OSPFv3 uses the IP Security (IPsec) secure socket application program interface (API) to add authentication to OSPFv3 packets. This API has been extended to provide support for IPv6.

OSPFv3 requires the use of IPsec to enable authentication. Crypto images are required to use authentication, because only crypto images include the IPsec API needed for use with OSPFv3.

In OSPFv3, authentication fields have been removed from OSPFv3 packet headers. When OSPFv3 runs on IPv6, OSPFv3 requires the IPv6 authentication header (AH) or IPv6 ESP header to ensure integrity, authentication, and confidentiality of routing exchanges. IPv6 AH and ESP extension headers can be used to provide authentication and confidentiality to OSPFv3.

To use the IPsec AH, you must enable the ipv6 ospf authentication command. To use the IPsec ESP, you must enable the ipv6 ospf encryption command. The ESP header may be applied alone or in combination with the AH, and when ESP is used, both encryption and authentication are provided. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host.

To configure IPsec, users configure a security policy, which is a combination of the security policy index (SPI) and the key (the key is used to create and validate the hash value). IPsec for OSPFv3 can be configured on an interface or on an OSPFv3 area. For higher security, users should configure a different policy on each interface configured with IPsec. If a user configures IPsec for an OSPFv3 area, the policy is applied to all of the interfaces in that area, except for the interfaces that have IPsec configured directly. Once IPsec is configured for OSPFv3, IPsec is invisible to the user.

The secure socket API is used by applications to secure traffic. The API needs to allow the application to open, listen, and close secure sockets. The binding between the application and the secure socket layer also allows the secure socket layer to inform the application of changes to the socket, such as connection open and close events. The secure socket API is able to identify the socket; that is, it can identify the local and remote addresses, masks, ports, and protocol that carry the traffic requiring security.

Each interface has a secure socket state, which can be one of the following:

• NULL: Do not create a secure socket for the interface if authentication is configured for the area.
• DOWN: IPsec has been configured for the interface (or the area that contains the interface), but OSPFv3 either has not requested IPsec to create a secure socket for this interface, or there is an error condition.
• GOING UP: OSPFv3 has requested a secure socket from IPsec and is waiting for a CRYPTO_SS_SOCKET_UP message from IPsec.
• UP: OSPFv3 has received a CRYPTO_SS_SOCKET_UP message from IPsec.
• CLOSING: The secure socket for the interface has been closed. A new socket may be opened for the interface, in which case the current secure socket makes the transition to the DOWN state. Otherwise, the interface will become UNCONFIGURED.
• UNCONFIGURED: Authentication is not configured on the interface.

OSPFv3 will not send or accept packets while in the DOWN state.

• OSPFv3 Virtual Links
• OSPFv3 Cost Calculation

You can customize OSPFv3 for your network, but you likely will not need to do so. The defaults for OSPFv3 are set to meet the requirements of most customers and features. If you must change the defaults, refer to the IPv6 command reference to find the appropriate syntax.

Caution

Be careful when changing the defaults. Changing defaults will affect your OSPFv3 network, possibly adversely.

• OSPFv3 Virtual Links

OSPFv3 is one of the routing protocols that can be used with Virtual Multipoint Interfaces (VMIs) in router-to-radio networks. The quality of a radio link has a direct impact on the throughput that can be achieved by router-router traffic. The PPPoE protocol has been extended to provide a process by which a router can request, or a radio can report, link quality metric information. Cisco's OSFPv3 implementation has been enhanced so that the route cost to a neighbor is dynamically updated based on metrics reported by the radio, thus allowing the best route to be chosen within a given set of radio links.

The routing protocols receive raw radio link data, and compute a composite quality metric for each link. In computing these metrics, the following factors may be considered:

• Maximum Data Rate--the theoretical maximum data rate of the radio link, in bytes per second
• Current Data Rate--the current data rate achieved on the link, in bytes per second
• Latency--the transmission delay packets encounter, in milliseconds
• Resources--a percentage (0 to 100) that can represent the remaining amount of a resource (such as battery power)
• Relative Link Quality--a numeric value (0-100) representing relative quality, with 100 being the highest quality

Metrics can be weighted during the configuration process to emphasize or de-emphasize particular characteristics. For example, if throughput is a particular concern, the current data rate metric could be weighted so that it is factored more heavily into the composite metric. Similarly, a metric that is of no concern can be omitted from the composite calculation.

Link metrics can change rapidly, often by very small degrees, which could result in a flood of meaningless routing updates. In a worst case scenario, the network would be churning almost continuously as it struggled to react to minor variations in link quality. To alleviate this concern, Cisco provides a tunable dampening mechanism that allows the user to configure threshold values. Any metric change that falls below the threshold is ignored.The quality of a connection to a neighbor varies, based on various characteristics of the interface when OSPF is used as the routing protocol. The routing protocol receives dynamic raw radio link characteristics and computes a composite metric that is used to reduce the effect of frequent routing changes.

A tunable hysteresis mechanism allows users to adjust the threshold to the routing changes that occur when the router receives a signal that a new peer has been discovered, or that an existing peer is unreachable. The tunable metric is weighted and is adjusted dynamically to account for the following characteristics:

• Current and maximum bandwidth
• Latency
• Resources
• L2 factor

Individual weights can be deconfigured and all weights can be cleared so that the cost is set back to the default value for the interface type. Based on the routing changes that occur, cost can be determined by the application of these metrics.

Per RFC 5340, the following rules indicate which paths are preferred when multiple intra-AS paths are available to ASBRs or forwarding addresses:

• Intra-area paths using nonbackbone areas are always the most preferred.
• The other paths, intraarea backbone paths and interarea paths, are of equal preference.

These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, and in the latter the paths terminate at separate ASBRs or forwarding addresses. In either case, each path is represented by a separate routing table entry. This feature applies only when RFC 1583 compatibility is set to disabled using the no compatibility rfc1583 command (RFC 5340 provides an update to RFC 1583).

Caution

To minimize the chance of routing loops, set identical RFC compatibility for all OSPF routers in an OSPF routing domain.

The graceful restart feature in OSPFv3 allows nonstop data forwarding along routes that are already known while the OSPFv3 routing protocol information is being restored. A device can participate in graceful restart either in restart mode (such as in a graceful-restart-capable router) or in helper mode (such as in a graceful-restart-aware router).

To perform the graceful restart function, a device must be in high availability (HA) stateful switchover (SSO) mode (that is, dual Route Processor (RP)). A device capable of graceful restart will perform the graceful restart function when the following failures occur:

• A RP failure that results in switchover to standby RP
• A planned RP switchover to standby RP

The graceful restart feature requires that neighboring devices be graceful-restart aware.

For further information about SSO and nonstop forwarding (NSF), see the Stateful Switchover and Cisco Nonstop Forwarding documents.

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    area area-ID [default-cost | nssa | stub]

5.    auto-cost reference-bandwidth Mbps

6.    bfd all-interfaces

7.    default {area area-ID[range ipv6-prefix | virtual-link router-id]} [default-information originate [always | metric | metric-type | route-map] | distance | distribute-list prefix-list prefix-list-name {in | out} [interface] | maximum-paths paths | redistribute protocol | summary-prefix ipv6-prefix]

8.    ignore lsa mospf

9.    interface-id snmp-if-index

10.    log-adjacency-changes [detail]

11.    passive-interface [default | interface-type interface-number]

12.    queue-depth {hello | update} {queue-size | unlimited}

13.    router-id {router-id}

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    address-family ipv6 unicast

5.    area area-ID range ipv6-prefix / prefix-length

6.    default {area area-ID[range ipv6-prefix | virtual-link router-id]} [default-information originate [always | metric | metric-type | route-map] | distance | distribute-list prefix-list prefix-list-name {in | out} [interface] | maximum-paths paths | redistribute protocol | summary-prefix ipv6-prefix]

7.    default-information originate [always | metric metric-value | metric-type type-value| route-map map-name]

8.    default-metric metric-value

9.    distance distance

10.    distribute-list prefix-list list-name {in[interface-type interface-number] | out routing-process [as-number]}

11.    maximum-paths number-paths

12.    summary-prefix prefix [not-advertise | tag tag-value]

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    address-family ipv4 unicast

5.    area area-id range ip-address ip-address-mask [advertise | not-advertise] [cost cost]

6.    default {area area-ID[range ipv6-prefix | virtual-link router-id]} [default-information originate [always | metric | metric-type | route-map] | distance | distribute-list prefix-list prefix-list-name {in | out} [interface] | maximum-paths paths | redistribute protocol | summary-prefix ipv6-prefix]

7.    default-information originate [always | metric metric-value | metric-type type-value| route-map map-name]

8.    default-metric metric-value

9.    distance distance

10.    distribute-list prefix-list list-name {in[interface-type interface-number] | out routing-process [as-number]}

11.    maximum-paths number-paths

12.    summary-prefix prefix [not-advertise | tag tag-value]

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    address-family ipv6 unicast

5.    redistribute source-protocol [process-id] [options]

1.    enable

2.    configure terminal

3.    interface type number

4.   Do one of the following:

OI  2001:DB8:0:7::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:6F00, GigabitEthernet0/0/0
OI  2001:DB8:0:8::/64 [110/100]
     via FE80::A8BB:CCFF:FE00:6F00, GigabitEthernet0/0/0
OI  2001:DB8:0:9::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:6F00, GigabitEthernet0/0/0

OI  2001:DB8::/48 [110/100]
     via FE80::A8BB:CCFF:FE00:6F00, GigabitEthernet0/0/0

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    address-family ipv6 unicast

5.    area area-ID range ipv6-prefix

• Defining an OSPFv3 Area Range

1.    enable

2.    configure terminal

3.    router ospfv3 process-id

4.    max-metric router-lsa [external-lsa [max-metric-value]] [include-stub] [inter-area-lsas [max-metric-value]] [on-startup {seconds | wait-for-bgp}] [prefix-lsa] [stub-prefix-lsa [max-metric-value]] [summary-lsa [max-metric-value]]

5.    exit

6.    show ospfv3 [process-id] max-metric

Once you have configured OSPFv3 and decided on your authentication, you must define the security policy on each of the routers within the group. The security policy consists of the combination of the key and the SPI. To define a security policy, you must define an SPI and a key.

You can configure an authentication or encryption policy either on an interface or for an OSPFv3 area. When you configure for an area, the security policy is applied to all of the interfaces in the area. For higher security, use a different policy on each interface.

You can configure authentication and encryption on virtual links.

• Defining Authentication on an Interface
• Defining Encryption on an Interface
• Defining Authentication in an OSPFv3 Area
• Defining Encryption in an OSPFv3 Area

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    timers lsa arrival milliseconds

5.    timers pacing flood milliseconds

6.    timers pacing lsa-group seconds

7.    timers pacing retransmission milliseconds

1.    enable

2.    configure terminal

3.    ipv6 router ospf process-id

4.    timers throttle spf spf-start spf-hold spf-max-wait

5.    timers throttle lsa start-interval hold-interval max-interval

6.    timers lsa arrival milliseconds

7.    timers pacing flood milliseconds

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    address-family ipv6 unicast

5.    event-log [one-shot | pause | size number-of-events]

• Enabling Event Logging for LSA and SPF Rate Limiting
• Clearing the Content of an Event Log

1.    enable

2.    configure terminal

3.    router ospfv3 [process-id]

4.    no compatible rfc1583

• Enabling OSPFv3 Graceful Restart on a Graceful-Restart-Capable Router
• Enabling OSPFv3 Graceful Restart on a Graceful-Restart-Aware Router

1.    enable

2.    clear ospfv3 [process-id] force-spf

3.    clear ospfv3 [process-id] process

4.    clear ospfv3 [process-id] redistribution

5.    clear ipv6 ospf [process-id] {process | force-spf | redistribution}

1.    enable

2.    show ospfv3 [process-id] border-routers

3.    show ospfv3 [process-id [area-id]] database [database-summary | internal | external[ipv6-prefix ] [link-state-id] | grace | inter-area prefix [ipv6-prefix | link-state-id] | inter-area router [destination-router-id | link-state-id] | link [interface interface-name | link-state-id] | network [link-state-id] | nssa-external [ipv6-prefix] [link-state-id] | prefix [ref-lsa {router | network} | link-state-id] | promiscuous | router [link-state-id] | unknown [{a rea | as | link} [link-state-id]] [adv-router router-id] [self-originate]

4.    show ospfv3 [process-id] events [generic | interface | lsa | neighbor | reverse | rib | spf]

5.    show ospfv3 [process-id] [area-id] flood-list interface-type interface-number

6.    show ospfv3 [process-id] graceful-restart

7.    show ospfv3 [process-id] [area-id] interface[type number] [brief]

8.    show ospfv3 [process-id] [area-id] neighbor[interface type interface-number] [neighbor-id] [detail]

9.    show ospfv3 [process-id] [area-id] request-list[neighbor] [interface] [interface neighbor]

10.    show ospfv3 [process-id] [area-id] retransmission-list [neighbor] [interface] [interface neighbor]

11.    show ospfv3 [process-id] statistic[detail]

12.    show ospfv3 [process-id] summary-prefix

13.    show ospfv3 [process-id] timers rate-limit

14.    show ospfv3 [process-id] traffic[interface-type interface-number]

15.    show ospfv3 [process-id] virtual-links

• Verifying OSPFv3 Configuration and Operation
• Examples