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 V200R013C00

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, IPv4 IS-IS, IPv6 IS-IS, BGP, Routing Policy, IP Routing Table Management, and PBR.
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

As a widely used IGP, in most cases, OSPF runs in VPNs. 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, simplifying the 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 the following benefits:

  • OSPF is used within a site to learn routes. Running OSPF between PEs and CEs can reduce the protocol types that CEs must support, lowering the requirements on the CEs.

  • Running OSPF both within a site and between PEs and CEs frees network administrators from getting familiarity with multiple protocols, simplifying the workload of them.

  • Running OSPF between PEs and CEs 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 VPN 1. The numbers following OSPF refer to the IDs of OSPF mutli-instance processes 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-backbones 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 backbone areas (Area 0) be contiguous. Therefore, Area 0 in 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 the MPLS VPN backbone network. If no physical link is available to directly connect PEs to Area 0 in the VPN site, a virtual link can be used to implement logical connection between them, 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. As a result, the backbone area in Site 1 is isolated from the VPN backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the backbone areas are continuous.

OSPF Domain ID

If inter-area routes are advertised between local and remote OSPF areas, these areas are considered 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 of which is a primary ID with the others being secondary IDs.

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

Before a PE advertises the BGP routes learned from remote PEs 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-9  Domain ID

Comparison Between Local and Remote Domain IDs

Advertised 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 and all 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 if OSPF and BGP learn routes from each other.

Figure 5-39  OSPF VPN routing loop

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 a Type 5 or Type 7 LSA and advertises it to CE1.
  3. CE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the 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 respectively.
  5. Likewise, CE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the next hop of PE2, and PE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the next hop of CE1.
  6. In this way, 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 both CE1. That is, a routing loop occurs.

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 routes. The OSPF routes with the destination address of 10.1.1.1/32 and the next hop of CE1 are active in the routing tables of PE1 and PE2.

The BGP routes then become inactive, causing the deletion of the LSAs generated when OSPF imports the routes. As a result, the active OSPF routes are withdrawn, and the BGP route becomes active again. The above process occurs repeatedly, leading to route flapping.

OSPF VPN provides a solution to this problem, as described in the following table.

Table 5-10  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 retains the default value 0 for the DN bit of other LSAs.

When calculating routes, the OSPF multi-instance process of the PE ignores LSAs with the DN bit set to 1. This prevents the PE from learning the self-originated LSAs from CEs, thereby avoiding routing loops.

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 received 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-0 destination address and an all-0 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/OSPF route exchanges.

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

Figure 5-40 illustrates an inter-AS VPN in Option A mode. OSPF runs between PE1 and CE1. Assume that CE1 sends VPN routes to CE2.

Figure 5-40  Networking diagram of an inter-AS VPN deployed in Option A mode

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 the DN bit set to 1.

  3. When learning these LSAs using OSPF, ASBR2 checks the DN-bit in the LSAs. When detecting that the DN-bit in the LSAs is 1, ASBR2 ignores these LSAs.

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

The following methods are provided to solve this problem:

  • Method 1: Disable devices from setting the DN bit to 1 when importing BGP routes into OSPF. For example, ASBR1 is disabled from setting the DN-bit to 1 when importing BGP routes into OSPF. When ASBR2 receives these routes and detects that the DN-bit in the LSAs carrying these routes is 0, ASBR2 uses these LSAs to calculate routes.

  • Method 2: Disable devices from checking the DN-bit in received LSAs. For example, ASBR2 is disabled from checking the DN-bit in received LSAs. ASBR1 sets the DN-bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does not check the DN-bit when receiving these LSAs and uses these LSAs to calculate routes.

The two 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 LSAs.

In an inter-AS VPN Option A scenario as shown in Figure 5-41, four ASBRs are fully meshed and run OSPF. ASBR2 may receive Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If ASBR2 is disabled from checking 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, you can disable the check of the DN-bit only for the Type 3 LSAs that are generated by devices with the router ID 10.1.1.1 or 10.3.3.3. With the check disabled in such a way, if ASBR2 receives Type 3 LSAs sent by ASBR4 with the router ID 10.4.4.4, ASBR2 will check the DN-bit and deny these Type 3 LSAs because the DN-bit is set to 1.

