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

Reminder

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

upgrade

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).
Principle

Principle

This section describes the implementation of OSPF.

Fundamentals of OSPF

OSPF has the following functions:

  • Divides an Autonomous System (AS) into one or multiple logical areas.

  • Advertises routes by sending Link State Advertisements (LSAs).

  • Exchanges OSPF packets between devices in an OSPF area to synchronize routing information.

  • Encapsulates OSPF packets into IP packets and sends the packets in unicast or multicast mode.

Packet Type
Table 7-12 packet type

Packet Type

Function

Hello packet

Sent periodically to discover and maintain OSPF neighbor relationships.

Database Description (DD) packet

Contains brief information about the local link-state database (LSDB) and synchronizes the LSDBs on two devices.

Link State Request (LSR) packet

Requests the required LSAs from neighbors.

LSR packets are sent only after DD packets are exchanged successfully.

Link State Update (LSU) packet

Sends the required LSAs to neighbors.

Link State Acknowledgement (LSAck) packet

Acknowledges the receipt of an LSA.

LSA Type
Table 7-13 LSA type

LSA Type

Function

Router-LSA (Type 1)

Describes the link status and link cost of a router. It is generated by every router and advertised in the area to which the router belongs.

Network-LSA (Type 2)

Describes the link status of all routers on the local network segment. Network-LSAs are generated by a designated router (DR) and advertised in the area to which the DR belongs.

Network-summary-LSA (Type 3)

Describes routes to a specific network segment in an area. Network-summary-LSAs are generated by an Area Border Router (ABR) and advertised in all areas except totally stub areas and Not-So-Stubby Areas (NSSA Areas).

ASBR-summary-LSA (Type 4)

Describes routes to an Autonomous System Boundary Router (ASBR). ASBR-summary-LSAs are generated by an ABR and advertised to all related areas except the area to which the ASBR belongs.

AS-external-LSA (Type 5)

Describes routes to a destination outside the AS. AS-external-LSAs are generated by an ASBR and advertised to all areas except stub areas and NSSA areas.

NSSA-LSA (Type7)

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

Opaque-LSA (Type 9/Type 10/Type 11)

Provides a universal mechanism for OSPF extension.

  • Type 9 LSAs are advertised only on the network segment where the interface originating Type 9 LSAs resides. Grace LSAs used to support GR are a type of Type 9 LSAs.
  • Type 10 LSAs are advertised inside an OSPF area. LSAs used to support TE are a type of Type 10 LSAs.
  • Type 11 LSAs are advertised within an AS. At present, there are no applications of Type 11 LSAs.
Router Type

Figure 7-30 lists common Router types used in OSPF.

Figure 7-30 Router type

Table 7-14 Router type

Router Type

Description

Internal router

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

Area Border Router (ABR)

An ABR belongs to two or more than two areas, one of which must be the backbone area.

An ABR is used to connect the backbone area and 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.

Internal routers in Area 0 and all ABRs are backbone routers.

ASBR (AS Boundary Router)

An ASBR exchanges routing information with other ASs.

An ASBR does not necessarily reside on the border of an AS. It can be an internal router or an ABR. An OSPF device that has imported external routing information will become an ASBR.

Route Type

Inter-area and intra-area routes in an AS describe the AS's network structure. AS external routes describe the routes to destinations outside an AS. OSPF classifies the imported AS external routes into Type 1 and Type 2 external routes.

Table 7-15 lists route types in descending priority order.

Table 7-15 route type

Route Type

Description

Intra-area route

Indicates routes within an area.

Inter-area route

Indicates routes between areas.

Type 1 external route

Type 1 external routes have high reliability.

Cost of a Type 1 external route = Cost of the route from a local router to an ASBR + Cost of the route from the ASBR to the destination of the Type 1 external route

Type 2 external route

Type 2 external routes have low reliability, and therefore OSPF considers that the cost of the route from an ASBR to the destination of a Type 2 external route is much greater than the cost of any internal route to the ASBR.

Cost of a Type 2 external route = Cost of the route from the ASBR to the destination of the Type 2 external route

Area Type
Table 7-16 area type

Area Type

Function

Common area

OSPF areas are common areas by default. Common areas include standard areas and backbone areas.

  • A standard area is the most common area and transmits intra-area routes, inter-area routes, and external routes.
  • A backbone area connects all the other OSPF areas. It is usually named Area 0.

Stub area

A stub area does not advertise AS external routes, but only intra-area and inter-area routes.

Compared with a non-stub area, the Router in a stub area maintains fewer routing entries and transmits less routing information.

To ensure the reachability of AS external routes, the ABR in a stub area advertises Type 3 default routes to the entire stub area. All AS external routes must be advertised by the ABR.

Totally stub area

A totally stub area does not advertise AS external routes or inter-area routes, but only intra-area routes.

Compared with a non-stub area, the Router in a totally stub area maintains fewer routing entries and transmits less routing information.

To ensure the reachability of AS external and inter-area routes, the ABR in a totally stub area advertises Type 3 default routes to the entire totally stub area. All AS external and inter-area routes must be advertised by the ABR.

NSSA area

An NSSA area can import AS external routes. An ASBR uses Type 7 LSAs to advertise the imported AS external routes to the entire NSSA area. These Type 7 LSAs are translated into Type 5 LSAs on an ABR, and are then flooded in the entire OSPF AS.

An NSSA area has the characteristics of the stub areas in an AS.

An ABR in an NSSA area advertises Type 3 default routes to the entire NSSA area. All inter-area routes must be advertised by the ABR.

Totally NSSA area

A totally NSSA area can import AS external routes. An ASBR uses Type 7 LSAs to advertise the imported AS external routes to the entire NSSA area. These Type 7 LSAs are translated into Type 5 LSAs on an ABR, and are then flooded in the entire OSPF AS.

