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 OSPF version 3 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 device configuration mode.

When using a nonbroadcast multiaccess (NBMA) interface in OSPFv3, you must manually configure the device with the list of neighbors. Neighboring devices are identified by their device ID.

In IPv6, you can configure many address prefixes on an interface. In OSPFv3, all address prefixes on an interface are included by default. You 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.

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 device 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, you may have two device 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.

If you have an IPv6 network that uses OSPFv3 as its Interior Gateway Protocol (IGP) you may want to use the same IGP to help carry and install IPv4 routes. All devices 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 devices exist around the edges running an IPv4 static or dynamic routing protocol. In this scenario, you need the ability to forward IPv4 traffic between these pockets without tunneling overhead, which means that any IPv4 transit device has both IPv4 and IPv6 forwarding stacks (that is, dual stack).

This feature allows a separate (possibly incongruent) topology to be constructed for the IPv4 AF. It installs IPv4 routes in the IPv4 Routing Information Base (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, you 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 the AF-specific RIB. LSAs that carry IPv6 unicast prefixes are used without any modification in different instances to carry each AF's 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 Shortest Path First (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 the 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 Release 15.1(3)S and Cisco IOS Release 15.2(1)T. Cisco devices that run software older than these releases and third-party devices will not neighbor with devices running the AF feature for the IPv4 AF because they do not set the AF bit. Therefore, those devices 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
  

On NBMA networks, the designated router (DR) or backup DR (BDR) performs the LSA flooding. On point-to-point networks, flooding simply goes out an interface directly to a neighbor.

Devices that share a common segment (Layer 2 link between two interfaces) become neighbors on that segment. OSPFv3 uses the Hello protocol, periodically sending hello packets out each interface. Devices become neighbors when they see themselves listed in the neighbor's hello packet. After two devices become neighbors, they may proceed to exchange and synchronize their databases, which creates an adjacency. Not all neighboring devices have an adjacency.

On point-to-point and point-to-multipoint networks, the software floods routing updates to immediate neighbors. There is no DR or BDR; all routing information is flooded to each networking device.

On broadcast or NBMA segments only, OSPFv3 minimizes the amount of information being exchanged on a segment by choosing one router to be a DR and one router to be a BDR. Thus, the devices on the segment have a central point of contact for information exchange. Instead of each device exchanging routing updates with every other device on the segment, each device exchanges information with the DR and BDR. The DR and BDR relay the information to the other devices.

The software looks at the priority of the devices on the segment to determine which devices will be the DR and BDR. The router with the highest priority is elected the DR. If there is a tie, then the router with the higher router ID takes precedence. After the DR is elected, the BDR is elected the same way. A device with a router priority set to zero is ineligible to become the DR or BDR.

When using NBMA in OSPFv3, you cannot automatically detect neighbors. On an NBMA interface, you must configure your neighbors manually using interface configuration mode.

When the process keyword is used with the clear ipv6 ospf command, the OSPFv3 database is cleared and repopulated, and then the SPF algorithm is performed. When the force-spf keyword is used with the clear ipv6 ospf command, the OSPFv3 database is not cleared before the SPF algorithm is performed.

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 a device learns multiple routes to a specific network via multiple routing processes (or routing protocols), it installs the route with the lowest administrative distance in the routing table. Sometimes the device must select a route from among many learned via the same routing process with the same administrative distance. In this case, the device chooses the path with the lowest cost (or metric) to the destination. Each routing process calculates its cost differently and the costs may need to be manipulated in order to achieve load balancing.

OSPFv3 performs load balancing automatically in the following way. If OSPFv3 finds that it can reach a destination through more than one interface and each path has the same cost, it installs each path in the routing table. The only restriction on the number of paths to the same destination is controlled by the maximum-paths command. The default maximum paths is 16, and the range is from 1 to 64.

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.

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.

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 system administrators, OSPFv3 packets must be authenticated. OSPFv3 uses the IPsec secure socket API to add authentication to OSPFv3 packets. This API supports 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 header, 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, you 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, you should configure a different policy on each interface configured with IPsec. If you configure 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 you.

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
  

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.

Bidirectional Forwarding Detection (BFD) supports OSPFv3.

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, Ethernet0/0
OI  2001:DB8:0:8::/64 [110/100]
     via FE80::A8BB:CCFF:FE00:6F00, Ethernet0/0
OI  2001:DB8:0:9::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:6F00, Ethernet0/0

OI  2001:DB8::/48 [110/100]
     via FE80::A8BB:CCFF:FE00:6F00, Ethernet0/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
  
• Defining Authentication and Encryption for a Virtual Link in an OSPFv3 Area
  

Before You Begin

Before you configure NBMA interfaces, you must perform the following tasks:

• Configure your network to be an NBMA network
• Identify each neighbor

Note	You cannot automatically detect neighbors when using NBMA interfaces. You must manually configure your router to detect neighbors when using an NBMA interface. When the ipv6 ospf neighbor command is configured, the IPv6 address used must be the link-local address of the neighbor.

1.    enable

2.    configure terminal

3.    interface type number

4.    frame-relay map ipv6 ipv6-address dlci [broadcast] [cisco] [ietf] [payload-compression {packet-by-packet | frf9 stac [ hardware-options] | data-stream stac [hardware-options]}]

5.    ipv6 ospf neighbor ipv6-address [priority number] [poll-interval seconds] [cost number] [database-filter all out]

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] [address-family] border-routers

3.    show ospfv3 [process-id [area-id]] [address-family] 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 [{area | as | link} [link-state-id]] [adv-router router-id] [self-originate]

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

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

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

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

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

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

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

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

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

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

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

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

• Verifying OSPFv3 Configuration and Operation
  
• Examples