No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).


This section describes the implementation of OSPFv3.

Principle of OSPFv3

Running on IPv6, OSPFv3 (defined in RFC 2740) is an independent routing protocol whose functions are enhanced on the basis of OSPFv2.

  • OSPFv3 and OSPFv2 are the same in respect of the working principles of the Hello message, state machine, link-state database (LSDB), flooding, and route calculation.

  • OSPFv3 divides an Autonomous System (AS) into one or more logical areas and advertises routes through LSAs.

  • OSPFv3 achieves unity of routing information by exchanging OSPFv3 packets between routers within an OSPFv3 area.

  • OSPFv3 packets are encapsulated into IPv6 packets, which can be transmitted in unicast or multicast mode.

Formats of OSPFv3 Packets

Packet Type


Hello packet

Hello packets are sent regularly to discover and maintain OSPFv3 neighbor relationships.

Database Description (DD) packet

A DD packet contains the summary of the local LSDB. It is exchanged between two OSPFv3 routers to update the LSDBs.

Link State Request (LSR) packet

LSR packets are sent to the neighbor to request the required LSAs.

An OSPFv3 router sends LSR packets to its neighbor only after they exchange DD packets.

Link State Update (LSU) packet

The LSU packet is used to transmit required LSAs to the neighbor.

Link State Acknowledgment (LSAck) packet

The LSAck packet is used to acknowledge the received LSA packets.

LSA Type

LSA Type


Router-LSA (Type1)

Generated by a router for each area to which an OSPFv3 interface belongs, the router LSA describes the status and costs of links of the router and is advertised in the area where the OSPFv3 interface belongs.

Network-LSA (Type2)

Generated by a designated router (DR), the network LSA describes the link status and is broadcast in the area that the DR belongs to.

Inter-Area-Prefix-LSA (Type3)

Generated on the area border router (ABR), an inter-area prefix LSA describes the route of a certain network segment within the local area and is used to inform other areas of the route.

Inter-Area-Router-LSA (Type4)

Generated on the ABR, an inter-area router LSA describes the route to the autonomous system boundary router (ASBR) and is advertised to all related areas except the area that the ASBR belongs to.

AS-external-LSA (Type5)

Generated on the ASBR, the AS-external LSA describes the route to a destination outside the AS and is advertised to all areas except the stub area and NSSA area.

NSSA-LSA (Type7)

Describes routes to a destination outside the AS. It is generated by an ASBR and advertised in NSSAs only.

Link-LSA (Type8)

Each router generates a link LSA for each link. A link LSA describes the link-local address and IPv6 address prefix associated with the link and the link option set in the network LSA. It is transmitted only on the link.

Intra-Area-Prefix-LSA (Type9)

Each router or DR generates one or more intra-area prefix LSAs and transmits it in the local area.

  • An LSA generated on a router describes the IPv6 address prefix associated with the router LSA.
  • An LSA generated on a DR describes the IPv6 address prefix associated with the network LSA.
Router Type
Figure 7-56 Router type

Table 7-30 Router types and descriptions

Router Type


Internal router

All interfaces on an internal router belong to the same OSPFv3 area.

Area border router (ABR)

An ABR can belong to two or more areas, but one of the areas must be a backbone area.

An ABR is used to connect the backbone area and the non-backbone areas. It can be physically or logically connected to the backbone area.

Backbone router

At least one interface on a backbone router belongs to the backbone area.

All ABRs and internal routers in Area 0, therefore, are backbone routers.

AS boundary router (ASBR)

A router that exchanges routing information with other ASs is called an ASBR.

An ASBR may not locate on the boundary of an AS. It can be an internal router or an ABR.

OSPFv3 Route Type

Inter-area routes and intra-area routes describe the network structure of an AS. External routes describe how to select a route to the destination outside an AS. OSPFv3 classifies the imported AS external routes into Type 1 routes and Type 2 routes.

Table 7-31 lists route types in a descending order of priority.

Table 7-31 Types of OSPFv3 routes

Route Type


Intra-area route

Indicates routes within an area.

Inter-area route

Indicates routes between areas.