Figure 5-41  Networking diagram of fully meshed ASBRs in the 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:

  • Support of OSPF-BGP synchronization is not required.

  • A separate OSPF instance is created for each service. That is, different virtual CEs transmit traffic for different services. This is a low-cost solution for LAN security issues.

  • Different OSPF multi-instances are implemented on a CE. To implement OSPF multi-instances, routing loop detection needs to be disabled and route calculation is performed directly. That is, MCEs also use the received LSAs with the DN bit set to 1 for route calculations.

OSPF TE

Traffic engineering (TE) requires knowledge of the network topology and network constraints, including the 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 LSAs to advertise network constraints. Then, the Constrained Shortest Path First (CSPF) algorithm can calculate the path that satisfies defined constraints.

OSPF TE is designed to support MPLS TE and the establishment and maintenance of the Label Switch Path (LSP). In MPLS TE architecture, OSPF 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 state 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 state information among devices in an area. This forms a uniform TEDB for route calculation.

Interaction Between OSPF TE and CSPF

OSPF uses Type 10 LSAs to collect traffic engineering information, including the 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 OSPF packets to reach a destination through a tunnel interface as the outbound interface. The differences between the two features are as follows:

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 need to use IGP shortcuts.

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

OSPF DS-TE

DiffServ Aware Traffic Engineering (DS-TE) combines the advantages of MPLS TE and Differentiated Services (DiffServ), and therefore it controls and forwards data differently based on Class of Service (CoS) while precisely controlling data paths. That is, 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 collect and advertise the information about the reservable bandwidth of each class type (CT) with a specific priority on the link. A class type refers to the bandwidth set of an LSP or a group of LSPs sharing the same CoS.

OSPF SRLG

OSPF supports Shared Risk Link Group (SRLG) applications in MPLS 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 value of the time to live (TTL) in an IP packet header is within a predefined range. An attacker may simulate real unicast OSPF 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 router will remain busy processing these packets, leading to a high CPU usage.

GTSM protects a device's TCP/IP-based control plane from certain attacks that consume CPU resources, for example, the CPU overload attack.

Devices with GTSM enabled check the TTL values in all received packets according to configured policies. An action is then performed on the 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 an IP packet sent to the device

  • VPN instance to which a packet belongs

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

  • Source interface number and destination interface number of a protocol above TCP/UDP

  • Valid TTL range

GTSM can be implemented for different connections:

  • For directly connected neighbors, the TTL 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 of multicast packets cannot exceed 255, and 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 preferred.

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 when a device restart occurs, without being affected by the actions on the control plane, such as re-establishment of neighbor relationships and route calculation. In this way, service interruption caused by route flapping is prevented and the network reliability is improved.

Basic Concepts of OSPF GR

Graceful Restart (GR), also called non-stop forwarding (NSF), is used to ensure normal traffic forwarding and proper running of key services 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 high availability (HA) technologies that include link protection, faulty node recovery, and traffic engineering, and is 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 neighbors of the GR time, cause, and interface address when the GR starts and ends.

  • Role of a switch during GR

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

    • Helper: is the switch that helps the Restarter. The Helper can be configured to:

      • Selectively support GR based on policies.
      • Support planned GR.
      • Support unplanned GR.
  • GR causes

    • 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 GR before GR timeout regardless of successful or failed GR.

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

  • Partial GR: When a neighbor of a switch does not support GR, only the interface associated with this neighbor exits GR, whereas the other interfaces perform GR normally.

  • Planned GR: Commands are manually configured to restart a switch or perform an active/standby switchover for the switch. The Restarter sends a Grace-LSA before the restart or switchover.

  • Unplanned GR: A switch performs an active/standby switchover without sending a Grace-LSA and then enters GR after the standby board goes Up. The process of unplanned GR after the standby board goes Up 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 phases:
  1. The Restarter (SwitchA) enters the GR state.

    1. The Restarter performs an active/standby switchover.

      NOTE:
      In planned GR mode, the Restarter sends a Grace-LSA to notify the Helper of the GR start, period, and cause before performing the switchover. In unplanned GR mode, the Restarter does not send any Grace-LSA.
    2. Before the Restarter enters the GR state, it sends a Grace-LSA to maintain OSPF neighbor relationships.
    3. When the standby 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 the neighbor relationship with the Restarter so that other switches do not detect the active/standby 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 the neighbor relationship list.
    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.

    An active/standby switchover or restart of the Restarter can be manually performed or automatically triggered by faults. During the switchover or restart, the Restarter does not delete the routing information from its routing table or FIB or reset its interface boards. Therefore, the service continuity can be implemented.

  3. The Restarter exits the GR state.

    • If the GR is successful, the Restarter reestablishes the 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, packet reception and status change on the Restarter and Helper are as follows:

      On the Restarter:

      • The Restarter times out the GR and fails to completely recover the neighbor relationships.

      • The Restarter fails to perform the bidirectional check due to Type 1 or Type 2 LSAs sent by the Helper.

      • The interface status of the Restarter changes.

      • The Restarter receives 1-way Hello packets from the Helper.

      • The Restarter receives a Grace-LSA generated by another switch on the same network segment.

        NOTE:
        Only one switch can perform GR on the same network segment at the same time.
      • Different DRs or BDRs are elected among the Restarter and neighbors on the same network segment due to topology changes.

      On the Helper:

      • The Helper fails to receive a Grace-LSA from the Restarter before the neighbor relationship expires.

      • The interface status of the Helper changes.

      • The Helper receives LSAs different from those in its own 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-11  Comparison of an active/standby switchover in GR mode and non-GR mode