A totally NSSA area has the characteristics of the totally stub areas in an AS.

An ABR in a totally NSSA area advertises Type 3 default routes to the entire totally NSSA area. All inter-area routes must be advertised by the ABR.

OSPF Network Type

Table 7-17 lists four OSPF network types that are classified based on link layer protocols.

Table 7-17 OSPF network type

Network Type

Description

Broadcast

A network with the link layer protocol of Ethernet or Fiber Distributed Data Interface (FDDI) is a broadcast network by default.

On a broadcast network:

  • Hello packets, LSU packets, and LSAck packets are usually transmitted in multicast mode. 224.0.0.5 is an IP multicast address reserved for an OSPF device. 224.0.0.6 is an IP multicast address reserved for an OSPF DR or backup designated router (BDR).

  • DD and LSR packets are transmitted in unicast mode.

Non-Broadcast Multi-Access (NBMA)

A network with the link layer protocol of frame relay (FR), X.25 is an NBMA network by default.

On an NBMA network, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.

Point-to-Multipoint (P2MP)

No network is a P2MP network by default, no matter what type of link layer protocol is used on the network. A network can be changed to a P2MP network. The common practice is to change a non-fully meshed NBMA network to a P2MP network.

On a P2MP network:

  • Hello packets are transmitted in multicast mode using the multicast address 224.0.0.5.

  • Other types of protocol packets, such as DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.

Point-to-point (P2P)

By default, a network where the link layer protocol is PPP, HDLC, or LAPB is a P2P network.

On a P2P network, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in multicast mode using the multicast address 224.0.0.5.

Stub Area

Stub areas are specific areas where ABRs do not flood the received AS external routes. In stub areas, Routers maintain fewer routing entries and less routing information.

Configuring a stub area is optional. Not every area can be configured as a stub area. A stub area is usually a non-backbone area with only one ABR and is located at the AS border.

To ensure the reachability of the routes to destinations outside an AS, the ABR in the stub area generates a default route and advertises the route to the non-ABRs in the same stub area.

Note the following points when configuring a stub area:

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

  • Before configuring an area as a stub area, you must configure stub area attributes on all Routers in the area.

  • There should be no ASBR in a stub area, meaning that AS external routes cannot be transmitted in the stub area.

  • Virtual connections cannot cross a stub area.

NSSA Area

NSSA areas are a special type of OSPF areas. There are many similarities between an NSSA area and a stub area. Both of them do not advertise the external routes received from the other OSPF areas. The difference is that a stub area cannot import AS external routes, whereas an NSSA area can import AS external routes and advertise the imported routes to the entire AS.

After an area is configured as an NSSA area, an ABR in the NSSA area generates a default route and advertises the route to the other Routers in the NSSA area. This is to ensure the reachability of the routes to the destinations outside an AS.

Note the following points when configuring an NSSA area:

  • The backbone area cannot be configured as an NSSA area.
  • Before configuring an area as an NSSA area, you must configure NSSA area attributes on all Routers in the area.
  • Virtual connections cannot cross an NSSA area.
Neighbor State Machine

OSPF has eight state machines: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and Full.

  • Down: It is in the initial stage of setting up sessions between neighbors. The state machine is Down when a router fails to receive Hello packets from its neighbor before the dead interval expires.

  • Attempt: It occurs only on an NBMA network. The state machine is Attempt when a neighbor does not reply with Hello packets after the dead interval has expired. The local router, however, keeps sending Hello packets to the neighbor at every poll interval.

  • Init: The state machine is Init after a router receives Hello packets.

  • 2-way: The state machine is 2-way when the Hello packets received by a router contain its own router ID. The state machine will remain in the 2-way state if no neighbor relationship is established, and will become Exstart if a neighbor relationship is established.

  • Exstart: The state machine is Exstart when the two neighbors start to negotiate the master/slave status and determine the sequence numbers of DD packets.

  • Exchange: The state machine is Exchange when a router starts to exchange DD packets with its neighbor after the master/slave status negotiation is completed.

  • Loading: The state machine is Loading after a router has finished exchanging DD packets with its neighbor.

  • Full: The state machine is Full when the LSA retransmission list is empty.

OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that have been authenticated can be received. If OSPF packets are not authenticated, a neighbor relationship cannot be established.

The Router supports two authentication methods:

  • Area-based authentication

  • Interface-based authentication

When both area-based and interface-based authentication methods are configured, interface-based authentication takes effect.

OSPF Route Summarization

Route summarization means that an ABR in an area summarizes the routes with the same prefix into one route and advertises the summarized route to the other areas.

Route summarization between areas reduces the amount of routing information to be transmitted, reducing the size of routing tables and improving device performance.

Route summarization can be carried out by an ABR or an ASBR:

  • Route summarization on an ABR:

    When an ABR in an area advertises routing information to other areas, it generates Type 3 LSAs by network segment. If this area contains consecutive network segments, you can run a command to summarize these network segments into one network segment. The ABR only needs to send one summarized LSA, and will not send the LSAs that belong to the summarized network segment specified in the command.

  • Route summarization on an ASBR:

    If the local device is an ASBR and route summarization is configured, the ASBR will summarize the imported Type 5 LSAs within the aggregated address range. After an NSSA area is configured, the ASBR needs to summarize the imported Type 7 LSAs within the aggregated address range.

    If the local device is an ASBR and ABR, the device will summarize the Type 5 LSAs that are translated from Type 7 LSAs.

OSPF Default Route

A default route is a route of which the destination address and mask are all 0s. If a router cannot find a route in its routing table for forwarding packets, it can forward packets using a default route. Due to hierarchical management of OSPF routes, the priority of default Type 3 routes is higher than the priority of default Type 5 or Type 7 routes.

