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 V200R011C10 Configuration Guide - IP Unicast Routing

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, 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 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-37 shows an OSPF GR process.

Figure 5-37  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-8  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-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. 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-38  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-39, 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-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 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-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 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-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, 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-9 lists the suppression modes that take effect in different situations.

Table 5-9  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-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 preceding principles. No matter which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is 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 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-10  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-11  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-43, 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-43  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-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. 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-45, 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-45  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-03-30

Document ID: EDOC1000178018

Views: 125319

Downloads: 17

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