Switchover in Non-GR Mode

Switchover in GR Mode

  • OSPF neighbor relationships are re-established.

  • Routes are recalculated.

  • The forwarding table changes.

  • The entire network detects the route changes, and routes flap 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 (65535).

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 the stability of the existing neighbor relationships, OSPF services, and other OSPF-dependent services, such as LDP and BGP. Suppression of OSPF neighbor relationship flapping can address this problem by delaying OSPF neighbor relationship reestablishment or preventing service traffic from passing through flapping links.

Related Concepts

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

Flapping_count: This parameter indicates the number of times flapping has occurred.

Detect-interval: This parameter indicates the flapping detection interval. The interval is used to determine whether to trigger a valid flapping_event.

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

Resume-interval: This parameter indicates the resumption interval. If the time between two valid flapping_events is longer than the resume-interval, flapping suppression exits.

Implementation
Flapping detection

A flapping counter is started on OSPF interfaces. Each time two consecutive flapping_events occur within a detect-interval, a valid flapping_event is recorded and the flapping_count increments by 1. When the flapping_count reaches or exceeds the threshold, the system determines that flapping occurs, triggers flapping suppression accordingly, and sets the flapping_count to 0. If two consecutive valid flapping_events occur within a period longer than the resume-interval before the flapping_count reaches the threshold again, the system also sets the flapping_count to 0. Interfaces start the suppression timer when the neighbor status 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, interfaces prevent neighbor relationships from being reestablished within the suppression period, which minimizes LSDB synchronization attempts and packet exchanges.
  • Hold-max-cost mode: In the case where the traffic forwarding path changes frequently, interfaces use 65535 as the cost of the flapping link within 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 after the Hold-down mode exits.

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

NOTE:
When an interface enters the flapping suppression state, all neighbors of the interface enter the state accordingly.
Exiting flapping suppression

Interfaces exit flapping suppression in the following scenarios:

  • The suppression timer expires.
  • The corresponding OSPF process is reset.
  • Command lines are configured to force interfaces to exit 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. At the early stage of the path switchover, there is a high probability that the status of the neighbor relationship between Switch B and Switch C flaps frequently, leading to frequent switchovers of forwarding paths. Each switchover triggered by faults causes traffic loss. The network stability is affected. In this scenario, if the devices are configured with flapping suppression, flapping suppression takes effect when the suppression conditions are met.

  • If flapping suppression works in Hold-down mode, the neighbor relationship between Switch B and Switch C is prevented from being reestablished within the suppression period so that the 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 within the suppression period so that the 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