OSPF default routes are usually used in the following cases:

  • An ABR advertises default Type 3 Summary LSAs to instruct routers within an area to forward packets between areas.

  • An ASBR advertises default Type 5 ASE LSAs or default Type 7 NSSA area LSAs to instruct routers in an AS to forward packets to other ASs.

Principles for advertising OSPF default routes are described below:
  • An OSPF router advertises an LSA that describes a default route only when an interface on the OSPF router is connected to a network outside an area.
  • If an OSPF router has advertised an LSA carrying information about a type of default route, the OSPF router does not learn this type of default routes advertised by other routers. This means that the OSPF router no longer calculates routes based on the LSAs carrying information about the same type of the default routes advertised by other routers, but stores these LSAs in its LSDB.
  • The route on which default external route advertisement depends cannot be a route in the local OSPF AS. This means that the route cannot be the one learned by the local OSPF process. This is because default external routes are used to guide packet forwarding outside an AS, whereas the routes within an AS have the next hop pointing to the devices within the AS.

Table 7-18 lists principles for advertising default routes in different areas.

Table 7-18 Principles for advertising OSPF default routes

Area Type

Function

Common area

By default, devices in a common OSPF area do not automatically generate default routes, even if the common OSPF area has default routes.

When a default route on the network is generated by another routing process (not OSPF process), the device that generates the default route must advertise the default route in the entire OSPF AS. (Run a command on an ASBR to configure the ASBR to generate a default route. After the configuration, the ASBR generates a default Type 5 ASE LSA and advertises the LSA to the entire OSPF AS.)

STUB area

A stub area does not allow AS external routes (Type 5 LSAs) to be transmitted within the area.

All routers within the stub area must learn AS external routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and advertises it to the entire stub area. Then all routes to destinations outside an AS can be learned from the ABR.

Totally STUB area

A totally stub area does not allow AS external routes (Type 5 LSAs) or inter-area routes (Type 3 LSAs) to be transmitted within the area.

All routers within the totally stub area must learn AS external routes and other areas' routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and advertises it to the entire totally stub area. Then, all routes to destinations outside an AS and to destinations in other areas can be learned from the ABR.

NSSA area

An NSSA area allows its ASBRs to import a small number of AS external routes, but does not advertise ASE LSAs (Type 5 LSAs) received from other areas within the NSSA area. This means that AS external routes can be learned only from ASBRs in the NSSA area.

Devices in an NSSA area do not automatically generate default routes.

Use either of the following methods as required:
  • To advertise some external routes using the ASBR in the NSSA area and advertise other external routes through other areas, configure a default Type 7 LSA on the ABR and advertise this LSA in the entire NSSA area.
  • To advertise all the external routes using the ASBR in the NSSA area, configure a default Type 7 LSA on the ASBR and advertise this LSA in the entire NSSA area.

The difference between these two configurations is described below:

  • An ABR will generate a default Type 7 LSA regardless of whether the routing table contains the default route 0.0.0.0.
  • An ASBR will generate a default Type 7 LSA only when the routing table contains the default route 0.0.0.0.

A default route is flooded only in the local NSSA area and is not flooded in the entire OSPF AS. If Routers in the local NSSA area cannot find routes to the outside of the AS, the Routers can forward packets to the outside of the AS through an ASBR. Packets of other OSPF areas, however, cannot be sent to the outside of the AS through this ASBR. Default Type 7 LSAs will not be translated into default Type 5 LSAs and flooded in the entire OSPF AS.

Totally NSSA area

A totally NSSA area does not allow AS external routes (Type 5 LSAs) or inter-area routes (Type 3 LSAs) to be transmitted within the area.

All Routers within the totally NSSA area must learn AS external routes from the ABR. The ABR automatically generates a default Summary LSAs and advertises it to the entire totally NSSA area. Then all external routes received from other areas and inter-area routes can be advertised within the totally NSSA area.

OSPF Route Filtering

OSPF supports route filtering using routing policies. By default, OSPF does not filter routes.

Routing policies used by OSPF include the route-policy, access-list, and prefix-list.

OSPF route filtering can be used for:

  • Importing routes

    OSPF can import routes learned by other routing protocols. You can configure routing policies to filter the imported routes to allow OSPF to import only the routes that match specific conditions.

  • Advertising imported routes

    OSPF advertises the imported routes to its neighbors.

    You can configure filtering rules to filter the routes to be advertised. The filtering rules can be configured only on ASBRs.

  • Learning routes

    Filtering rules can be configured to allow OSPF to filter the received intra-area, inter-area, and AS external routes.

    After receiving routes, an OSPF device adds only the routes that match the filtering rules to the local routing table, but can still advertise all routes from the OSPF routing table.

  • Learning inter-area LSAs

    You can run a command to configure an ABR to filter the incoming Summary LSAs. This configuration takes effect only on ABRs because only ABRs can advertise Summary LSAs.

    Table 7-19 Differences between inter-area LSA learning and route learning

    Inter-area LSA Learning

    Route Learning

    Directly filters the incoming LSAs.

    Filters the routes that are calculated based on LSAs, but does not filter LSAs. This means that all incoming LSAs are learned.

  • Advertising inter-area LSAs

    You can run a command to configure an ABR to filter the outgoing Summary LSAs. This configuration takes effect only on ABRs.

OSPF Multi-Process

OSPF supports multi-process. Multiple OSPF processes can run on the same Router, and they are independent of each other. Route exchanges between different OSPF processes are similar to route exchanges between different routing protocols.

Each interface on the Router belongs to only one OSPF process.

A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in a VPN, whereas OSPF is used as an IGP on the backbone of the VPN. Two OSPF processes on the same PE are independent of each other.

OSPF RFC 1583 Compatibility

RFC 1583 is an earlier version of OSPFv2.

