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

Configuration Guide - IP Unicast Routing

S7700 and S9700 V200R011C10

This document describes IP Unicast Routing configurations supported by the switch, including the principle and configuration procedures of IP Routing Overview, Static Route, RIP, RIPng, OSPF, OSPFv3, IS-IS(IPv4), IS-IS(IPv6), BGP, Routing Policy ,and PBR, and provides configuration examples.
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).
Enhanced OSPF Functions

Enhanced OSPF Functions

OSPF VPN

Definition

OSPF VPN enables Provider Edges (PEs) and Customer Edges (CEs) within VPNs to run OSPF. This is useful for interworking and allows OSPF to learn and advertise VPN routes.

Purpose

OSPF is a widely used IGP and, in most cases can run within a VPN. When OSPF runs between PEs and CEs, and PEs are advertising VPN routes using OSPF, CEs do not need to support other routing protocols for interworking. 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 routing information is learned and advertised between PEs and CEs using OSPF.

Running OSPF between PEs and CEs has many benefits:

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

  • Running OSPF both in a site and between PEs and CEs simplifies the workload of network administrators. Network administrators do not require familiarity with multiple protocols.

  • Running OSPF facilitates the transition from a non-VPN backbone network to a BGP/MPLS VPN network.

As shown in Figure 5-37, CE1, CE3, and CE4 belong to VPN1. The numbers following OSPF refer to the process IDs of multiple OSPF instances running on PEs.

Figure 5-37  Running OSPF between PEs and CEs

To advertise routes of CE1 to CE3 and CE4:

  1. PE1 imports OSPF routes of CE1 into BGP and generates 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.

Configuring OSPF Areas Between PEs and CEs

OSPF areas between PEs and CEs can be either non-backbone 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 to which CEs connect must be connected to the backbone area of this VPN site through Area 0. This link can be either a physical or a virtual link that implements a logical connection between the PEs and the backbone area, as shown in Figure 5-38.

Figure 5-38  Configuring OSPF areas between PEs and CEs

In Figure 5-38, a non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is configured in Site 1. This separates the backbone area in Site 1 from the VPN backbone area. 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.

Important characteristics of OSPF domain IDs include:

  • Domain IDs identify and differentiate different domains.

  • Each OSPF domain has one or more domain IDs. One domain ID must be a primary ID, while the others are secondary IDs.

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

Before a PE advertises the BGP routes learned from a remote PE to CEs, the PE checks the domain IDs carried in the BGP routes to determine the type of OSPF routes (Type 3, Type 5, or Type 7) to be advertised.

If local domain IDs are the same as or compatible with the remote domain IDs carried in the BGP routes, the PE advertises Type 3 routes. Otherwise, the PE advertises Type 5 or Type 7 routes.

Table 5-8  Domain ID

Comparison Between Local and Remote Domain IDs

Route Type

Both the local and remote domain IDs are null.

Inter-area route

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

Inter-area route

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

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

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

Routing Loop Prevention

Routing loops may occur between PEs and CEs when OSPF and BGP learn routes from each other.

Figure 5-39  OSPF VPN routing loops

As shown in Figure 5-39, a routing loop occurs in the following process:
  1. PE1 uses OSPF to import a BGP route whose destination address is 10.1.1.1/32.
  2. OSPF then generates and advertises a Type 5 or Type 7 LSA to CE1.
  3. CE1 learns an OSPF route with the destination address 10.1.1.1/32 and next hop of PE1 and advertises the route to PE2.
  4. PE2 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1.
  5. CE1 also learns an OSPF route with the destination address 10.1.1.1/32 and next hop of PE2. PE1 learns an OSPF route with the destination address 10.1.1.1/32 and next hop of CE1.
  6. CE1 has learned two equal-cost routes, with the next hop of one being PE1 and the other being PE2. The next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1.

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

The BGP route then becomes inactive, causing LSAs generated when this route is imported by OSPF to be deleted. As a result, the OSPF route is withdrawn. 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.