If only one forwarding path exists on the network, the neighbor relationship flapping between any two devices on the path will interrupt traffic forwarding. In Figure 5-46, the only 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 the 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, the Hold-max-cost mode (rather than the 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 within 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 are different from those on Switch B, Switch A first detects the flapping and suppresses Switch C. Consequently, the Hello packets sent by Switch A do not carry the Switch ID of Switch C. However, Switch B has not detected the flapping yet and still considers Switch C as 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 same broadcast network as Switch C 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 intra-area routes, and therefore 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 of 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. Therefore, the Hold-down mode must be used in this scenario to prevent the neighbor relationship between Switch B and Switch C from being reestablished within 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. You can manually configure command lines to change the mode to Hold-down.

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 configured, 65535 is used as the cost of the new LSP to be established. After the new LSP is established, the original cost takes effect. Then, the original LSP is deleted, and LDP traffic is forwarded along the new LSP.

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

Table 5-12  Principles for selecting suppression modes in different situations

LDP-IGP Synchronization/OSPF Neighbor Relationship Flapping Suppression Mode

Hold-down Mode of LDP-IGP Synchronization

Hold-max-cost Mode of LDP-IGP Synchronization

Exiting LDP-IGP Synchronization Suppression

Hold-down mode of OSPF neighbor relationship flapping suppression

Hold-down

Hold-down

Hold-down

Hold-max-cost mode of OSPF neighbor relationship flapping suppression

Hold-down

Hold-max-cost

Hold-max-cost

Exiting OSPF Neighbor Relationship Flapping Suppression

Hold-down

Hold-max-cost

Exiting LDP-IGP synchronization and OSPF neighbor relationship flapping suppression

For example, the link between PE1 and P1 frequently flaps, as shown 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 above principles. No matter which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is switched to 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 a 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. The Hold-down mode takes precedence over the 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 in certain scenarios.

Table 5-13  OSPF smart-discover

Scenario

Processing

Smart-discover is not configured.

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

  • Devices wait to receive Hello packets within the Hello interval to establish neighbor relationships.

Smart-discover is configured.

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

  • Devices receive packets without delay and can immediately transmit their status to establish neighbor relationships.

Principle

In the following scenarios, an interface with smart-discover enabled can send Hello packets to target devices without waiting for the expiration of the Hello timer:

  • 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 LSDB.

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

Purpose

Configuring stub areas or NSSAs partially addresses database overflows. However, stub areas or NSSAs fail to resolve the problem of an unexpected increase in dynamic routes. To dynamically limit the LSDB capacity and thereby prevent database overflows, you can set the maximum number of external LSAs allowed in the LSDB.

Implementation

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

All routers on an 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 the overflow state after the timer expires. By default, the timer value is 5 seconds.

Table 5-14  OSPF database overflow phases

Overflow Phase

OSPF Processing

Entering the overflow state

A router deletes all non-default external routes generated by itself.

Staying in the overflow state

  • The router does not generate non-default external routes.
  • The router discards the newly received non-default external routes, and does not reply with LSAck packets.
  • When the overflow timer expires, the router checks whether the number of external routes still exceeds the upper limit and performs the following operations accordingly:
    • If the number of external routes still exceeds the upper limit, the router restarts the timer.
    • If the number of external routes is less than the upper limit, the router exits the overflow state.

Exiting the overflow state

  • The router resets the overflow timer.
  • The router generates non-default routes.
  • The router learns the newly received non-default external routes, and replies with LSAck packets.
  • The router prepares to enter the 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 one is valid.

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

Implementation

As shown in Figure 5-50, Router A and Router B are connected through three links and establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, Router A floods the LSA to Router B through interfaces 1, 2, and 3.

This flooding causes an unnecessary load on the concurrent links.

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

If there are multiple concurrent links between a device with OSPF mesh-group enabled and its neighbor, the device floods received LSAs only to 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 or a higher state. When the status of the interface on the primary link is lower than Exchange, OSPF reselects a primary link from concurrent links for flooding LSAs. After receiving LSAs flooded by Router A through link 1, Router B no longer floods the LSAs to Router A through link 2 and link 3.

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

In Figure 5-52, a mesh group of Router A 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 added to the mesh group.

Figure 5-52  Scenario where an interface cannot be added to a mesh group

NOTE:

If a router with OSPF mesh-group enabled has the same router ID as its directly connected neighbor, LSDBs cannot be synchronized and routes cannot be calculated correctly. In such a scenario, you need to reconfigure the router ID of the neighbor. (The configuration with the same router ID for two different devices is a configuration error.)

Translation
Download
Updated: 2019-04-08

Document ID: EDOC1100065744

Views: 67518

Downloads: 52

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