When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC 1583 define different route selection rules. To prevent routing loops, both communication ends must use the same route selection rules.

  • After RFC 1583 compatibility is enabled, OSPF use the route selection rules defined in RFC 1583.
  • When RFC 1583 compatibility is disabled, OSPF uses the route selection rules defined in RFC 2328.
OSPF calculates external routes based on Type 5 LSAs. If the Router enabled with RFC 1583 compatibility receives a Type 5 LSA:
  • The Router selects a route to the ASBR that originates the LSA, or to the forwarding address (FA) described in the LSA.
  • The Router selects external routes to the same destination.

By default, OSPF uses the route selection rules defined in RFC 1583.

BFD for OSPF

Definition

Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults between forwarding engines.

To be specific, BFD detects connectivity of a data protocol on a path between two systems. The path can be a physical link, a logical link, or a tunnel.

In BFD for OSPF, a BFD session is associated with OSPF. The BFD session quickly detects a link fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of the network topology.

Purpose

The link fault or the topology change may cause devices to re-calculate routes. Therefore, the convergence of routing protocols must be as quick as possible to improve the network performance.

Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster and notify the faults to routing protocols immediately. If BFD is associated with OSPF, once a fault occurs on a link between neighbors, BFD can speed up the OSPF convergence.

Table 7-20 Comparison before and after BFD for OSPF is enabled

Associated with BFD or Not

Link Fault Detection Mechanism

Convergence Speed

Not associated with BFD

An OSPF Dead timer expires. By default, the timeout period of the timer is 40s.

At the second level

Associated with BFD

A BFD session goes Down.

At the millisecond level

Principle
Figure 7-31 BFD for OSPF

The principle of BFD for OSPF is shown in Figure 7-31.

  1. OSPF neighbor relationships are established between these three routers.

  2. After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session.

  3. The outbound interface on RouterA connected to RouterB is GE 2/17/0. If the link fails, BFD detects the fault and then notifies RouterA of the fault.

  4. RouterA processes the event that a neighbor relationship becomes Down and re-calculates routes. After calculation, the outbound interface is GE1 /17/0 passes through RouterC and then reaches RouterB.

OSPF Smart-discover

Definition

Generally, Routers periodically send Hello packets through OSPF interfaces. That is, a Router sends Hello packets at the Hello interval set by a Hello timer. Because Hello packets are sent at a fixed interval, the speed at which OSPF neighbor relationship is established is lowered.

Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in specific scenarios.

Table 7-21 OSPF Smart-discover

Smart-discover Configured or Not

Processing

Smart-discover is not configured

  • Hello packets are sent only when the Hello timer expires.

  • The gap between the sending of two Hello packets is the Hello interval.

  • Neighbors keep waiting to receive Hello packets within the Hello interval.

Smart-discover is configured

  • Hello packets are sent directly regardless of whether the Hello timer expires.

  • Neighbors can receive packets rapidly and perform status transition immediately.

Principle

In the following scenarios, the interface enabled with Smart-discover can send Hello packets to neighbors without having to wait for the Hello timer to expire:

  • The neighbor status becomes 2-way for the first time.

  • The neighbor status changes from 2-way or a higher state to Init.

OSPF VPN

Definition

As an extension of OSPF, OSPF VPN multi-instance enables Provider Edges (PEs) and Customer Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and advertise routes.

Purpose

As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and CEs, and PEs advertise VPN routes to CEs using OSPF, CEs do not need to support other routing protocols for interworking with PEs. This simplifies management and configuration of CEs.

Running OSPF Between PEs and CEs

In BGP/MPLS VPN, routing information is transmitted between PEs using Multi-Protocol BGP (MP-BGP), whereas routes are learned and advertised between PEs and CEs using OSPF.

Running OSPF between PEs and CEs has the following benefits:

  • OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce the protocol types that switch must support, reducing the requirements for switch.

  • Similarly, running OSPF both in a site and between PEs and CEs simplifies the workload of network administrators. In this manner, network administrators do not have to be familiar with multiple protocols.

  • When a network using OSPF but not VPN on the backbone network begins to use BGP/MPLS VPN, running OSPF between PEs and CEs facilitates the transition.

As shown in Figure 7-32, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF refer to the process IDs of multiple OSPF instances running on PEs.

Figure 7-32 Running OSPF between PEs and CEs

The process of advertising routes of CE1 to CE3 and CE4 is as follows:

  1. PE1 imports OSPF routes of CE1 into BGP and forms BGP VPNv4 routes.

  2. PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.

  3. PE2 imports BGP VPNv4 routes into OSPF, and then advertises these routes to CE3 and CE4.

The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.

Configuring OSPF Areas Between PEs and CEs

OSPF areas between PEs and CEs can be either non-backbone areas or backbone areas (Area 0). A PE can only be an area border router (ABR).

In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area 0. OSPF requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be connected to the MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that CEs access must be connected to the backbone area of this VPN site through Area 0. If no physical link is available to directly connect PEs to the backbone area, a virtual link can be used to implement logical connection between the PEs and the backbone area, as shown in Figure 7-33.

Figure 7-33 Configuring OSPF areas between PEs and CEs

A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is configured in Site 1. As a result, the backbone area in Site 1 is separated from the VPN backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the backbone area is contiguous.

OSPF Domain ID

If inter-area routes are advertised between local and remote OSPF areas, these areas are considered to be in the same OSPF domain.

  • Domain IDs identify and differentiate different domains.

  • Each OSPF domain has one or more domain IDs, one of which is a primary ID with the others being secondary IDs.

  • If an OSPF instance does not have a specific domain ID, its ID is considered as null.

Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of OSPF routes (Type 3, Type 5 or Type 7) to be advertised to CEs according to domain IDs.

  • If local domain IDs are the same as or compatible with remote domain IDs in BGP routes, PEs advertise Type 3 routes.

  • Otherwise, PEs advertise Type 5 or Type 7 routes.

Table 7-22 Domain ID