Table 5-9  Routing loop prevention

Feature

Definition

Function

DN bit

The DN bit is a 1-bit flag used by an OSPF multi-instance process to prevent routing loops.

When a PE advertises generated Type 3, Type 5, or Type 7 LSAs to CEs, it sets the DN bit of these LSAs to 1 and sets the DN bit of other LSAs to 0.

When calculating routes, the OSPF multi-instance process of the PE ignores LSAs with the DN bit 1. This prevents routing loops when the PE learns 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 received BGP private routes.

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

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. This prevents routing loops.

Default route

A default route is a route with an all-zero destination address and subnet mask.

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

PEs do not calculate default routes.

Disabling Routing Loop Prevention

Exercise caution when disabling routing loop prevention as it increases the likelihood of routing loops.

After routing loop prevention is enabled, OSPF routing loops will not occur in VPN sites during BGP or OSPF route exchanges.

In an inter-AS VPN Option A scenario, if OSPF runs 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.

Figure 5-40 shows a network with inter-AS VPN Option A deployed. OSPF runs between PE1 and CE1. CE1 sends VPN routes to CE2.

Figure 5-40  Inter-AS VPN Option A

In Figure 5-40:

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

  2. ASBR1 receives the MP-BGP routes, imports the routes into the OSPF process within a VPN instance, and then generates Type 3, Type 5, or Type 7 LSAs with DN bit set to 1.

  3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. ASBR2 learns that the DN bit of each LSA is 1 and does not add routing information carried in these LSAs to its routing table due to the routing loop prevention mechanism.

Because ASBR2 cannot learn OSPF routes sent from ASBR1, CE1 cannot communicate with CE3.

The following methods allow for communication between CE1 and CE3:

  • Devices do not set the DN bit to 1 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 receiving these routes, ASBR2 learns that the DN bit in the LSAs carrying these routes is 0 and then adds the routes to its routing table.

  • Devices do not check the DN bit after receiving LSAs. For example, ASBR1 sets the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2 does not check the DN bit after receiving these LSAs.

The preceding methods can be used more flexibly based on specific types of LSAs. For Type 3 LSAs, configure a sender to determine whether to set the DN bit to 1. Alternatively, 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 LSAs.

In an inter-AS VPN Option A scenario shown in Figure 5-41, 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. 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 loops caused by Type 3 LSAs, configure ASBR2 not to check the DN bit in the Type 3 LSAs that are generated by devices with router ID 10.1.1.1 and router ID 10.3.3.3. When configured successfully, if ASBR2 receives Type 3 LSAs sent by ASBR4 with the router ID 10.4.4.4, ASBR2 will check the DN bit in the LSAs and ignore these LSAs because the DN bit is set to 1.

Figure 5-41  Full-mesh ASBRs in an inter-AS VPN Option A scenario

Multi-VPN-Instance CE

OSPF multi-instance generally runs on PEs. Multi-VPN-Instance CEs (MCEs) are devices that run OSPF multi-instance within user LANs.

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

  • OSPF-BGP synchronization support is not required.

  • Different OSPF instances are created for different services. That is, different virtual CEs transmit different services. This is a low-cost solution for LAN security issues.

  • Different OSPF multi-instances are implemented on a CE. Implementing MCEs requires disabling of loop detection and direct route calculation. That is, MCEs also use the received LSAs with the DN bit set to 1 for route calculation.

OSPF TE

Traffic engineering (TE) requires knowledge of network topology and network constraints, including bandwidth, traffic engineering metrics, administrative groups, and affinity attributes. By itself, OSPF cannot meet these requirements and needs to be extended by introducing a new type of LSA to advertise network constraints. The Constrained Shortest Path First (CSPF) algorithm can calculate the path that satisfies defined constraints.

OSPF TE supports MPLS TE in the establishment and maintenance of the Label Switch Path (LSP). OSPF advertises information and is responsible for collecting and advertising MPLS TE information.

