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

S600-E V200R013C00 Configuration Guide - IP Unicast Routing

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, 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 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-37 shows an OSPF GR process.

Figure 5-37  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-9  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-38, 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-38  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-39, 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-39  Flapping suppression in a single-forwarding path scenario
Broadcast scenario

In Figure 5-40, 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-40  Flapping suppression on a broadcast network
Multi-area scenario

In Figure 5-41, 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-41  Flapping suppression in a multi-area scenario
Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression configured

In Figure 5-42, 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-10 lists the suppression modes that take effect in different situations.

Table 5-10  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-42, 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-42  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-11  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-12  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-43, 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-43  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-44.

Figure 5-44  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-45, 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-45  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: EDOC1100066165

Views: 34301

Downloads: 3

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next