Comparison Between Local and Remote Domain IDs

Local and Remote Domain IDs the Same Or Not

Route Type

Both the local and remote domain IDs are null.

The same

Inter-area route

The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs.

The same

Inter-area route

The remote domain ID is different from the local primary domain ID or any of the local secondary domain IDs.

Not the same

If the local area is a non-NSSA, external routes are generated.

If the local area is an NSSA, NSSA routes are generated.

Disabling Routing Loop Prevention

Disabling routing loop prevention may cause routing loops. Exercise caution when performing this operation.

During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops in VPN sites.

In the inter-AS VPN Option A scenario, if OSPF is running between ASBRs to transmit VPN routes, the remote ASBR may be unable to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.

As shown in Figure 7-34, inter-AS VPN Option A is deployed. OSPF is running between PE1 and CE1. CE1 sends VPN routes to CE2.

Figure 7-34 Networking diagram for inter-AS VPN Option A

  1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, and imports these routes into MP-BGP, and sends the MP-BGP routes to ASBR1.

  2. After having received the MP-BGP routes, ASBR1 imports the routes into the OSPF process in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs in which the DN bit is set to 1.

  3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. After learning that the DN bit in each LSA is set to 1, ASBR2 does not add the routing information carried in these LSAs to its routing table.

Due to the routing loop prevention mechanism, ASBR2 cannot learn the OSPF routes sent from ASBR1, causing CE1 to be unable to communicate with CE3.

To address the preceding problem, use either of the following methods:

  • A device does not set the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For example, ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF. After ASBR2 receives these routes and checks that the DN bit in the LSAs carrying these routes is 0, ASBR2 adds the routes to its routing table.

  • A device does not check the DN bit after having received LSAs. For example, ASBR1 sets the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does not check the DN bit after having received these LSAs.

The preceding methods can be used more flexibly based on specific types of LSAs. For Type 3 LSAs, you can configure a sender to determine whether to set the DN bit to 1 or configure a receiver to determine whether to check the DN bit in the Type 3 LSAs based on the router ID of the device that generates the Type 3 LSAs.

In the inter-AS VPN Option A scenario shown in Figure 7-35, the four ASBRs are fully meshed and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the Type 3 LSAs, and routing loops will occur, as described in Figure 7-35. ASBR2 will deny the Type 5 or Type 7 LSAs, because the VPN route tags carried in the LSAs are the same as the default VPN route tag of the OSPF process on ASBR2.

To address the routing loop problem caused by Type 3 LSAs, configure ASBR2 not to check the DN bit in the Type 3 LSAs that are generated by devices with the router ID 1.1.1.1 and the router ID 3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by ASBR4 with the router ID 4.4.4.4, ASBR2 will check the DN bit and deny these Type 3 LSAs because the DN bit is set to 1.

Figure 7-35 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A scenario

Routing Loop Prevention

Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each other.

Figure 7-36 OSPF VPN routing loops

As shown in Figure 7-36, on PE1, OSPF imports a BGP route whose destination address is 10.1.1.1/32, and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1 respectively, and advertises the route to PE2. In this manner, PE2 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively.

Similarly, CE1 also learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE2 respectively. PE1 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively.

As a result, CE1 has two equal-cost routes with next hops being PE1 and PE2 respectively, and the next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1. Thus, a routing loop occurs.

In addition, the preference of an OSPF route is higher than that of a BGP route. Therefore, on PE1 and PE2, BGP routes to 10.1.1.1/32 are replaced by the OSPF route. That is, the OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively is active in the routing tables of PE1 and PE2.

The BGP route then becomes inactive, and thus the LSA generated when this route is imported by OSPF is deleted. This causes the OSPF route to be withdrawn. As a result, there is no OSPF route in the routing table, and the BGP route becomes active again. This cycle causes route flapping.

OSPF VPN provides a solution to this problem, as shown in Table 7-23.

Table 7-23 Routing loop prevention

Feature

Definition

Function

DN-bit

To prevent routing loops, an OSPF multi-instance process uses one bit as a flag bit, which is called the DN-bit.

When advertising the generated Type 3, Type 5, or Type 7 LSAs to CEs, PEs set the DN-bit of these LSAs to 1 and the DN-bit of other LSAs to 0.

When calculating routes, the OSPF multi-instance process of a PE ignores the LSAs with the DN-bit being 1. This avoids routing loops that occur when PEs learn the self-originated LSAs from CEs.

VPN Route Tag

The VPN route tag is carried in Type 5 or Type 7 LSAs generated by PEs according to the received BGP private route.

Not transmitted in BGP extended community attributes, the VPN route tag is valid only on the PEs that receive BGP routes and generate OSPF LSAs.

When a PE detects that the VPN route tag in the incoming LSA is the same as that in the local LSA, the PE ignores this LSA. Consequently, routing loops are avoided.

Default Route

A route with the destination address and mask being all 0s is a default route.

PEs do not calculate default routes.

Default routes are used to forward the traffic from CEs or the sites where CEs reside to the VPN backbone network.

Multi-VPN-Instance CE

OSPF multi-instance generally runs on PEs. The devices that run OSPF multi-instance within the LANs of users are called Multi-VPN-Instance CEs (MCEs), that is, multi-instance CEs.

Compared with OSPF multi-instance running on PEs, MCEs have the following characteristics:

  • MCEs do not need to support OSPF-BGP synchronization.

  • MCEs establish different OSPF instances for different services. Different virtual CEs transmit different services. This solves the security issue of the LAN at a low cost.

  • MCEs implement different OSPF multi-instances on a CE. The key to implementing MCEs is to disable loop detection and calculate routes directly. MCEs also need to use the received LSAs with the ND-bit for route calculation.

OSPF NSSA

Definition