Figure 5-42  OSPF functions in MPLS TE architecture

OSPF Functions in MPLS TE Architecture

In MPLS TE architecture, OSPF advertises information by collecting and then flooding traffic engineering information to devices in the same area.

Collected information forms the traffic engineering database (TEDB) and is utilized by the CSPF to calculate routes.

OSPF does not consider what the specific information is or how MPLS uses the information.

TE-LSA
OSPF uses Type 10 Opaque LSAs to collect and advertise traffic engineering information. Type 10 LSAs contain link status information required by traffic engineering, including:
  • Maximum link bandwidth
  • Maximum reservable bandwidth
  • Current reserved bandwidth
  • Link color

Type 10 Opaque LSAs use OSPF flooding to synchronize link status information among devices in an area. This forms a uniform TEDB for route calculation.

Interaction Between OSPF TE and CSPF

OSPF collects traffic engineering information in an area by using Type 10 LSAs that include bandwidth, priority, and link metric. OSPF then processes and provides the information for CSPF to calculate routes.

IGP Shortcut and Forwarding Adjacency

OSPF supports IGP shortcuts and forwarding adjacencies. These two features enable a tunnel interface to be used as an outbound interface to reach a destination.

Devices with IGP shortcuts enabled use a tunnel interface as an outbound interface without advertising the tunnel interface link to neighbors. This prevents other devices from using this tunnel. IGP shortcuts are unidirectional and need to be configured only on devices that use IGP shortcuts.

Devices with forwarding adjacencies enabled use a tunnel interface as an outbound interface while advertising the tunnel interface to neighbors. This allows other devices to use this tunnel.

OSPF DS-TE

DiffServ Aware Traffic Engineering (DS-TE) controls and forwards data differently based on Class of Service (CoS). DS-TE combines the advantages of MPLS TE and Differentiated Services (DiffServ) while precisely controlling data paths. DS-TE allows for efficient use of network resources while reserving required resources for different services.

To support DE-TE in MPLS, OSPF TE-LSAs contain local overbooking multiplier TLVs and bandwidth constraint (BC) TLVs. These TLVs are used to advertise and collect the reservable bandwidths of class types (CTs) with different priorities on the link. A class type refers to the collected bandwidth of an LSP or a group of LSPs sharing the same CoS.

OSPF SRLG

OSPF supports Shared Risk Link Group (SRLG) applications in MPLS. This is achieved by obtaining information about the SRLG that floods traffic engineering information to devices in an area.

OSPF Local MT

Definition and Purpose

When multicast and an MPLS TE tunnel are deployed, multicast services may become unavailable due to TE tunnel deployment.

To solve this problem, you can enable local multicast-topology (MT) for multicast packet forwarding.

Local MT

After IGP Shortcut is configured on a TE tunnel, the outbound interface of the route calculated by an IGP may not be the actual physical interface but a TE tunnel interface.

If a router sends a Join message through a TE tunnel interface, routers spanned by the TE tunnel cannot detect the Join message, so they do not create any multicast forwarding entries.

In Figure 5-43, RouterB that is spanned by the TE tunnel does not create any multicast forwarding entries.

Figure 5-43  OSPF Local MT

A TE tunnel is unidirectional, so multicast data packets sent by the multicast source are sent to the routers spanned by the tunnel through physical interfaces. Services become unavailable as these routers discard the multicast data packets due to a lack of multicast forwarding entries.

After local MT is enabled, if the outbound interface of the calculated route is an IGP Shortcut TE tunnel interface, the route management (RM) module creates a separate Multicast IGP (MIGP) routing table for the multicast protocol, calculates the actual physical outbound interface for the route, and then adds the route to the MIGP routing table. Multicast then uses routes in the MIGP routing table to forward packets.

In Figure 5-43, the packets requesting to join a multicast group is sent from RouterA to RouterB through GE 1/1/0. RouterB then can create a multicast forwarding table correctly.