Type1 external routes

Because of the high reliability of Type 1 external routes, the calculated cost of external routes is equal to that of AS internal routes, and can be compared with the cost of OSPFv3 routes.

That is, the cost of a Type1 external route equals the cost of the route from the router to the corresponding ASBR plus the cost of the route from the ASBR to the destination address.

Type2 external routes

Because of the low reliability of Type2 external routes, the cost of the route from the ASBR to a destination outside the AS is considered far greater than the cost of any internal path to an ASBR.

Therefore, OSPFv3 only takes the cost of the route from the ASBR to a destination outside the AS into account when calculating route costs. That is, the cost of a Type2 external route equals the cost of the route from the ASBR to the destination of the route.

Area Type
Table 7-32 Types of OSPFv3 areas

Area Type


Totally stub area

A totally stub area allows the Type3 default routes advertised by the ABR, and disallows the routes outside the AS and inter-area routes.

Stub area

A stub area allows inter-area routes, which is different from a totally stub area.


Imports routes outside an AS, which is different from a stub area. An ASBR advertises Type7 LSAs in the local area. These Type 7 LSAs are translated into Type 5 LSAs on an ABR, and are then flooded in the entire OSPFv3 AS.

Network Types Supported by OSPFv3

OSPFv3 classifies networks into the following types according to link layer protocols.

Table 7-33 Types of OSPFv3 networks

Network Type



If the link layer protocol is Ethernet or FDDI, OSPFv3 defaults the network type to broadcast.

In this type of networks, the following situations occur:

  • Hello messages, LSU packets, and LSAck packets are transmitted in multicast mode (FF02::5 is the reserved IPv6 multicast address of the OSPFv3 router; FF02::6 is the reserved IPv6 multicast address of the OSPFv3 DR or BDR).

  • DD packets and LSR packets are transmitted in unicast mode.

Non-broadcast Multiple Access (NBMA)

If the link layer protocol is frame relay, ATM, or X.25, OSPFv3 defaults the network type to NBMA.

In this type of networks, protocol packets such as Hello messages, DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted in unicast mode.

Point-to-Multipoint (P2MP)

Regardless of the link layer protocol, OSPFv3 does not default the network type to P2MP. A P2MP network must be forcibly changed from other network types. The common practice is to change a non-fully connected NBMA to a P2MP network.

In this type of networks, the following situations occur:

  • Hello messages are transmitted in multicast mode with the multicast address as FF02::5.

  • Other protocol packets, including DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted in unicast mode.

Point-to-point (P2P)

If the link layer protocol is PPP, HDLC, or LAPB, OSPFv3 defaults the network type to P2P.

In this type of network, the protocol packets, including Hello messages, DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted to the multicast address FF02::5.

Stub Area

A stub area is a special area where the ABRs do not flood the received external routes. In stub areas, the size of the routing table of the routers and the routing information in transmission are reduced.

Configuring a stub area is optional. Not all areas can be configured as stub areas. Usually, a stub area is a non-backbone area with only one ABR and is located at the AS boundary.

To ensure the reachability of a destination outside the AS, the ABR in the stub area generates a default route and advertises it to the non-ABR routers in the stub area.

Note the following when configuring a stub area:

  • The backbone area cannot be configured as a stub area.

  • If an area needs to be configured as a stub area, all the routers in this area must be configured with the stub command.

  • An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub area.

  • A virtual link cannot pass through the stub area.

OSPFv3 Route Summarization

Routing information can be decreased after route aggregation so that the size of routing tables is reduced, which improves the performance of routers.