As defined in OSPF, stub areas cannot import external routes. This prevents a large number of external routes from consuming bandwidth and storage resources of the Routers in stub areas. To import external routes and to prevent external routes from consuming resources, NSSAs are used, because stub areas cannot meet requirements.

NSSAs are a new type of OSPF areas.

There are many similarities between NSSAs and stub areas. The difference between NSSAs and stub areas is that NSSAs can import AS external routes into the entire OSPF AS and advertise the imported routes in the OSPF AS, but do not learn external routes from other areas on the OSPF network.

Figure 7-37 NSSA

N-bit

All Routers in an area must be configured with the same area type. In OSPF, the N-bit is carried in a Hello packet and is used to identify the area type supported by the Router. OSPF neighbor relationships cannot be established between Routers configured with different area types.

Some manufacturers do not comply with the standard and set the N-bit in both OSPF Hello and DD packets. To allow Huawei devices to interwork with these manufacturers' devices, set the N-bit in OSPF DD packets on Huawei devices.

Type 7 LSA
  • Type 7 LSAs are a new type of LSAs that can only be used in NSSAs and describe the imported external routes.
  • Type 7 LSAs are generated by ASBRs in an NSSA and flooded only in the NSSA where the ASBRs reside.
  • When the ABRs in the NSSA receive these Type 7 LSAs, they translate some of the Type 7 LSAs into Type 5 LSAs to advertise AS external routes to the other areas on the OSPF network.
Translating Type 7 LSAs Into Type 5 LSAs

To advertise the external routes imported by an NSSA to other areas, Type 7 LSAs need to be translated into Type 5 LSAs so that the external routes can be advertised on the entire OSPF network.

  • The Propagate bit (P-bit) in a Type 7 LSA is used to instruct the Router whether to translate Type 7 LSAs into Type 5 LSAs.
  • By default, the ABR with the largest router ID in an NSSA is responsible for translating Type 7 LSAs into Type 5 LSAs.
  • Only the Type 7 LSAs in which the P-bit is set to 1 and the FA is not 0 can be translated into Type 5 LSAs. The FA indicates that the packet to a specific destination address will be forwarded to the address specified by the FA.
  • The P-bit in the Type 7 LSAs generated by ABRs is not set to 1.
Preventing Loops Caused by Default Routes

There may be multiple ABRs in an NSSA. To prevent routing loops, these ABRs not to calculate default routes advertised by each other.

OSPF Fast Convergence

OSPF fast convergence is an extended feature of OSPF to speed up route convergence. The characteristics of OSPF fast convergence are as follows:

  • Priority-based OSPF Convergence
  • When certain routes on the network change, only the changed routes are recalculated. This is called Partial Route Calculation (PRC).
  • An intelligent timer is used to implement LSA management (the generating and receiving of LSAs). With the intelligent timer, infrequent changes are responded to quickly, whereas frequent changes are suppressed as desired.

    To avoid excessive consumption of device resources by network connections or due to frequent route flapping, RFC 2328 maintains that:

    • After an LSA is generated, it cannot be generated again in five seconds. That is, the interval for updating LSAs is one second.
    • The interval for receiving LSAs is one second.

    On a stable network where routes need to be fast converged, you can use the intelligent timer to set the interval for receiving LSAs to 0 seconds. This ensures that topology or route changes can be advertised to the network or be immediately sensed, thus speeding up route convergence on the network.

  • Route calculation is controlled through the intelligent timer.

    When the network topology changes, devices need to recalculate routes according to OSPF. This means that frequent changes in the network topology affect the performance of devices. To address issue, RFC 2328 requires the use of a delay timer in route calculation so that route calculation is performed only after the specified delay. But the delay suggested by RFC is a fixed value, and cannot ensure both fast response to topology changes and effective suppression of flapping.

    By means of the intelligent timer, the delay in route calculation can be flexibly set as desired. As a result, infrequent changes are responded to quickly, whereas frequent changes are suppressed as desired.

  • OSPF Smart-discover

Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first when a great number of routes need to converge. Different routes can be set with different convergence priorities. This allows important routes to converge first and therefore improves network reliability.

By using priority-based OSPF convergence, you can assign a higher convergence priority to routes for key services so that those routes can converge fast. By so doing, the impact on key services is reduced.

OSPF-BGP Association

Definition

When a new device is deployed in the network or a device is restarted, network traffic may be lost during BGP convergence. This is because IGP convergence is faster than BGP convergence.

This problem can be solved through the synchronization between OSPF and BGP.

Purpose

If a backup link exists, during traffic switchback, BGP traffic is lost because BGP route convergence is slower than OSPF route convergence.

As shown in Figure 7-38, RouterA, RouterB, RouterC, and RouterD run OSPF and establish IBGP connections. RouterC functions as the backup of RouterB. When the network is stable, BGP and OSPF routes converge completely on the device.

Normally, traffic from RouterA to 10.3.1.0/30 passes through RouterB. When RouterB becomes faulty, traffic is switched to RouterC. After RouterB recovers, traffic is switched back to RouterB. During this process, packet loss occurs.

This is because when traffic is switched back to RouterB, IGP route convergence is faster than BGP route convergence. Consequently, convergence of OSPF routes is already complete when BGP route convergence is still going on. As a result, RouterB does not know the route to 10.3.1.0/30.

Therefore, when packets from RouterA to 10.3.1.0/30 arrive at RouterB, they are discarded because RouterB does not have the route to 10.3.1.0/30.

Figure 7-38 OSPF-BGP synchronization

Principle

The device enabled with OSPF-BGP synchronization remains as a stub router within the set synchronization period. That is, the link metric in the LSA advertised by the device is the maximum value 65535. Therefore, the device instructs other OSPF devices not to use it for data forwarding.

As shown in Figure 7-38, OSPF-BGP synchronization is enabled on RouterB. In this situation, before BGP route convergence is complete, RouterA continues to use the backup link RouterC rather than forward traffic to RouterB until BGP route convergence on RouterB is complete.