OSPF Security

OSPF GTSM

The Generalized TTL Security Mechanism (GTSM) protects services over the IP layer against attacks by checking whether the time to live (TTL) value in an IP packet header is within a predefined range. An attacker may simulate real OSPF unicast packets and continuously send the packets to a router. When the router finds that these packets are destined for itself, it directly sends the packets to the control plane for processing without checking the validity of these packets. As a result, the switch will remain busy processing these packets, resulting in a high CPU usage.

The Generalized TTL Security Mechanism (GTSM) protects a device's TCP/IP-based control plane from certain attacks that consume CPU resources.

Devices with GTSM enabled check the TTL values in all received packets according to configured policies. An action is then performed on packets that do not match the criteria specified in the policies (for example, the packets may be discarded).

A GTSM policy includes:

  • Source address of the IP packet sent to the device

  • VPN instance to which the packet belongs

  • Protocol number of the IP packet (89 for OSPF, and 6 for BGP)

  • Source interface number and destination interface number of protocols above TCP/UDP

  • Valid TTL range

GTSM can be implemented for different connections:

  • For directly connected neighbors, the TTL value of unicast protocol packets is set to 255.

  • For multi-hop neighbors, an appropriate TTL range is defined.

The applicability of GTSM is as follows:

  • GTSM is applicable to unicast packets instead of multicast packets. The TTL value of multicast packets cannot exceed 255; therefore, GTSM is not required for multicast packets.

  • GTSM does not apply to devices that use a tunnel to communicate with each other.

OSPF Packet Authentication

OSPF packets must be authenticated before a neighbor relationship can be established.

Routers support two authentication methods: area-based authentication and interface-based authentication.

If both authentication methods are configured, interface-based authentication is used.

OSPF GR

The control plane and forwarding plane are generally separated on switches. When the network topology remains stable, a restart of the control plane does not affect the forwarding plane, which means that the forwarding plane can continue to forward data. 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), also called non-stop forwarding (NSF), is used to ensure normal traffic forwarding and key services forwarding during a routing protocol restart.

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

GR is a fault-tolerant redundancy technology, one of a group of high availability (HA) technologies that include link protection, faulty node recovery, and traffic engineering, used to ensure non-stop forwarding of key services during active/standby switchovers and system upgrades.

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 switch during GR

    • Restarter: the switch that restarts. The Restarter can be configured to support full GR or partial GR.

    • Helper: the switch that helps the Restarter. Configured policies of the Helper can be set to:

      • Selectively support GR.
      • Support planned GR.
      • Support unplanned GR.
  • Conditions that cause GR

    • Unknown: indicates that GR is triggered by unknown events.

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

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

    • Switch to redundant control processor: indicates that GR is triggered by an abnormal active/standby switchover.

  • GR period

    The GR period cannot exceed 1800 seconds. OSPF switches can exit from GR regardless of successful or failed GR, without waiting for GR to expire.

Classification of OSPF GR
  • Full GR: When a neighbor of a switch does not support GR, the switch exits from GR.

  • Partial GR: 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: A switch is restarted or performs an active/standby switchover using a command. The Restarter sends a Grace-LSA before the restart or active/standby switchover.

  • Unplanned GR: A switch performs an active/standby 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

Figure 5-44 shows an OSPF GR process.