The procedure for OSPFv3 route aggregation is as follows:

  • Route summarization on an ABR

    An ABR can summarize routes with the same prefix into one route and advertise the summarized route in other areas.

    When sending routing information to other areas, an ABR generates Type 3 LSAs based on IPv6 prefixes. If consecutive IPv6 prefixes exist in an area and route summarization is enabled on the ABR of the area, the IPv6 prefixes can be summarized into one prefix. If there are multiple LSAs that have the same prefix, the ABR summarizes these LSAs and advertises only one summarized LSA. The ABR does not advertise any specific LSAs.

  • Route summarization on an ASBR

    An ASBR can summarize imported routes with the same prefix into one route and then advertise the summarized route to other areas.

    After being enabled with route summarization, an ASBR summarizes imported Type 5 LSAs within the summarized address range. After route summarization, the ASBR does not generate a separate Type 5 LSA for each specific prefix within the configured range. Instead, the ASBR generates a Type 5 LSA for only the summarized prefix. In an NSSA, an ASBR summarizes multiple imported Type 7 LSAs within the summarized address range into one Type 7 LSA.

OSPFv3 Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-backbone area.

  • A virtual link must be set up on both ends of the link; otherwise, it does not take effect.

  • The transmit area refers to the area that provides an internal route of a non-backbone area for both the ends of the virtual link.

In actual applications, the physical connectivity between non-backbone areas and the backbone area cannot be ensured owing to various limitations. To solve this problem, you can configure OSPFv3 virtual links.

The virtual link is similar to a point-to-point connection between two ABRs. Similar to physical interfaces, the interfaces on the virtual link can be configured with parameters such as the hello interval.

Figure 7-57 OSPFv3 virtual link

As shown in Figure 7-57, OSPFv3 packets transmitted between two ABRs are only forwarded by the OSPFv3 devices that reside between the two ABRs. The OSPFv3 devices detect that they are not the destinations of the packets, so they forward the packets as common IP packets.

OSPFv3 Multi-process

OSPFv3 supports multi-process. More than one OSPFv3 process can run on the same router because processes are independent of each other. Route interaction between different OSPFv3 processes is similar to the route interaction between different routing protocols.

An interface of a router belongs to only a certain OSPFv3 process.


Graceful restart (GR) is a technology used to ensure normal traffic forwarding when a routing protocol restarts and guarantee that key services are not affected in the process.

GR is one of the high availability (HA) technologies, which comprise a series of comprehensive technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a redundancy technology, GR is widely used to ensure uninterrupted forwarding of key data in active/standby switchover and system upgrade.

If GR is not enabled, the active/standby switchover occurring owing to various causes leads to transient interruption of data forwarding, and as a result, route flapping occurs on the whole network. Such route flapping and service interruption are unacceptable on a large-scale network, especially on a carrier network.

In GR mode, the forwarding plane continues to direct data forwarding once a restart occurs, and the actions on the control plane, such as reestablishment of neighbor relationships and route calculation, do not affect the forwarding plane. In this manner, service interruption caused by route flapping is prevented so that the network reliability is improved.

Basic Concepts
  • Grace-LSA

    • OSPFv3 supports GR by flooding Grace-LSAs on the link.

    • Grace-LSAs are used to inform the neighbor of the GR time, cause, and interface instance ID when GR starts and ends.

  • Router function

    • A router can function as a GR restarter.

    • A router can function as a GR helper.

  • GR implementation

    • Planned-GR: This refers to the smooth restart of OSPFv3 through the reset ospfv3 graceful-restart command. In this mode, a Grace-LSA is sent to the neighbor before the restart.

    • Unplanned-GR: This refers to the active/standby switchover triggered by router faults like power down, dead loop, exception or reset in master.

      Unlike planned-GR, no Grace-LSA is sent before the active/standby switchover in unplanned GR mode. Instead, the switchover is directly performed. When the standby board becomes Up, a Grace-LSA is sent and the GR process starts. The following procedure is the same as that of planned GR.

GR Process
Figure 7-58 OSPFv3 planned-GR process (reset ospfv3 graceful-restart)