OSPF GR

Routers generally operate with separation of the control plane and forwarding plane. When the network topology remains stable, a restart of the control plane does not affect the forwarding plane, and the forwarding plane can still forward data properly. This separation ensures non-stop service forwarding.

In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding after a restart occurs. The actions on the control plane, such as re-establishment of neighbor relationships and route calculation, do not affect the forwarding plane. Network reliability is improved because service interruption caused by route flapping is prevented.

Basic Concepts of OSPF GR

Graceful Restart (GR) is a technology used to ensure normal traffic forwarding and non-stop forwarding of key services during the restart of routing protocols.

Unless otherwise stated, GR described in this section refers to the GR technology defined in RFC 3623.

GR is one of the high availability (HA) technologies, which comprise a set of comprehensive technologies, such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-tolerant redundancy technology, GR is widely used to ensure non-stop forwarding of key services during master/slave switchover and system upgrade.

The following concepts are involved in GR:

  • Grace-LSA

    OSPF supports GR by flooding Grace-LSAs. Grace-LSAs are used to inform the neighbor of the GR time, cause, and interface address when the GR starts and ends.

  • Role of a router during GR

    • Restarter: is the router that restarts. The Restarter can be configured to support totally GR or partly GR.

    • Helper: is the router that helps the Restarter. The Helper can be configured to support planned GR or unplanned GR or to selectively support GR through the configured policies.

  • Conditions that cause GR

    • Unknown: indicates that GR is triggered for an unknown reason.

    • Software restart: indicates that GR is triggered by commands.

    • Software reload/upgrade: indicates that GR is triggered by software restart or upgrade.

    • Switch to redundant control processor: indicates that GR is triggered by the abnormal master/slave switchover.

  • GR period

    The GR period cannot exceed 1800 seconds. OSPF routers can exit from GR regardless of whether GR succeeds or fails, without waiting for GR to expire.

Classification of OSPF GR
  • Totally GR: indicates that when a neighbor of a router does not support GR, the router exits from GR.

  • Partly GR: indicates that when a neighbor does not support GR, only the interface associated with this neighbor exits from GR, whereas the other interfaces perform GR normally.

  • Planned GR: indicates that a router restarts or performs the master/slave switchover using a command. The Restarter sends a Grace-LSA before restart or master/slave switchover.

  • Unplanned GR: indicates that a router restarts or performs the master/slave switchover because of faults. A router performs the master/slave switchover, without sending a Grace-LSA, and then enters GR after the slave board goes Up. The process of unplanned GR is the same as that of planned GR.

GR Process
  • A router starts GR.

    In planned GR mode, after master/slave switchover is triggered through a command, the Restarter sends a Grace-LSA to all neighbors to notify them of the start, period, and cause of GR, and then performs the master/slave switchover.

    In unplanned GR, the Restarter does not send the Grace-LSA.

    In unplanned GR mode, the Restarter sends a Grace-LSA immediately after the slave board goes Up, informing neighbors of the start, period, and cause of GR. The Restarter then sends a Grace-LSA to each neighbor five times consecutively. This ensures that neighbors receive the Grace-LSA. This operation is proposed by manufacturers but not defined by the OSPF protocol.

    The Restarter sends a Grace-LSA to notify neighbors that it enters GR. During GR, neighbors keep neighbor relationships with the Restarter so that other routers cannot detect the switchover of the Restarter.

  • The GR process runs, as shown in Figure 7-39.

    Figure 7-39 OSPF GR process

  • The router exits from GR.

    Table 7-24 Reasons that a router exits GR

    Execution of GR

    Restarter

    Helper

    GR succeeds.

    Before GR expires, the Restarter re-establishes neighbor relationships with all neighbors before master/slave switchover.

    After the Helper receives the Grace-LSA with the Age being 3600s from the Restarter, the neighbor relationship between the Helper and Restarter enters the Full state.

    GR fails.

    • GR expires, and neighbor relationships do not recover completely.

    • Router-LSA or Network-LSA sent by the Helper causes Restarter to fail to perform bidirectional check.

    • Status of the interface that functions as the Restarter changes.

    • Restarter receives the one-way Hello packet from the Helper.

    • The Restarter receives the Grace-LSA that is generated by another router on the same network segment. Only one router can perform GR on the same network segment.

    • On the same network segment, neighbors of the Restarter have different DRs or BDRs because of the topology changes.

    • Helper does not receive the Grace-LSA from Restarter before the neighbor relationship expires.

    • Status of the interface that functions as the Helper changes.

    • Helper receives the LSA that is inconsistent with the LSA in the local LSDB from another router. This situation can be excluded after the Helper is configured not to perform strict LSA check.

    • Helper receives Grace-LSAs from two routers on the same network segment at the same time.

    • Neighbor relationships between Helper and other neighbors change.

Comparison Between GR Mode and Non-GR Mode
Table 7-25 Comparison of master/slave switchover in the GR mode and non-GR mode

Switchover in Non-GR Mode

Switchover in GR Mode

  • OSPF neighbor relationships are re-established.

  • Routes are recalculated.

  • Forwarding table changes.

  • Entire network detects route changes, and route flapping occurs for a short period of time.

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

  • OSPF neighbor relationships are re-established.

  • Routes are recalculated.

  • Forwarding table remains unchanged.

  • Except for neighbors of the device where master/slave switchover occurs, other routers do not detect route changes.

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

OSPF-LDP Association

Definition

In the networking that uses primary and backup links, when the faulty primary link recovers, traffic is switched from the backup link back to the primary link.

IGP route convergence completes before an LDP session is established. Consequently, the old LSP is deleted before the new LSP is established and LSP traffic is interrupted.

Purpose