Figure 5-44  OSPF GR process
An OSPF GR process includes the following procedures:
  1. The restarter (SwitchA) enters the GR state.

    1. The restarter performs a master/slave main control board switchover.

      NOTE:
      In planned GR mode, the restarter sends a grace LSA to each neighbor to notify them of the GR start, period, and cause before performing a master/slave main control board switchover. In unplanned GR mode, the restarter does not send grace LSAs.
    2. Before the restarter enters the GR state, it sends a grace LSA to maintain OSPF neighbor relationships.
    3. When the slave main control board goes Up, the restarter immediately sends a grace LSA to notify the helper (SwitchB) of the GR start, period, and cause. Then, the restarter sends five consecutive grace LSAs to the helper to ensure that the helper can receive a grace LSA.

      NOTE:
      Sending five consecutive grace LSAs is proposed by vendors and has not been defined by OSPF.

    During the GR, the helper retains a neighbor relationship with the restarter. Other switches do not detect the master/slave main control board switchover performed by the restarter.

  2. The restarter stays in the GR state.

    1. The restarter and helper establish an OSPF adjacency.
    2. The helper checks the restarter status. If the restarter status is Down, the helper considers that the restarter can restore services within a specified GR period. Before the specified GR period expires, the helper does not terminate sessions or delete the topology or routing information obtained from the restarter.
    3. When the restarter recovers, it sends a packet to the helper. After the restarter receives a response, it reestablishes a neighbor relationship with the helper.
    4. The restarter establishes a session with the helper to obtain topology or routing information and uses the information to calculate its own routing table.

    A master/slave main control board switchover or restarter restart can be manually performed or automatically triggered by faults. During the master/slave main control board switchover or restarter restart, the restarter does not delete the routing information from its routing table or FIB or reset its interface boards. This process ensures service continuity.

  3. The restarter leaves the GR state.

    • If the GR is successful, the restarter reestablishes a neighbor relationship with the helper before the GR period expires. After the helper receives a grace LSA with an aging time of 3600 seconds from the restarter, the status of the neighbor relationship between the helper and restarter changes to Full.

    • If the GR fails, several cases occur on the restarter and helper.

      The following conditions occur on the restarter:
      • The GR expires, and the neighbor relationship does not recover completely.

      • Type 1 or Type 2 LSAs sent by the helper cause the restarter to fail to perform a bidirectional check.

      • The status of the interface that functions as the restarter changes.

      • The restarter receives 1-way Hello packets from the helper.

      • The restarter receives grace LSAs generated by another switch on the same network segment.

        NOTE:
        Only one switch can perform a GR on the same network segment at the same time.
      • Different designated switches (DRs) or backup designated switches (BDRs) are elected among the restarter and neighbors on the same network segment due to topology changes.

      The following conditions occur on the helper:

      • The helper does not receive grace LSAs from the restarter before the neighbor relationship expires.

      • The status of the interface that functions as the helper changes.

      • The helper receives LSAs, which are different from the LSAs in its own link state database (LSDB), from other switches. You can configure the helper not to perform a strict LSA check to avoid this issue.

      • The helper receives grace LSAs from two switches on the same network segment at the same time.

      • The neighbor relationships between the helper and other switches change.

Comparison Between GR Mode and Non-GR Mode
Table 5-10  Comparison of an active/standby 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.

  • The forwarding table remains unchanged.

  • Except for neighbors of the device on which an active/standby switchover occurs, other switches do not detect route changes.

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

OSPF Neighbor Relationship Flapping Suppression

OSPF neighbor relationship flapping suppression works by delaying OSPF neighbor relationship reestablishment or setting the link cost to the maximum value.

Background

If the status of an interface carrying OSPF services alternates between Up and Down, OSPF neighbor relationship flapping occurs on the interface. During the flapping, OSPF frequently sends Hello packets to reestablish the neighbor relationship, synchronizes LSDBs, and recalculates routes. In this process, a large number of packets are exchanged, adversely affecting neighbor relationship stability, OSPF services, and other OSPF-dependent services, such as LDP and BGP. OSPF neighbor relationship flapping suppression can address this problem by delaying OSPF neighbor relationship reestablishment or preventing service traffic from passing through flapping links.

Related Concepts

Flapping_event: reported when the status of a neighbor relationship on an interface last changes from Full to a non-Full state. The flapping_event triggers flapping detection.

Flapping_count: number of times flapping has occurred.

Detect-interval: interval at which flapping is detected. The interval is used to determine whether to trigger a valid flapping_event.

Threshold: flapping suppression threshold. When the flapping_count reaches or exceeds threshold, flapping suppression takes effect.