Figure 7-59 OSPFv3 unplanned-GR process (active/standby switchover)

  • On the GR restarter:

  1. In planned-GR mode, the GR restarter sends a Grace-LSA to all neighbors to inform them of the start of a GR process and the period and cause of this process.

    In unplanned GR mode, a Grace-LSA is sent to each neighbor immediately after the standby board is Up to inform the neighbors of the start of a GR process and the period and cause of the process.

  2. The GR restarter performs negotiation with neighbors again to set up new neighbor relationships.

  3. When all the neighbor relationships between the GR restarter and the original neighbors enter the Full state:

    • The GR restarter exits from the GR process and OSPFv3 recalculates routes.

    • The GR restarter updates the routing table on the switch module and the FIBs on interface boards and deletes invalid routing entries.

    • The GR restarter sends a Grace-LSA whose aging time is 3600 seconds to instruct the GR helper to exit from the GR process.

    Now, the GR process is complete.

  4. If errors occur during a GR process, the GR timer expires, or the neighbor relationship fails to enter the Full state during a GR process, the GR restarter exits from the process and OSPFv3 is restarted in non-GR mode. In this case, packets are lost.

  • On the GR helper:

  1. If a router is configured to support the GR process on its neighbor, the router enters the helper mode after receiving a Grace-LSA.

  2. The GR helper maintains its neighbor relationship with the GR restarter, and the status of the neighbor relationship does not change.

  3. If the GR helper continues to receive Grace-LSAs whose GR period is different from that on the GR helper, the GR helper updates its GR period.

  4. Being informed of the successful GR process through a Grace-LSA whose aging time is 3600 seconds from the GR restarter, the GR helper exits from the GR process.

  5. If errors occur during a GR process, the GR helper exits from the helper state and deletes invalid routes after route calculation.

Comparison between the GR Mode and the Non-GR Mode
Table 7-34 Comparison between the OSPFv3 GR mode and the OSPFv3 non-GR mode

Active/Standby Switchover in Non-GR Mode

Active/Standby Switchover in GR Mode

  • OSPFv3 neighbor relationships are reestablished.

  • Routes are recalculated.

  • The forwarding table changes.

  • Route changes are sensed on the network and route flapping occurs over a short period of time.

  • Packets are lost during forwarding, and services are interrupted.

  • OSPFv3 neighbor relationships are reestablished.

  • Routes are recalculated.

  • The forwarding table remains the same.

  • Except the neighbor of the device where the active/standby switchover occurs, other routers do not sense the route changes.

  • No packets are lost during forwarding, and services are not affected.

Association between OSPFv3 and BGP

When a new router is deployed in the network or a router is restarted, the network traffic may be lost during BGP convergence. This is because IGP convergence is quicker than BGP convergence. This problem can be solved through the association between OSPFv3 and BGP.

If a router on a BGP network recovers from a fault, BGP convergence is performed again and certain packets may be lost during the convergence.

As shown in Figure 7-60, traffic from RouteA to RouterD passes through RouterC, and traverses a BGP network.

Figure 7-60 Traffic traversing a BGP network

If a fault occurs on RouterC, traffic is redirected to RouterB after rerouting. Packets are lost when RouterC is restored to the normal status.

Because OSPFv3 convergence is quicker than BGP convergence, OSPFv3 convergence is complete when RouterC recovers. The next hop of the route from RouterA to RouterD is RouterC, which, however, does not know the route to RouterD since BGP convergence on RouterC is not complete.

Thus, when the packets destined for RouterD are transmitted from RouterA to RouterC, they are discarded by RouterC because RouterC has no route to RouterD, as shown in Figure 7-61.

Figure 7-61 Packet loss during the restart of the device not enabled with association between OSPFv3 and BGP

Process of Association between OSPFv3 and BGP

When a router enabled with association between OSPFv3 and BGP restarts, the router advertises a message in the local OSPFv3 area to instruct other routers not to use it as a transit router.

At the same time, the router sets the largest weight value of 65535 in its LSAs to ensure that it is not used by other routers as the transit router. The BGP route, however, can still reach the router.

Comparison between OSPFv3 and OSPFv2

OSPFv3 and OSPFv2 are the same in the following aspects:

  • Network type and interface type

  • Interface state machine and neighbor state machine

  • LSDB

  • Flooding mechanism

  • Five types of packets, including Hello, DD, LSR, LSU, and LSAck packets

  • Route calculation