As shown in Figure 7-40, the primary link adopts the path PE1→P1→P2→P3→PE2, and the backup link adopts the path PE1→P1→P4→P3→PE2.

When the primary link is faulty, traffic is switched to the backup link. After the primary link recovers, traffic is switched back to the primary link. During this process, traffic is interrupted for a long period of time.

Figure 7-40 OSPF-LDP association

Synchronizing Label Distribution Protocol(LDP) and IGP on P1 and P2 can shorten traffic interruption caused by traffic switchover from the backup link to the primary link.

Table 7-26 OSPF-LDP association
Enabling Status of OSPF-LDP Association Traffic Interruption Time
Not enabled. Seconds level
Enabled. Milliseconds level
Principle

The principle of LDP-IGP synchronization is to delay route switchback by suppressing the establishment of IGP neighbor relationships until LDP convergence is complete. That is, before an LSP on the primary link is established, the backup link continues to forward traffic. Then the link is deleted after the LSP is established.

Synchronization of LDP and IGP involves three timers:

  • Hold-down

  • Hold-max-cost

  • Delay

After the primary link recovers, a router responds as follows:

  1. Starts the hold-down timer. The IGP interface does not establish IGP neighbors but waits for establishment of an LDP session. The Hold-down timer specifies the period that the IGP interface waits.

  2. Starts the hold-max-cost timer after the hold-down timer expires. The hold-max-cost timer specifies the interval for advertising the maximum link metric of the interface in the Link State Advertisement (LSA) to the primary link.

  3. Starts the Delay timer to allow time for establishment of an LSP after an LDP session is re-established for the faulty link.

  4. After the Delay timer expires, LDP notifies IGP that synchronization is complete regardless of the status of IGP.

OSPF Database Overflow

Definition

OSPF requires that routers in the same area have the same Link-State Database (LSDB).

With the continuous increase in routes on the network, some routers fail to carry the additional routing information because of limited system resources. This situation is called OSPF database overflow.

Purpose

You can configure stub areas or NSSAs to solve the problem of the continuous increase in routing information that causes the exhaustion of system resources of routers. However, configuring stub areas or NSSAs cannot solve the problem when the unexpected increase in dynamic routes causes database overflow. Setting the maximum number of external LSAs in the LSDB can dynamically limit the LSDB capacity, to avoid the problems caused by database overflow.

Principle

To prevent database overflow, you can set the maximum number of non-default external routes on a router.

All routers on the OSPF network must be set with the same upper limit. If the number of external routes on a router reaches the upper limit, the router enters the Overflow state and starts an overflow timer. The router automatically exits from the overflow state after the timer expires, By default, it is 5 seconds.

Table 7-27 OSPF database overflow

Overflow Phase

OSPF Processing

Entering overflow state

A router deletes all non-default external routes that is generated.

Staying in overflow state

  • Router does not generate non-default external routes.
  • Router discards the newly received, non-default external routes, and does not reply with an LSAck packet.
  • When the overflow timer expires, the router checks whether the number of external routes still exceeds the upper limit.
    • If so, the router restarts the timer.
    • If not, the router exits from overflow state.

Exiting from the overflow state

  • Router deletes the overflow timer.
  • Router generates non-default routes.
  • Router learns the newly received non-default routes, and replies with an LSAck packet.
  • Router prepares to enter Overflow state for the next time it occurs.

OSPF Mesh-Group

Definition

In the scenario where there are multiple concurrent links, you can deploy OSPF mesh-group to classify links into a mesh group. Then, OSPF floods LSAs to only a link selected from the mesh group. Using OSPF mesh-group prevents unnecessary burden on the system caused by repetitive flooding.

The mesh-group feature is disabled by default.

Purpose

After receiving or generating an LSA, an OSPF process floods the LSA. When there are multiple concurrent links, OSPF floods the LSA to each link and sends Update messages.

In this scenario, if there are 2000 concurrent links, OSPF floods each LSA 2000 times. Only one flooding, however, is valid. The other 1999 times are useless repetition.

To prevent burden on the system caused by repetitive flooding, you can enable mesh-group to classify multiple concurrent links between a router and its neighbor into a group and then select a primary link to use for flooding.

Principles

As shown in Figure 7-41, RouterA and RouterB, which are connected through three links, establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, RouterA floods the LSA to RouterB through interfaces 1, 2, and 3.

This flooding causes a heavy load on the concurrent links. For the neighbor with concurrent links, only a primary link is selected to flood the LSA.

Figure 7-41 LSA flooding with OSPF mesh-group disabled

When multiple concurrent links exist between a device enabled with OSPF mesh-group and its neighbor, the device selects to flood the received LSAs, as shown in Figure 7-42.

Figure 7-42 LSA flooding with OSPF mesh-group enabled

As defined in OSPF, LSAs can be flooded to a link only when the neighbor status is not lower than Exchange. In this case, when the status of the interface on the primary link is lower than Exchange, OSPF reselects a primary link from the concurrent links and then floods the LSA. After receiving the LSA flooded by RouterA from link 1, RouterB no longer floods the LSA to RouterA through interfaces 2 and 3.

As defined by the mesh-group feature, the Router ID of a neighbor uniquely identifies the mesh group. Interfaces connected to the same neighbor that have a status greater than Exchange belong to the same mesh group.

In Figure 7-43, a mesh group of RouterA resides in Area 0, which contains the links of interface 1 and interface 2. More than one neighbor of interface 3 resides on the broadcast link. Therefore, interface 3 cannot be defined as part of the mesh group.

Figure 7-43 Interface not added to mesh group

NOTE:

After a router is enabled with mesh-group, if the Router IDs of the router and its directly connected neighbor are the same, LSDBs cannot be synchronized and routes cannot be calculated correctly. In this case, you need to reconfigure the Router ID of the neighbor.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 57502

Downloads: 3619

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