Resume-interval: interval used to determine whether flapping suppression exits. If the interval between two valid flapping_events is longer than the resume-interval, flapping suppression exits.

Implementation
Flapping detection

OSPF interfaces start a flapping counter. If the interval between two flapping_events is shorter than the detect-interval, a valid flapping_event is recorded, and the flapping_count increases by 1. When the flapping_count exceeds the threshold, the system determines that flapping occurs, and therefore triggers flapping suppression, and sets the flapping_count to 0. If the interval between two valid flapping_events is longer than the resume-interval before the flapping_count reaches the threshold again, the system sets the flapping_count to 0 again. Interfaces start the suppression timer when the status of a neighbor relationship last changes to ExStart or Down.

The detect-interval, threshold, and resume-interval are configurable.

Flapping suppression

Flapping suppression works in either Hold-down or Hold-max-cost mode.

  • Hold-down mode: In the case of frequent flooding and topology changes during neighbor relationship establishment, interfaces prevent neighbor relationships from being reestablished during the suppression period, which minimizes LSDB synchronization attempts and packet exchanges.
  • Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use 65535 as the cost of the flapping link during the suppression period, which prevents traffic from passing through the flapping link.

Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost mode.

By default, the Hold-max-cost mode takes effect. The mode and suppression period can be changed manually.

NOTE:
When an interface enters the flapping suppression state, all neighbor relationships on the interface enter the state accordingly.
Exiting from flapping suppression

Interfaces exit from flapping suppression in the following scenarios:

  • The suppression timer expires.
  • The corresponding OSPF process is reset.
  • A command is run to exit from flapping suppression.
Typical Scenarios
Basic scenario

In Figure 5-45, the traffic forwarding path is Switch A -> Switch B -> Switch C -> Switch E before a link failure occurs. After the link between Switch B and Switch C fails, the forwarding path switches to Switch A -> Switch B -> Switch D -> Switch E. If the neighbor relationship between Switch B and Switch C frequently flaps at the early stage of the path switchover, the forwarding path will be switched frequently, causing traffic loss and affecting network stability. If the neighbor relationship flapping meets suppression conditions, flapping suppression takes effect.

  • If flapping suppression works in Hold-down mode, the neighbor relationship between Switch B and Switch C is prevented from being reestablished during the suppression period, in which traffic is forwarded along the path Switch A -> Switch B -> Switch D -> Switch E.
  • If flapping suppression works in Hold-max-cost mode, 65535 is used as the cost of the link between Switch B and Switch C during the suppression period, and traffic is forwarded along the path Switch A -> Switch B -> Switch D -> Switch E.
Figure 5-45  Flapping suppression in a basic scenario
Single-forwarding path scenario

When only one forwarding path exists on the network, the flapping of the neighbor relationship between any two devices on the path will interrupt traffic forwarding. In Figure 5-46, the traffic forwarding path is Switch A -> Switch B -> Switch C -> Switch E. If the neighbor relationship between Switch B and Switch C flaps, and the flapping meets suppression conditions, flapping suppression takes effect. However, if the neighbor relationship between Switch B and Switch C is prevented from being reestablished, the whole network will be divided. Therefore, Hold-max-cost mode (rather than Hold-down mode) is recommended. If flapping suppression works in Hold-max-cost mode, 65535 is used as the cost of the link between Switch B and Switch C during the suppression period. After the network stabilizes and the suppression timer expires, the link is restored.

NOTE:

By default, the Hold-max-cost mode takes effect.

Figure 5-46  Flapping suppression in a single-forwarding path scenario
Broadcast scenario