OSPFv3 and OSPFv2 are different in the following aspects:

  • OSPFv3 is based on links rather than network segments.

    OSPFv3 runs on IPv6, which is based on links rather than network segments.

    Therefore, you need not to configure OSPFv3 on the interfaces in the same network segment. It is only required that the interfaces enabled with OSPFv3 are on the same link. In addition, the interfaces can set up OSPFv3 sessions without IPv6 global addresses.

  • OSPFv3 does not depend on IP addresses.

    This is to separate topology calculation from IP addresses. That is, OSPFv3 can calculate the OSPFv3 topology without knowing the IPv6 global address, which only applies to virtual link interfaces for packet forwarding.

  • OSPFv3 packets and LSA format change.

    • OSPFv3 packets do not contain IP addresses.

    • OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are advertised by Link LSAs and Intra Area Prefix LSAs.

    • In OSPFv3, Router IDs, area IDs, and LSA link state IDs no longer indicate IP addresses, but the IPv4 address format is still reserved.

    • Neighbors are identified by Router IDs instead of IP addresses in broadcast, NBMA, or P2MP networks.

  • Information about the flooding scope is added in LSAs of OSPFv3.

    Information about the flooding scope is added in the LSA Type field of LSAs of OSPFv3. Thus, OSPFv3 routers can process LSAs of unidentified types, which makes the processing more flexible.

    • OSPFv3 can store or flood unidentified packets, whereas OSPFv2 just discards unidentified packets.

    • OSPFv3 floods packets in an OSPF area or on a link. It sets the U flag bit of packets (the flooding area is based on the link local) so that unidentified packets are stored or forwarded to the stub area.

    For example, RouterA and RouterB can identify LSAs of a certain type. They are connected through RouterC, which, however, cannot identify this type of LSAs. When RouterA floods an LSA of this type, RouterC can still flood the received LSA to RouterB although it does not identify this LSA. RouterB then processes the LSA.

    If OSPFv2 is run, RouterC discards the unidentified LSA so that the LSA cannot reach RouterB.

  • OSPFv3 supports multi-process on a link.

    Only one OSPFv2 process can be configured on a physical interface.

    In OSPFv3, one physical interface can be configured with multiple processes that are identified by different instance IDs. That is, multiple OSPFv3 instances can run on one physical link. They establish neighbor relationships with the other end of the link and transmit packets to the other end without interfering with each other.

    Thus, the resources of a link can be shared among OSPFv3 instances that simulate multiple OSPFv3 routers, which improves the utilization of limited router resources.

  • OSPFv3 uses IPv6 link-local addresses.

    IPv6 implements neighbor discovery and automatic configuration based on link-local addresses. Routers running IPv6 do not forward IPv6 packets whose destination address is a link-local address. Those packets can only be exchanged on the same link. The unicast link-local address starts from FE80/10.

    As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to maintain neighbor relationships and update LSDBs. Except Vlink interfaces, all OSPFv3 interfaces use link-local addresses as the source address and that of the next hop to transmit OSPFv3 packets.

    The advantages are as follows:
    • The OSPFv3 can calculate the topology without knowing the global IPv6 addresses so that topology calculation is not based on IP addresses.

    • The packets flooded on a link are not transmitted to other links, which prevents unnecessary flooding and saves bandwidth.

  • OSPFv3 packets do not contain authentication fields.

    OSPFv3 directly adopts IPv6 authentication and security measures. Thus, OSPFv3 does not need to perform authentication. It only focuses on the processing of packets.

  • OSPFv3 supports two new LSAs.

    • Link LSA: A router floods a link LSA on the link where it resides to advertise its link-local address and the configured global IPv6 address.

    • Intra Area Prefix LSA: A router advertises an intra-area prefix LSA in the local OSPF area to inform the other routers in the area or the network, which can be a broadcast network or a NBMA network, of its IPv6 global address.

  • OSPFv3 identifies neighbors based on router IDs only.

    On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on IPv4 addresses of interfaces.

    OSPFv3 identifies neighbors based on router IDs only. Thus, even if global IPv6 addresses are not configured or they are configured in different network segments, OSPFv3 can still establish and maintain neighbor relationships so that topology calculation is not based on IP addresses.

Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59640

Downloads: 3623

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Previous Next