In Figure 5-47, four devices are deployed on the same broadcast network using switches, and the devices are broadcast network neighbors. If Switch C flaps due to a link failure, and Switch A and Switch B were deployed at different time (Switch A was deployed earlier for example) or the flapping suppression parameters on Switch A and Switch B are different, Switch A first detects the flapping and suppresses Switch C. Consequently, the Hello packets sent by Switch A do not carry Switch C's Switch ID. However, Switch B has not detected the flapping yet and still considers Switch C a valid node. As a result, the DR candidates identified by Switch A are Switch B and Switch D, whereas the DR candidates identified by Switch B are Switch A, Switch C, and Switch D. Different DR candidates result in a different DR election result, which may lead to route calculation errors. To prevent this problem in scenarios where an interface has multiple neighbors, such as on a broadcast, P2MP, or NBMA network, all neighbors on the interface are suppressed when the status of a neighbor relationship last changes to ExStart or Down. Specifically, if Switch C flaps, Switch A, Switch B, and Switch D on the broadcast network are all suppressed. After the network stabilizes and the suppression timer expires, Switch A, Switch B, and Switch D are restored to normal status.

Figure 5-47  Flapping suppression on a broadcast network
Multi-area scenario

In Figure 5-48, Switch A, Switch B, Switch C, Switch E, and Switch F are connected in area 1, and Switch B, Switch D, and Switch E are connected in backbone area 0. Traffic from Switch A to Switch F is preferentially forwarded along an intra-area route, and the forwarding path is Switch A -> Switch B -> Switch C -> Switch E -> Switch F. When the neighbor relationship between Switch B and Switch C flaps and the flapping meets suppression conditions, flapping suppression takes effect in the default mode (Hold-max-cost). Consequently, 65535 is used as the cost of the link between Switch B and Switch C. However, the forwarding path remains unchanged because intra-area routes take precedence over inter-area routes during route selection according to OSPF route selection rules. To prevent traffic loss in multi-area scenarios, configure Hold-down mode to prevent the neighbor relationship between Switch B and Switch C from being reestablished during the suppression period. During this period, traffic is forwarded along the path Switch A -> Switch B -> Switch D -> Switch E -> Switch F.

NOTE:

By default, the Hold-max-cost mode takes effect. The mode can be changed to Hold-down manually.

Figure 5-48  Flapping suppression in a multi-area scenario
Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression configured

In Figure 5-49, if the link between PE1 and P1 fails, an LDP LSP switchover is implemented immediately, causing the original LDP LSP to be deleted before a new LDP LSP is established. To prevent traffic loss, LDP-IGP synchronization needs to be configured. With LDP-IGP synchronization, 65535 is used as the cost of the new LSP to be established. After the new LSP is established, the original cost takes effect. Consequently, the original LSP is deleted, and LDP traffic is forwarded along the new LSP.

LDP-IGP synchronization and OSPF neighbor relationship flapping suppression work in either Hold-down or Hold-max-cost mode. If both functions are configured, Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost. Table 5-11 lists the suppression modes that take effect in different situations.

Table 5-11  Principles for selecting the suppression modes that take effect in different situations

LDP-IGP Synchronization/OSPF Neighbor Relationship Flapping Suppression Mode

LDP-IGP Synchronization Hold-down Mode

LDP-IGP Synchronization Hold-max-cost Mode

Exited from LDP-IGP Synchronization Suppression

OSPF Neighbor Relationship Flapping Suppression Hold-down Mode

Hold-down

Hold-down

Hold-down

OSPF Neighbor Relationship Flapping Suppression Hold-max-cost Mode

Hold-down

Hold-max-cost

Hold-max-cost

Exited from OSPF Neighbor Relationship Flapping Suppression

Hold-down

Hold-max-cost

Exited from LDP-IGP synchronization and OSPF neighbor relationship flapping suppression

For example, the link between PE1 and P1 frequently flaps in Figure 5-49, and both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression are configured. In this case, the suppression mode is selected based on the preceding principles. No matter which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is PE1 -> P4 -> P3 -> PE2.

Figure 5-49  Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression configured
Scenario with both bit-error-triggered protection switching and OSPF neighbor relationship flapping suppression configured

If a link has poor link quality, services transmitted along it may be adversely affected. If bit-error-triggered protection switching is configured and the bit error rate (BER) along a link exceeds a specified value, a bit error event is reported, and 65535 is used as the cost of the link, triggering route reselection. Consequently, service traffic is switched to the backup link. If both bit-error-triggered protection switching and OSPF neighbor relationship flapping suppression are configured, they both take effect. Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost.

OSPF Smart-Discover

Definition

Routers periodically send Hello packets through OSPF interfaces at the Hello interval specified in the Hello timer. This fixed interval slows down the establishment of OSPF neighbor relationships.

Enabling smart-discover can speed up establishment of OSPF neighbor relationships.

Table 5-12  OSPF smart-discover

Scenario

Processing

Smart-discover is not configured

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

  • Neighbors wait to receive Hello packets within the Hello interval.

Smart-discover is configured

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

  • Neighbors receive packets without delay and can immediately transition their status.

Principle

In the following situations, an interface with smart-discover enabled can send Hello packets to neighbors without waiting 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 Database Overflow

Definition

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

If the number of routes on a network increases and system resources are limited, routers may fail to carry some routing information. This is known as OSPF database overflow.

Purpose

Configuring stub areas or NSSAs partially addresses database overflows. However, this solution fails if there is an unexpected increase in dynamic routes. To dynamically limit the LSDB capacity and thereby prevent database overflows, set the maximum number of external LSAs in the LSDB.

Principle

Setting the maximum number of non-default external routes on a router can prevent database overflow.

All routers on the OSPF network must be configured 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, which, by default, is 5 seconds.

Table 5-13  OSPF database overflow phases

Overflow Phase

OSPF Processing

Entering overflow state

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

Staying in overflow state

  • The router does not generate non-default external routes.
  • The router discards 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 the number exceeds the upper limit, the router restarts the timer.
    • If the number is below the upper limit, the router exits from overflow state.

Exiting from the overflow state

  • The router deletes the overflow timer.
  • The router generates non-default routes.
  • The router learns the newly received non-default routes, and replies with an LSAck packet.
  • The router prepares to enter overflow state in case of future occurrences.

OSPF Mesh-Group

Definition

In scenarios with multiple concurrent links, you can deploy OSPF mesh-group to classify links into a mesh group. This allows OSPF to flood LSAs to only one link selected from the mesh group. OSPF mesh-group prevents repetitive flooding that burdens the system.

The mesh-group feature is disabled by default.

Purpose

After receiving or generating an LSA, an OSPF process floods the LSA. If there are multiple concurrent links, OSPF floods the LSA to each link and sends Update messages. Flooding more than one LSA is unnecessary as only the first is valid.

To prevent this unnecessary burden on the system, 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.

Implementation

As shown in Figure 5-50, RouterA and RouterB are connected through three links and 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 an unnecessary load on concurrent links.

Figure 5-50  LSA flooding with OSPF mesh-group disabled

If there are multiple concurrent links between a device enabled with OSPF mesh-group and its neighbor, the device floods received LSAs on only the primary link, as shown in Figure 5-51.

Figure 5-51  LSA flooding with OSPF mesh-group enabled

As defined in OSPF, LSAs can be flooded to a link only when the neighbor status reaches Exchange. When the status of the interface on the primary link is lower than Exchange, OSPF reselects a primary link from concurrent links before flooding 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.

The Router ID of a neighbor uniquely identifies the mesh group. Interfaces connected to the same neighbor with statuses greater than Exchange belong to the same mesh group.

In Figure 5-52, 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 is not part of the mesh group.

Figure 5-52  Interface not added to mesh group

NOTE:

If a router enabled with OSPF mesh-group has the same router ID as its directly connected neighbor, LSDBs cannot be synchronized and routes cannot be calculated correctly. In such a scenario, reconfigure the router ID of the neighbor.

Translation
Download
Updated: 2019-04-01

Document ID: EDOC1000178324

Views: 222717

Downloads: 194

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