No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

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

upgrade

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring OSPF

Configuring OSPF

By building OSPF networks, you can enable OSPF to discover and calculate routes in ASs.

Configuring Basic OSPF Functions

Before building OSPF networks, you need to configure basic OSPF functions.

Pre-configuration Tasks

Before configuring basic OSPF functions, complete the following tasks:

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

Creating an OSPF Process

Context

To run OSPF, the switch modules needs to have a router ID. A router ID of the switch modules is a 32-bit unsigned integer, which uniquely identifies the switch modules in an AS. To ensure the stability of OSPF, you need to manually configure a router ID for each device during network planning.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

    An OSPF process is created, and the OSPF view is displayed.

    • The parameter process-id specifies the ID of an OSPF process. The default value is 1.

      The switch modules supports OSPF multi-process. You can create different processes for different types of service. The OSPF process ID is valid in the local area, without affecting packet exchange with other switch moduless. Therefore, different switch moduless can also exchange packets even though they have different process IDs.

    • The parameter router-id router-id specifies the router ID of the switch modules.

      By default, the system automatically selects an IP address of the interface as the router ID. The largest IP address in loopback addresses is taken as the router ID. If no loopback interface is configured, the largest IP address configured on the interface is selected as the router ID.. When manually setting a router ID, ensure that the router ID of each device in an AS is unique. Generally, you can set the router ID to be the same as the IP address of a certain interface on the device.

      NOTE:

      The router ID of each OSPF process must be unique on the OSPF network; otherwise, the OSPF neighbor relationship cannot be set up and routing information is incorrect. Configuring a unique router ID for each OSPF process on each OSPF device is recommended.

    • The parameter vpn-instance vpn-instance-name specifies the name of a VPN instance.

      If a VPN instance is specified, the OSPF process belongs to the specified VPN instance. Otherwise, the OSPF process belongs to the public network instances.

  3. Run:

    commit

    The configuration is committed.

Creating an OSPF Area

Context

More and more devices are deployed with the increasing expansion of the network scale. As a result, each device has to maintain a large LSDB, which becomes a heavy burden. OSPF solves this problem by dividing an AS into areas. An area is regarded as a logical device group. Each group is identified by an area ID. The borders of an area are devices, rather than links. A network segment (or a link) belongs to only one area. That is, each OSPF interface must belong to an area.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

    The OSPF process is enabled, and the OSPF view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

    Areas are not equally important. The area with the area ID being 0 is called the backbone area. The backbone area is responsible for forwarding inter-area routing information. In addition, routing information between non-backbone areas must be forwarded through the backbone area.

  4. Run:

    commit

    The configuration is committed.

Enable OSPF

Context

After creating an OSPF process, you need to configure the network segments included in an area. A network segment belongs to only one area. That is, you need to specify an area for each interface that runs OSPF. In this document, the network segment refers to the network segment to which the IP address of the OSPF interface belongs.

OSPF checks the network mask carried in a received Hello packets. If the network mask carried in a received Hello packet is different from the network mask of the local device, the Hello packet is discarded. Then no OSPF neighbor relationship can be established.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

    OSPF can be enabled in an OSPF area or on a specific interface.

    • Enable OSPF in an OSPF area.

    1. Run:

      network ip-address wildcard-mask

      Network segments belonging to an area are configured.

      OSPF can properly run on an interface only when the following conditions are met:

      • The IP address mask length of the interface is equal to or greater than the mask length specified in the network command.

      • The primary IP address of the interface must be within the network segment specified by the network command.

      By default, OSPF advertises the IP address of the loopback interface as a 32-bit host route, which is irrelevant to the mask length configured on the loopback interface. To advertise routes to the network segment of the loopback interface, configure the network type as NBMA or broadcast in the interface view. For details, see Configuring Network Types of OSPF Interfaces.

    • Enable OSPF on an interface.

    1. Run the following command in the system view:

      interface interface-type interface-number

      The interface view is displayed.

    2. On an Ethernet interface, run:

      undo portswitch

      The interface is switched to Layer 3 mode.

      By default, an Ethernet interface works in Layer 2 mode.

      If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

      NOTE:

      If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

    3. Run:

      ospf enable process-id area area-id

      OSPF is enabled on the interface.

  4. Run:

    commit

    The configuration is committed.

(Optional) Creating OSPF Virtual Links

Context

After OSPF areas are defined, OSPF route updates between non-backbone areas are transmitted through a backbone area. Therefore, OSPF requires that all non-backbone areas maintain the connectivity with the backbone area and the backbone areas in different OSPF areas maintain the connectivity with each other. In real world situations, this requirement may not be met because of some restrictions. To resolve this problem, you can configure OSPF virtual links.

Perform the following steps on the switch modules running OSPF.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Run:

    vlink-peer router-id [ smart-discover | hello hello-interval | retransmit retransmit-interval | trans-delay trans-delay-interval | dead dead-interval | [ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-null | keychain keychain-name ] ] *

    A virtual link is created.

    This command must also be configured on the neighboring switch modules.

Follow-up Procedure

After virtual links are created, different default MTUs may be used on devices provided by different vendors. To ensure consistency, the MTU is set to 0 by default when the interface sends DD packets. For details, see Configuring an Interface to Fill in the DD Packet with the Actual MTU.

Checking the Configuration

Prerequisites

All configurations of basic OSPF functions are complete.

Procedure

  • Run the display ospf [ process-id ] peer command in any view to check information about OSPF neighbors.
  • Run the display ospf [ process-id ] interface command in any view to check information about OSPF interfaces.
  • Run the display ospf [ process-id ] routing command in any view to check information about the OSPF routing table.

Setting Parameters for OSPF Neighbor Relationship

On an OSPF network, all routing information is transmitted and exchanged between neighboring or adjacent devices. By maintaining neighbor relationships or adjacencies, you can stabilize the entire network.

Pre-configuration Tasks

Before configuring session parameters for the OSPF neighbor or adjacency relationship, complete the following tasks:

  • Configuring a link layer protocol

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

  • Configuring Basic OSPF Functions

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Setting the OSPF Packet Retransmission Limit

Context

After an OSPF switch modules sends one of the following packets, if it does not receive the LSAck packet within a specified time, it retransmits the packet. After the number of packet retransmissions reaches the set limit, the OSPF switch modules tears down the adjacency relationship with its neighbor.
  • DD packets
  • LSU packets
  • LSR packets

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF view is displayed.

  3. Run:

    retransmission-limit [ max-number ]

    The OSPF packet retransmission limit is set.

    By default, the OSPF packet retransmission limit is not set. The default maximum number of packet retransmissions is 30.

  4. Run:

    commit

    The configuration is committed.

Configuring an Interface to Fill in the DD Packet with the Actual MTU

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf mtu-enable

    The interface is configured to fill in the DD packet with the actual MTU and check whether the MTU in the DD packet from the neighbor exceeds the MTU of the local end.

    By default, the MTU in the DD packet sent by an interface is 0.

    Setting the MTU in a DD packet will lead to the reestablishment of the neighbor relationship.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of session parameters of the OSPF neighbor or adjacency relationship are complete.

Procedure

  • Run the display ospf [ process-id ] peer command to check information about OSPF neighbors.
  • Run the display ospf [ process-id ] brief command to check brief information about the specified OSPF process.
  • Run the display ospf [ process-id ] retrans-queue [ interface-type interface-number ] [ neighbor-id] command to check the OSPF retransmission list.

Configuring OSPF Attributes in Different Types of Networks

By setting network types for OSPF interfaces and adjusting OSPF attributes, you can build OSPF networks flexibly.

Applicable Environment
According to the types of link layer protocols, OSPF classifies networks into the following types:
  • P2MP: There is no concept of P2MP in link layer protocols. Therefore, a P2MP network must be forcibly changed from other network types.
  • NBMA: If the link layer protocol is FR, X.25, OSPF defaults the network type to NBMA.
  • Broadcast: If the link layer protocol is Ethernet or FDDI, OSPF defaults the network type to broadcast.
  • P2P: If the link layer protocol is PPP, HDLC, or LAPB, OSPF defaults the network type to P2P.

When link layer protocols remain unchanged, you can change network types and configure OSPF features to flexibly build networks.

Pre-configuration Tasks

Before configuring OSPF attributes in different types of networks, complete the following tasks:

Configuration Procedures
Figure 7-45 Flowchart of configuring OSPF attributes in different types of networks

Configuring Network Types of OSPF Interfaces

Context

You can configure one of the following network types for an interface as required:
  • P2MP: There is no concept of P2MP in link layer protocols. Therefore, a P2MP network must be forcibly changed from other network types.

  • NBMA: An NBMA network must be fully meshed. That is, any two switch moduleses on the NBMA network must be directly reachable. In most cases, however, this requirement cannot be met. In this case, you need to forcibly change the network type through commands.

  • Broadcast: To speed up the establishment of the neighbor relationship, you can change the network type of broadcast to P2P network.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf network-type { broadcast | nbma | p2mp | p2p }

    The network type of the OSPF interface is configured.

    By default, the network type of an interface depends on the physical interface. The network type of an Ethernet interface is broadcast.

    Configuring the new network type for an interface will cause the OSPF session on the interface to be reestablished.

    NOTE:

    Generally, the network types of OSPF interfaces on both ends of a link must be the same. Otherwise, routes cannot be correctly calculated.

  5. Run:

    commit

    The configuration is committed.

(Optional) Setting the DR Priority for the OSPF Interface of the Broadcast or NBMA Network Type

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf dr-priority priority

    The DR priority of the OSPF interface is set. The greater the value, the higher the priority.

    By default, the DR priority of an interface is 1.

  5. Run:

    commit

    The configuration is committed.

Follow-up Procedure

Restarting or shutting down the current interface will interrupt the OSPF adjacency relationship between devices. Therefore, perform the operation with caution.

Reconfiguring the DR priority for a device does not change the DR or BDR on a network. You can reelect a DR or BDR by using the following methods. This, however, will result in the interruption of the OSPF adjacency relationship between devices. Therefore, the following methods are used only when necessary.

  • Restart the OSPF processes on all the switch moduless.

  • Run the shutdown and then undo shutdown commands on the interfaces where the OSPF adjacency relationship is established.

Configuring P2MP Network Attributes

Procedure

  1. Disable OSPF from checking the network mask.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. On an Ethernet interface, run:

      undo portswitch

      The interface is switched to Layer 3 mode.

      By default, an Ethernet interface works in Layer 2 mode.

      If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

      NOTE:

      If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

    4. Run:

      ospf network-type p2mp

      The network type of the OSPF interface is configured.

      A P2MP network is forcibly changed from another other type of network. For details, see Configuring Network Types for OSPF Interfaces.

    5. Run:

      ospf p2mp-mask-ignore

      OSPF is disabled from checking the network mask on the P2MP network.

    6. Run:

      commit

      The configuration is committed.

  2. Configure the switch modules to filter the LSA packets to be sent.

    When multiple links exist between two switch moduless, you can configure the local switch modules to filter the LSA packets to be sent. This can reduce unnecessary LSA retransmission attempts and save bandwidth resources.

    1. Run:

      quit

      Exit from the interface view.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      filter-lsa-out peer ip-address { all | { summary [ acl { acl-number | acl-name } ] | ase [ acl { acl-number | acl-name } ] | nssa [ acl { acl-number | acl-name } ] } * }

      The local switch modules is configured to filter the LSA packets to be sent on the P2MP network.

      By default, the LSA packets to be sent are not filtered.

    4. Run:

      commit

      The configuration is committed.

Configuring Neighbors for NBMA Networks

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    peer ip-address [ dr-priority priority ]

    Neighbors are configured on an NBMA network.

    • The parameter ip-address specifies the IP address of a neighbor.
    • The parameter dr-priority priority specifies the DR priority of the neighbor. The greater the value, the higher the priority.

  4. Run:

    commit

    The configuration is committed.

(Optional) Configuring the Interval for Sending Poll Packets in NBMA Networks

Context

On an NBMA network, devices establish neighbor relationships with adjacencies by sending Hello packets.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf timer poll interval

    The interval for sending Poll packets on the NBMA interface is set.

    The parameter interval specifies the polling interval for sending Hello packets.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of OSPF attributes in different types of network are complete.

Procedure

  • Run the display ospf [ process-id ] interface command to check information about OSPF interfaces.
  • Run the display ospf [ process-id ] peer command to check information about OSPF neighbors.
  • Run the display ospf brief command to check the interval for sending Hello packets on an NBMA network.

Configuring OSPF Stub Areas

By configuring non-backbone areas at the edge of ASs as stub areas, you can reduce the size of the routing table and reduce the number of LSAs to be transmitted.

Applicable Environment

Dividing an AS into different areas can reduce the number of LSAs to be transmitted on the network and enhance OSPF extensibility. For some non-backbone areas at the edge of ASs, you can configure these areas as stub areas to further reduce the size of the routing table and the number of transmitted LSAs.

Pre-configuration Tasks

Before configuring OSPF stub areas, complete the following tasks:

Configuration Procedures
Figure 7-46 Flowchart of configuring OSPF stub areas
Defining the Current Area to be a Stub Area

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Run:

    stub [ no-summary ]

    The current area is configured as a stub area.

    If the parameter no-summary is specified, it indicates that an ABR is disabled from sending summary LSAs to a stub area. To disable an ABR from sending summary LSAs to a stub area, you can specify the parameter no-summary in the stub only when the stub command is configured on the ABR.

    To configure an area as a stub area, you need to run the stub command on all the switch moduless in this area.

    AS external routes in Type 5 LSAs cannot be advertised in a stub area. Therefore, the switch moduless in the stub area learn AS external routes from an ABR. The ABR automatically generates a Type 3 summary LSA with the link state ID being 0.0.0.0 and the network mask being 0.0.0.0 and then advertises the LSA in the entire stub area.

  5. Run:

    commit

    The configuration is committed.

(Optional) Configuring Metrics of Default Routes Sent to Stub Areas

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Run:

    stub [ no-summary ]

    The current area is configured as a stub area.

  5. Run:

    default-cost cost

    The cost of the default route to the stub area is set.

    The parameter cost specifies the cost of the Type 3 default route to a stub area. The default value is 1.

    This command applies to only the ABR that is connected to a stub area.

  6. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of OSPF stub areas are complete.

Procedure

  • Run the display ospf [ process-id ] peer command to check information about OSPF neighbors.
  • Run the display ospf [ process-id ] routing command to check information about the OSPF routing table.

Configuring OSPF NSSA Areas

Configuring a non-backbone area on the border of an autonomous system (AS) as a not-so-stubby area (NSSA) can reduce entries in the routing table and the amount of routing information to be transmitted.

Applicable Environment

An excessive number of entries in a routing table wastes network resources and causes high central processing unit (CPU) usage. To reduce entries in a routing table, configure a non-backbone area on the border of an AS as a stub area or an NSSA to reduce the amount of routing information to be transmitted. For details on how to configure an OSPF stub area, see Configuring OSPF Stub Areas.

An NSSA is a special type of Open Shortest Path First area. Neither the NSSA nor the stub area transmits routes learned from other areas in the AS where it resides. Different from the stub area, the NSSA allows AS external routes to be imported and forwarded in the entire AS.

An OSPF stub area can save system resources, but cannot import external routes. An NSSA can be applied to a scenario in which AS external routes are to be imported but not forwarded to save system resources.

Type 7 link state advertisements (LSAs) are used to carry imported AS external routing information in the NSSA. Type 7 LSAs are generated by autonomous system border routers (ASBRs) of NSSAs and flooded only in the NSSAs where ASBRs reside. The area border router (ABR) in an NSSA selects Type 7 LSAs from the received LSAs and translates them into Type 5 LSAs to advertise AS external routes to the other areas over the OSPF network.

NOTE:
  • A Type 7 LSA is a new type of LSA that has been introduced to support NSSAs and describe imported external routes.
  • Type 7 LSAs can be used to carry default route information to guide traffic to other ASs.
Pre-configuration Tasks

Before configuring an NSSA, complete the following tasks:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Run:

    nssa [ default-route-advertise | no-import-route | no-summary | set-n-bit | suppress-forwarding-address | translator-always | translator-interval interval-value | zero-address-forwarding ] *

    The specified area is configured as an NSSA.

    NOTE:
    • NSSA attributes must be configured on all devices in the NSSA using the nssa command.
    • Configuring or deleting NSSA attributes may trigger routing update in the area and disconnection from neighbors. A second configuration of NSSA attributes can be implemented or canceled only after a routing update is complete.
    The nssa command is applicable to the following scenarios:
    • The default-route-advertise parameter is configured to advertise Type 7 LSAs carrying the default route on the ASBR to the NSSA.

      Regardless of whether the default route 0.0.0.0/0 exists in the routing table on the ABR, Type 7 LSAs carrying the default route will be generated. However, Type 7 LSAs carrying the default route will be generated only when the default route 0.0.0.0/0 exists in the routing table on the ASBR.

    • If an ASBR also functions as an ABR, the no-import-route parameter is configured to prevent external routes imported using the import-route command from being advertised to the NSSA.
    • The no-summary parameter is configured on an ABR to reduce the number of LSAs that are transmitted to the NSSA. This implementation prevents the ABR from transmitting Type 3 LSAs to the NSSA.
    • After the set-n-bit parameter is configured, the N-bit is set in the database description (DD) packets during the synchronization between the switch modules and neighboring switch moduless.
    • The suppress-forwarding-address parameter sets the forwarding address (FA) of the Type 5 LSAs translated from Type 7 LSAs by the NSSA ABR to 0.0.0.0.
    • If multiple ABRs are deployed in the NSSA, the system automatically selects an ABR (generally the switch modules with the largest router ID) as a translator to convert Type 7 LSAs into Type 5 LSAs. You can configure the translator-always parameter on an ABR to specify the ABR as an all-the-time translator. To specify two ABRs for load balancing, configure the translator-always parameter on the chosen ABRs to specify the ABRs as all-the-time translators. You can use this command to pre-configure a fixed translator to prevent LSA flooding caused by translator role changes.
    • The translator-interval parameter is used to ensure uninterrupted services when translator roles change. The value of interval-value must be greater than the flooding period.
    • The zero-address-forwarding parameter is used to set the FA of the generated NSSA LSAs to 0.0.0.0 when external routes are imported to the ABR in an NSSA.

  5. (Optional) Run:

    default-cost cost

    The cost of the default route on which Type 3 LSAs are transmitted to the NSSA by the ABR is set.

    To ensure the reachability of AS external routes, the ABR in the NSSA generates a default route and advertises this route to the other switch moduless in the NSSA. The cost of the default route to an NSSA is set and the selection of the default route is adjusted.

    By default, the cost of the default route to the NSSA by the ABR is 1.

  6. Run:

    commit

    The configuration is committed.

Checking the Configuration

Run either of the following commands to check LSDB information:

  • display ospf [ process-id ] lsdb [ brief ]

  • display ospf [ process-id ] lsdb [ router | network | summary | asbr | ase | nssa | opaque-link | opaque-area ] [ link-state-id ] hostname hostname [ age { min-value min-age-value | max-value max-age-value } * ]

  • display ospf [ process-id ] lsdb [ router | network | summary | asbr | ase | nssa | opaque-link | opaque-area ] [ link-state-id ] [ originate-router [ advertising-router-id ] | self-originate ] [ age { min-value min-age-value | max-value max-age-value } * ] [ resolve-hostname ]

Run either of the following commands to check routing table information:

  • display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface interface-type interface-number ] [ nexthop nexthop-address ]

  • display ospf [ process-id ] routing router-id [ router-id ]

Run the display ospf [ process-id ] interface [ all | interface-type interface-number ] [ verbose ] command to check OSPF interface information.

Adjusting OSPF Route Selection

By adjusting OSPF route selection, you can enable OSPF to meet the requirements of complex networks.

Applicable Environment

On complex networks, you can adjust OSPF parameters to flexibly adjust the networking and optimize load balancing.

Pre-configuration Tasks

Before adjusting OSPF route selection, complete the following tasks:

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Setting the Link Cost for an OSPF Interface

Context

OSPF can automatically calculate the link cost for an interface according to the interface bandwidth. You can also set the link cost for the interface through commands.

If you do not set the cost of an OSPF interface by using the ospf cost cost command, OSPF automatically calculates the cost of the interface according to the interface bandwidth. The calculation formula is as follows: Cost of the interface = Bandwidth reference value/Interface bandwidth. The integer of the calculated result is the cost of the interface. If the calculated result is smaller than 1, the cost value is 1. Changing the bandwidth reference value can change the cost of an interface.

Procedure

  • Setting the link cost for an OSPF interface
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The OSPF interface view is displayed.

    3. On an Ethernet interface, run:

      undo portswitch

      The interface is switched to Layer 3 mode.

      By default, an Ethernet interface works in Layer 2 mode.

      If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

      NOTE:

      If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

    4. Run:

      ospf cost cost

      The cost of the OSPF interface is set.

    5. Run:

      commit

      The configuration is committed.

  • Setting the bandwidth reference value
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      bandwidth-reference value

      The bandwidth reference value is set.

      The parameter value specifies the bandwidth reference value used to calculate the link cost, in Mbit/s.

    4. Run:

      commit

      The configuration is committed.

Setting the Preference for Equal-cost OSPF Routes

Context

After OSPF calculates equal-cost routes, you can run the nexthop command to select the route with the highest priority from the equal-cost routes as the next hop. The smaller the weight, the higher the priority of the route. The default weight is 255. OSPF discovers equal-cost routes and the number of equal-cost routes is smaller than or equal to that specified in the maximum load-balancing number command. In this case, OSPF traffic will be balanced among these equal-cost routes.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    nexthop ip-address weight value

    The preference is set for equal-cost routes.

    • The parameter ip-address specifies the next-hop address of the equal-cost route.
    • The parameter value specifies the weight of the next hop. The default value is 255. The smaller the weight, the higher the priority of the route.

  4. Run:

    commit

    The configuration is committed.

Setting the Maximum Number of Equal-Cost Routes

Context

The CX11x&CX31x&CX91x series switch modules support load balancing among equal-cost routes. That is, you can configure multiple routes, which have the same destination and preference.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    maximum load-balancing number

    The maximum number of equal-cost routes is set.

    NOTE:
    When the number of equal-cost routes is greater than number specified in the maximum load-balancing command, valid routes are selected for load balancing based on the following criteria:
    1. Route preference: Routes with higher preferences are selected for load balancing.
    2. Interface index: If routes have the same priorities, routes with higher interface index values are selected for load balancing.
    3. Next hop IP address: If routes have the same priorities and interface index values, routes with larger IP address are selected for load balancing.

  4. Run:

    commit

    The configuration is committed.

Configuring External Route Selection Rules Compatible with RFC 1583

Context

All devices in an OSPF routing domain must be configured with the same route selection rule. At present, most OSPF routing domains adopt the route selection rules defined in RFC 2328.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. (Optional)Run:

    rfc1583 compatible

    The external route selection rules, which are compatible with RFC 1583, are configured.

    By default, the routing rule of compatible 1583 is enabled.

    NOTE:

    On a network, if OSPF switch moduless have different configurations of the external route selection rules compatible with RFC 1583, external loops may occur.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of adjusting OSPF route selection are complete.

Procedure

  • Run the display ospf [ process-id ] interface command to check information about OSPF interfaces.
  • Run the display ospf [ process-id ] routing command to check information about the OSPF routing table.

Controlling OSPF Routing Information

This section describes how to control OSPF routing information. Detailed operations include importing external routes, and filtering the received routes and LSAs.

Pre-configuration Tasks

Before controlling OSPF routing information, complete the following tasks:

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Configuring OSPF to Import External Routes

Context

OSPF can ensure loop-free intra-area routes and inter-area routes; however, OSPF cannot protect external routes against loops. Therefore, when configuring OSPF to import external routes, avoid the loops caused by manual configurations.

Do as follows on the switch modules that functions as the ASBR running OSPF:

Procedure

  • Configuring OSPF to import the routes discovered by other protocols
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      import-route { bgp [ permit-ibgp ] | direct | rip [ process-id-rip ] | static | isis [ process-id-isis ] | ospf [ process-id-ospf ] } [ cost cost | route-policy route-policy-name | tag tag | type type ] * 

      The routes discovered by other protocols are imported.

    4. Run:

      commit

      The configuration is committed.

  • Setting parameters for OSPF to import routes
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      default { cost { cost-value | inherit-metric } | tag tag | type type } *

      The default values of parameters (the metric of routes, tag, and type) are set for importing routes.

      • The parameter cost cost-value specifies the default metric of the external route imported by OSPF.
      • The parameter inherit-metric indicates that the cost of the imported route is the cost carried in the route. If the cost is not specified, the default cost set through the default command is used as the cost of the imported route.

      When OSPF imports external routes, you can set default values for some additional parameters, such as the metric of routes to be imported, route tag, and route type. The route tag is used to identify the protocol-related information. For example, it can be used to differentiate AS numbers when OSPF receives BGP routes.

      By default, the default metric of the external routes imported by OSPF is 1; the type of the imported external routes is Type 2; the default tag value is 1.
      NOTE:
      You can run one of the following commands to set the cost of the imported route. The following commands are listed in descending order of priority:
      • Run the apply cost command in a route-policy to set the cost of the imported route.
      • Run the import-route command for OSPF to set the cost of the imported route.
      • Run the default command to set the default cost of the imported route.

    4. Run:

      commit

      The configuration is committed.

Configuring OSPF to Advertise the Default Route to the OSPF Area

Context

In a routing table, a default route is the route to the network 0.0.0.0 (with the mask being 0.0.0.0). You can check whether the default route is configured by using the display ip routing-table command. If the destination address of a packet does not match any entry in the routing table, the packet is sent through a default route. If no default route exists and the destination address of the packet does not match any entry in the routing table, the packet is discarded. An Internet Control Message Protocol (ICMP) packet is then sent, informing the originating host that the destination host or network is unreachable.

Procedure

  • Configuring OSPF to Advertise the Default Route to the OSPF Area
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run the following commands as required:

      • Run:

        default-route-advertise [ [ always | permit-calculate-other ] | cost cost | type type | route-policy route-policy-name | distribute-delay delay-time ] *

        OSPF is configured to advertise the default route to the OSPF area.

        • always indicates that an LSA describing the default route is generated and then advertised regardless of whether there are the active default routes of other OSPF processes in the routing table of the local device.
        • permit-calculate-other indicates that the local router is still allowed to calculate the default routes advertised by other switch moduless after adverting its default route.
        • route-policy route-policy-name indicates that the local device advertises default routes according to the parameters of the configured routing policy when there are matched default routing entries generated by other OSPF processes.
      • Run:

        default-route-advertise summary cost cost

        The default cost of a Type 3 summary LSA is set.

        Before selecting the preceding parameters, you need to configure VPN. Otherwise, this command cannot be run.

      NOTE:
      • An ASE LSA that describes the default route is generated and then advertised only when there are active default routes of other OSPF processes in the routing table of the local device.
      • Before advertising a default route, OSPF compares the preferences of default routes. Therefore, if a static default route is configured on an OSPF switch modules, to add the default route advertised by OSPF to the current routing table, ensure that the preference of the configured static default route is lower than that of the default route advertised by OSPF.

    4. Run:

      commit

      The configuration is committed.

Configuring OSPF Route Aggregation

Context

Do as follows on the OSPF router.

Procedure

  • Configuring ABR Route Aggregation
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      area area-id

      The OSPF area view is displayed.

    4. Run:

      abr-summary ip-address mask [ [ advertise | not-advertise ] | cost cost | inherit-minimum } ]*

      ABR route aggregation of OSPF is configured.

    5. Run:

      commit

      The configuration is committed.

  • Configuring ASBR Route Aggregation
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospf [ process-id ]

      The OSPF process view is displayed.

    3. Run:

      asbr-summary ip-address mask [ not-advertise | tag tag | cost cost | distribute-delay interval ] *

      ASBR route aggregation of OSPF is configured.

    4. Run:

      commit

      The configuration is committed.

Configuring OSPF to Filter the Received Routes

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy route-policy-name [ secondary ] } import

    OSPF is configured to filter the received routes.

    • The parameter acl-number specifies the number of a basic ACL.
    • The parameter acl-name acl-name specifies the name of an ACL.
    • The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.

    OSPF is a link-state dynamic routing protocol, with routing information carried in the LSA. Therefore, the filter-policy import command cannot be used to filter the advertised or received LSAs.

    The filter-policy import command is used to filter the routes calculated by OSPF. Only the routes that pass the filtering are added to the routing table. Routes that do not pass the filtering can not added to the OSPF routing table, but can be advertised.

  4. Run:

    commit

    The configuration is committed.

Configuring OSPF to Filter the Routes to Be Advertised

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name } export [ protocol [ process-id ] ]

    OSPF is configured to filter the routes imported through the import-route command. Only the routes that pass the filtering are advertised.

    • The parameter acl-number specifies the number of a basic ACL.
    • The parameter acl-name acl-name specifies the name of an ACL.
    • The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.

    You can specify the parameter protocol [ process-id ] to filter the routes of a certain routing protocol or a certain OSPF process. If protocol [ process-id ] is not specified, OSPF filters all the imported routes.

    NOTE:
    • The import-route command cannot be used to import external default routes.
    • OSPF filters the imported routes, and generates Type 5 LSAs to advertise only external routes that passing the filtering.

  4. Run:

    commit

    The configuration is committed.

Configuring the switch modules to Filter LSAs to Be Sent

Context

When multiple links exist between two switch moduleses, you can configure the local switch modules to filter the LSAs to be sent. This prevents unnecessary LSA transmission and saves bandwidth resources.

Perform the following steps on the switch modules running OSPF.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf filter-lsa-out { all | { summary [ acl { acl-number | acl-name } ] | ase [ acl { acl-number | acl-name } ] | nssa [ acl { acl-number | acl-name } ] } * }

    The LSAs to be sent are filtered.

    By default, the LSAs to be sent are not filtered.

Configuring OSPF to Filter ABR Type3 LSA

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Depending on type of desired filtering, run one of following commands to configure OSPF to filter the Type 3 LSAs generated by ABRs.:

    OSPF is configured to filter the Type 3 LSAs generated by ABRs.

    • Run:

      filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy route-policy-name } export

      The outgoing summary LSAs in the local area will be filtered.

    • Run:

      filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy route-policy-name } import [ include-abr-summary ]

      The incoming summary LSAs in the local area are to be filtered.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of controlling OSPF routing information are complete.

Procedure

  • Run the display ospf [ process-id ] lsdb command to check information about the OSPF LSDB.

Configuring OSPF IP FRR

In the case of a link fault, a device enabled with OSPF IP FRR can fast switch traffic to the backup link. This protects traffic and greatly improves the reliability of OSPF networks.

Pre-configuration Tasks

Before configuring OSPF IP FRR, complete the following tasks:

Configuration Procedures
Figure 7-47 Flowchart for configuring OSPF IP FRR

Enabling OSPF IP FRR

Context

FRR calculation consumes a large number of CPU resources. When there are import features such as routing protocol, you need to delay FRR calculation.

After FRR calculation is delayed, devices process important services such as route calculation first.

Do as follows on the switch modules that needs to protect traffic to be forwarded:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ] [ router-id router-id | vpn-instance vpn-instance-name ] *

    An OSPF process is started and the OSPF view is displayed.

  3. Run:

    frr

    The OSPF IP FRR view is displayed.

  4. Run:

    loop-free-alternate

    OSPF IP FRR is enabled to generate a loop-free backup link.

    NOTE:

    OSPF can generate a loop-free backup link only when the OSPF IP FRR traffic protection inequality is met.

  5. Run:

    commit

    The configuration is committed.

(Optional) Blocking FRR on an OSPF Interface

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The view of an OSPF interface enabled with FRR is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf frr block

    FRR is blocked on the OSPF interface.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All OSPF IP FRR configurations are complete.

Procedure

  • Run the display ospf [ process-id ] routing command to check the information about the primary link and backup link of a route after configuring OSPF IP FRR.

Configuring BFD for OSPF

If there are high requirements for data transmission, and OSPF convergence needs to be speeded up when the link status changes, you can configure BFD on OSPF links. After detecting a link failure, BFD notifies the routing protocol of the failure, which triggers fast convergence. When the neighbor relationship is Down, the BFD session is deleted dynamically.

Applicable Environment

The link fault or the topology change may cause devices to recalculate routes. Therefore, the convergence of routing protocols must be speed up to improve the network performance.

Link faults are inevitable. Therefore, a feasible solution is required to fast detect faults and notify routing protocols of the faults immediately. If BFD is associated with routing protocols, once a link fault occurs, BFD can speed up the convergence of routing protocols.

Pre-configuration Tasks

Before configuring BFD for OSPF, complete the following tasks:

Configuration Procedures
Figure 7-48 Flowchart of configuring BFD for OSPF
Configuring Global BFD

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    bfd

    BFD is configured globally, and the global BFD view is displayed.

  3. Run:

    commit

    The configuration is committed.

Configuring BFD for OSPF Feature

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF view is displayed.

  3. Run:

    bfd all-interfaces enable

    BFD for OSPF is enabled to establish the BFD session.

    If all the interfaces in a certain process are configured with BFD and their neighbor relationships are in the Exstart state, OSPF establishes BFD sessions on all the interfaces in the process.

    Run the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-interval | detect-multiplier multiplier-value | frr-binding } * command to set parameters for BFD sessions.
    • The parameter min-rx-interval receive-interval specifies the expected minimum interval for receiving BFD packets from the neighbor.
    • The parameter min-tx-interval transmit-interval specifies the minimum interval for sending BFD packets to the neighbor.
    • The parameter detect-multiplier multiplier-value specifies the local detection multiplier.
    • The parameter frr-binding indicates that the status of the BFD session is bound to OSPF IP FRR.
    NOTE:

    If only the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-interval | detect-multiplier multiplier-value | frr-binding } * command is run to set BFD parameters, and the bfd all-interfaces enable command is not run, BFD cannot be enabled.

  4. Run:

    commit

    The configuration is committed.

(Optional) Preventing an Interface from Dynamically Setting Up a BFD Session

Context

After the bfd all-interfaces enable command is run in an OSPF process, BFD sessions can be established on all the OSPF interfaces whose neighbor relationships are Full.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The view of the interface enabled with BFD for OSPF is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf bfd block

    The interface is prevented from dynamically establishing a BFD session.

  5. Run:

    commit

    The configuration is committed.

(Optional) Configuring BFD on the Specified Interface

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The view of the interface enabled with BFD for OSPF is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf bfd enable

    BFD is enabled on the interface to establish the BFD session.

    If all the interfaces in a certain process are configured with BFD and their neighbor relationships are in the Exstart state, OSPF establishes BFD sessions on all the interfaces in the process by using default BFD parameters.

    Run the ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit- interval | detect-multiplier multiplier-value } * command to set parameters for BFD sessions.

    NOTE:
    • The BFD priority configured on an interface is higher than the BFD priority configured in a process. That is, if BFD is enabled on an interface, BFD parameters on the interface are used to establish BFD sessions.

    • If only the ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit- interval | detect-multiplier multiplier-value } * command is run to set BFD parameters, and the ospf bfd enable command is not run, BFD cannot be enabled on the interface.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of BFD for OSPF are complete.

Procedure

  • Run one of the following commands to check the BFD session:

    • display ospf [process-id ] bfd session interface-type interface-number [ router-id ]
    • display ospf [process-id ] bfd session { router-id | all }

Configuring OSPF Fast Convergence

By adjusting OSPF timers, you can implement OSPF fast network convergence.

Pre-configuration Tasks

Before configuring OSPF fast convergence, complete the following tasks:

  • Configuring a link layer protocol

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

  • Configuring Basic OSPF Functions

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Setting the Convergence Priority of OSPF Routes

Context

With the integration of network services, different services such as data, voice, and video run on the same network infrastructure, and have different requirements for the network. For Video on Demand (VoD) services, the route convergence speed of the multicast source server is the most critical factor that affects multicast services. It is required that the routes to the multicast source should converge rapidly when network faults occur. On the BGP or MPLS VPN bearer network where OSPF is used to implement the IP connectivity of the backbone network, end-to-end routes between PEs need to be converged rapidly.

You can set priorities for specific routes by setting the convergence priority of OSPF routes so that these routes converge preferentially. This shortens the interruption of key services and improves the reliability of the entire network.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF view is displayed.

  3. Run:

    prefix-priority { critical | high | medium } ip-prefix ip-prefix-name

    The convergence priority of OSPF routes is set.

    After the convergence priority of OSPF routes is set, OSPF can calculate and flood LSAs, and synchronize LSDBs according to priorities. This speeds up route convergence. When an LSA meets multiple priorities, the highest priority takes effect. OSPF calculates LSAs in the sequence of intra-area routes, inter-area routes, and AS external routes. This command makes OSPF calculate route priorities. Convergence priorities are critical, high, medium, and low. To speed up the processing of LSAs with the higher priority, during LSA flooding, the LSAs need to be placed into the corresponding critical, high, medium, and low queues according to priorities.

    NOTE:

    This command takes effect only on the public network.

  4. Run:

    commit

    The configuration is committed.

Setting the Interval for Sending Hello Packets

Context

Hello packets are commonly used packets, which are periodically sent on OSPF interfaces to establish and maintain neighbor relationships. The intervals set on the interfaces connecting two OSPF neighbors need to be the same. Otherwise, the OSPF neighbor relationship cannot be established.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf timer hello interval

    The interval for sending Hello packets is set on the OSPF interface.

    By default, the interval for sending Hello packets on a P2P or broadcast interface is 10s; the interval for sending Hello packets on a P2MP or NBMA interface is 30s; the dead time for the OSPF neighbors on the same interface is four times the interval for sending Hello packets.

  5. Run:

    commit

    The configuration is committed.

Setting the Dead Time of the Neighbor Relationship

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf timer dead interval

    The dead time after which the neighbor relationship between two switch moduless is set.

    By default, the dead time of the neighbor relationship on a P2P or broadcast interface is 40s; the dead time of the neighbor relationship on a P2MP or NBMA interface is 120s; the dead time of the neighbor relationship on the same interface is four times the interval for sending Hello packets.

    NOTE:

    Setting the dead interval of an OSPF neighbor to be longer than 20s is recommended. If the dead interval of an OSPF neighbor is shorter than 20s, the session may be closed.

    Both the Hello timer and the Dead timer are restored to the default values after the network type is changed.

  5. Run:

    commit

    The configuration is committed.

Configuring Smart-discover

Context

Before Smart-discover is configured, when the neighbor status of the switch modules changes or the DR/BDR on the multi-access network (broadcast or NBMA network) changes, the switch modules does not send Hello packets to its neighbor until the Hello timer expires. This slows down the establishment of neighbor relationships between devices. After Smart-discover is configured, when the neighbor relationship status of the switch modules changes or the DR/BDR on the multi-access network (broadcast or NBMA network) changes, the switch modules can send Hello packets to its neighbor immediately without waiting for the expiration of the Hello timer. This speeds up the establishment of neighbor relationships and thus implements fast convergence of OSPF networks.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf smart-discover

    Smart-discover is configured on the interface.

  5. Run:

    commit

    The configuration is committed.

Setting the Interval for Updating LSAs

Context

In OSPF, the interval for updating LSAs is defined as 5s. This aims to prevent network connections or frequent route flapping from consuming excessive network bandwidth or device resources.

On a stable network where routes need to be fast converged, you can cancel the interval for updating LSAs by setting the interval to 0 seconds. In this manner, the changes of the topology or the routes can be immediately advertised on the network through LSAs. Route convergence on the network is thus sped up.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    lsa-originate-interval { 0 | { intelligent-timer max-interval start-interval hold-interval | other-type interval } * }

    The interval for updating LSAs is set.

    • The parameter intelligent-timer indicates that the interval for updating router LSAs and network LSAs is set through an intelligent timer.
    • The parameter max-interval specifies the maximum interval for updating LSAs, in milliseconds.
    • The parameter start-interval specifies the initial interval for updating LSAs, in milliseconds.
    • The parameter hold-interval specifies the hold interval for updating LSAs, in milliseconds.
    • The parameter other-type interval indicates that the interval for updating LSAs excluding Router LSAs and Network LSAs is set.
    By default, intelligent timer is enabled. After an intelligent timer is enabled, the default maximum interval for updating LSAs is 5000 ms, the default initial interval is 500 ms, and the default hold interval is 1000 ms (the interval is expressed in milliseconds). Details about the interval for updating LSAs are as follows:
    1. The initial interval for updating LSAs is specified by start-interval.
    2. The interval for updating LSAs for the nth (n ≥ 2) time is equal to hold-interval x 2(n-2).
    3. When the interval specified by hold-interval x 2(n-2) reaches the maximum interval specified by max-interval, OSPF updates LSAs at the maximum interval for three consecutive times. Then, OSPF goes back to Step 3.a and updates LSAs at the initial interval specified by start-interval.

  4. Run:

    commit

    The configuration is committed.

Setting the Interval for Receiving LSAs

Context

In OSPF, the interval for receiving LSAs is 1s. This aims to prevent network connections or frequent route flapping from consuming excessive network bandwidth or device resources.

On a stable network where routes need to be fast converged, you can cancel the interval for receiving LSAs by setting the interval to 0 seconds. In this manner, the changes of the topology or the routes can be immediately advertised to the network through LSAs. Route convergence on the network is thus sped up.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    lsa-arrival-interval { interval | intelligent-timer max-interval start-interval hold-interval }

    The interval for receiving LSAs is set.

    • The parameter interval specifies the interval for receiving LSAs, in milliseconds.
    • The parameter intelligent-timer indicates that the interval for receiving router LSAs or network LSAs is set through an intelligent timer.
    • The parameter max-interval specifies the maximum interval for receiving LSAs, in milliseconds.
    • The parameter start-interval specifies the initial interval for receiving LSAs, in milliseconds.
    • The parameter hold-interval specifies the hold interval for receiving LSAs, in milliseconds.

    On a stable network where routes need to be fast converged, you can set the interval for receiving LSAs to 0 seconds so that the changes of the topology or the routes can be detected immediately.

    By default, intelligent timer is enabled. After an intelligent timer is enabled, the default maximum interval for receiving LSAs is 1000 ms, the default initial interval is 500 ms, and the default hold interval is 500 ms. Details about the interval for receiving LSAs are as follows:
    1. The initial interval for receiving LSAs is specified by the parameter start-interval.
    2. The interval for receiving LSAs for the nth (n ≥ 2) time is equal to hold-interval x 2(n-2).
    3. When the interval specified by hold-interval x 2(n-2) reaches the maximum interval specified by max-interval, OSPF receives LSAs at the maximum interval for three consecutive times. Then, OSPF goes back to Step 3.a and receives LSAs at the initial interval specified by start-interval.

  4. Run:

    commit

    The configuration is committed.

Setting the Interval for the SPF Calculation

Context

When the OSPF LSDB changes, the shortest path needs to be recalculated. If a network changes frequently and the shortest path is calculated continually, many system resources are consumed and thus system performance is degraded. By configuring an intelligent timer and properly setting the interval for the SPF calculation, you can prevent excessive system memory and bandwidth resources from being occupied.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    spf-schedule-interval { interval1 | intelligent-timer max-interval start-interval hold-interval | millisecond interval2 }

    The interval for the SPF calculation is set.

    • The parameter interval1 specifies the interval for the SPF calculation, in milliseconds.
    • The parameter intelligent-timer indicates that the interval for the SPF calculation is set through an intelligent timer.
    • The parameter max-interval specifies the maximum interval for the SPF calculation, in milliseconds.
    • The parameter start-interval specifies the initial interval for the SPF calculation, in milliseconds.
    • The parameter hold-interval specifies the hold interval for the SPF calculation, in milliseconds.
    • The parameter millisecond interval2 specifies the interval for the SPF calculation, in milliseconds.

    By default, an intelligent timer is enabled; the maximum interval for the SPF calculation is 10000 ms, the initial interval is 500 ms, and the hold interval is 1000 ms (the interval is expressed in milliseconds).

    After an intelligent timer is enabled, the interval for the SPF calculation is as follows:

    1. The initial interval for the SPF calculation is specified by the parameter start-interval.

    2. The interval for the SPF calculation for the nth (n ≥ 2) time is equal to hold-interval x 2(n-2).

    3. When the interval specified by hold-interval x 2(n-2) reaches the maximum interval specified by max-interval, OSPF performs the SPF calculation at the maximum interval for three consecutive times. Then, OSPF goes back to 3.a and performs the SPF calculation at the initial interval specified by start-interval.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of OSPF fast convergence are complete.

Procedure

  • Run the display ospf [ process-id ] brief command to check brief information about the specified OSPF process.

Configuring OSPF GR Helper

To avoid traffic interruption and route flapping caused by the active/standby switchover, you can enable OSPF GR.

Applicable Environment

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

NOTE:

The CX11x&CX31x&CX91x series switch modules support only the GR Helper.

Pre-configuration Tasks

Before configuring OSPF GR, complete the following tasks:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF view is displayed.

  3. Run:

    opaque-capability enable

    The opaque-LSA capability is enabled.

    The opaque-LSA capability of OSPF needs to be enabled first because OSPF supports GR through Type 9 LSAs.

  4. Run:

    graceful-restart helper-role { [ { ip-prefix ip-prefix-name | acl-number acl-number | acl-name acl-name } | ignore-external-lsa | planned-only ] * | never }

    The GR session parameters is set.

    • Set ACL parameters, the local switch can enter the Helper mode only after neighbors pass the filtering policies of ip-prefix or acl.
    • Set ignore-external-lsa, the Helper does not check the LSAs outside the AS (AS-external LSA). By default, the Helper checks the LSAs outside the AS.
    • Set planned-only, the Helper supports only the planned-GR. By default, the Helper supports both the planned-GR and unplanned-GR.
    • Set never, the switch does not support the Helper mode.

Checking the Configuration

Run the display ospf [ process-id ] graceful-restart [ verbose ] command to check the restart status of OSPF GR.

Improving the Stability of an OSPF Network

A stable OSPF network features less route flapping, normal device performance, and good network performance.

Applicable Environment

By setting timers, you can reduce the number of unnecessary packets on networks and reduce the load on the device. Network performance is thus improved.

Pre-configuration Tasks

Before improving the security of an OSPF network, complete the following tasks:

  • Configuring a link layer protocol

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

  • Configuring Basic OSPF Functions

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Setting the Priority of OSPF

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    preference [ ase | inter | intra ] { preference | route-policy route-policy-name } *

    The priority of OSPF is set.

    • If the parameter ase is specified, it indicates that the preference of AS external routes is set.
    • inter: sets the priority of the Inter-area route.

    • intra: sets the priority of the Intra-area route.

    • The parameter preference specifies the preference of OSPF routes. The smaller the value, the higher the preference.
    • If the parameter route-policy route-policy-name is specified, it indicates that the preference is set for specified routes according to the routing policy.

    By default, the preference of OSPF routes is 10. When the parameter ase is specified, the default preference of AS external routes is 150.

  4. Run:

    commit

    The configuration is committed.

Configuring the Delay for Transmitting LSAs on the Interface

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf trans-delay interval

    The delay in transmitting LSAs is set on the interface.

    By default, the delay in transmitting LSAs is 1 second.

  5. Run:

    commit

    The configuration is committed.

Configuring the Interval for Retransmitting LSAs

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run:

    ospf timer retransmit interval

    The interval for retransmitting LSAs between adjacent switch moduless is set.

    By default, the interval for retransmitting LSAs is 5 seconds.

    NOTE:

    The interval for retransmitting LSAs between adjacent switch moduless cannot be set too small. Otherwise, certain LSAs are retransmitted unnecessarily. Generally, the interval needs to be greater than the round trip time of a packet transmitted between two switch moduless.

  5. Run:

    commit

    The configuration is committed.

Configuring Secure Synchronization

Context

When the switch moduless in an area just finish synchronizing the LSDBs, the LSDBs of these switch moduless are different from each other. As a result, route flapping occurs. You can configure secure synchronization to solve this problem. This, however, may delay the establishment of the OSPF adjacency relationship.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [process-id ]

    The OSPF view is displayed.

  3. Run:

    safe-sync enable

    Secure synchronization is configured.

  4. Run:

    commit

    The configuration is committed.

Configuring Stub Routers

Context

A stub switch modules is used to control traffic and instruct other OSPF switch moduless not to use it to forward data. Other OSPF switch moduless can have a route to the stub switch modules.

The metric of links in the Router LSAs generated by the stub switch modules is set to the maximum value (65535).

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    stub-router [ on-startup [ interval ] ]

    A stub switch modules is configured.

    The parameter on-startup [ interval ] specifies the interval during which the switch modules remains to be a stub switch modules. By default, the interval is 500 seconds.

    NOTE:

    There is no relation between the stub switch modules configured through this command and the switch modules in a stub area.

  4. Run:

    commit

    The configuration is committed.

Suppressing an Interface from Receiving or Sending OSPF Packets

Context

After an OSPF interface is set to be in the silent state, the interface can still advertise its direct routes. Hello packets on the interface, however, cannot be forwarded. Therefore, no neighbor relationship can be established on the interface. This can enhance the networking adaptability of OSPF and reduce the consumption of system resources.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    silent-interface { all | interface-type interface-number }

    The interface is suppressed from receiving or sending OSPF packets.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of improving the stability of an OSPF network are complete.

Procedure

  • Run the display ospf [ process-id ] brief command to check brief information about the specified OSPF process.
  • Run the display ip routing-table command to check information about the IP routing table.

Improving the Security of an OSPF Network

On a network demanding high security, you can configure OSPF authentication and the GTSM to improve the security of the OSPF network.

Applicable Environment

With the increase in attacks on TCP/IP networks and the defects in the TCP/IP protocol suite, network attacks have a greater impact on the network security. Especially attacks on network devices will cause the crash of the network. By configuring the GTSM and authentication, you can improve the security of an OSPF network.

The CX11x&CX31x&CX91x series switch modules support the following authentication modes:
  • Simple authentication
  • MD5 authentication
  • HMAC-MD5 authentication
  • Keychain authentication
NOTE:

The CX11x&CX31x&CX91x series switch modules supports OSPF GTSM. For detailed configuration of OSPF GTSM, refer to the CX11x&CX31x&CX710&CX91x Series Switch Modules Configuration Guide - Security

NOTE:
Pre-configuration Tasks

Before improving the security of an OSPF network, complete the following tasks:

Configuration Procedures

You can choose one or several configuration tasks (excluding "Checking the Configuration") as required.

Configuring the OSPF GTSM Functions

Context

To apply GTSM functions, enable GTSM on the two ends of the OSPF connection.

The valid TTL range of the detected packets is [255 -hops + 1, 255].

GTSM checks the TTL value of only the packet that matches the GTSM policy. For the packets that do not match the GTSM policy, you can set them as "pass" or "drop". If the GTSM default action performed on the packet is set as "drop", you need to configure all the switch modules connections for GTSM. If the packets sent from a switch modules do not match the GTSM policy, they are dropped. The connection thus cannot be established. This ensures security but reduces the ease of use.

You can enable the log function to record the information that the packets are dropped. This is convenient for fault location.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf valid-ttl-hops hops [ nonstandard-multicast ] [ vpn-instance vpn-instance-name ]

    OSPF GTSM functions are configured.

    NOTE:

    The ospf valid-ttl-hops command has two functions:

    • Enabling OSPF GTSM

    • Configuring the TTL value to be detected

    The parameter vpn-instance is valid only for the latter function.

    Thus, if the private network policy or the public network policy is configured only, it is recommended to set the default action performed on the packets that do not match the GTSM policy as pass. This prevents the OSPF packets of other processes from being discarded incorrectly.

Configuring the Area Authentication Mode

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run:

    area area-id

    The OSPF area view is displayed.

  4. Run any of the following command to configure the authentication mode of the OSPF area as required:

    • Run:

      authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]

      Simple authentication is configured for the OSPF area.

      • plain indicates the plain text password.
      • cipher indicates the cipher text password. For Message Digest 5 (MD5) or Hashed Message Authentication Code-MD5 (HMAC-MD5) authentication, the authentication mode is in cipher text by default.
    • Run:

      authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ]

      Authentication mode is configured for the OSPF area.

      • md5 indicates the MD5 cipher text authentication mode.

      • hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.
      • hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.
      • key-id specifies the ID of the authentication key.
    • Run:

      authentication-mode keychain keychain-name

      The Keychain authentication is configured for the OSPF area.

      NOTE:

      Before using the Keychain authentication, you need to configure Keychain information in the system view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm, and key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.

  5. Run:

    commit

    The configuration is committed.

Configuring the Interface Authentication Mode

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The OSPF interface view is displayed.

  3. On an Ethernet interface, run:

    undo portswitch

    The interface is switched to Layer 3 mode.

    By default, an Ethernet interface works in Layer 2 mode.

    If an Ethernet interface already has Layer 2 configuration, this command fails to be executed on the interface. Before running this command on the interface, delete all the Layer 2 configuration of the interface.

    NOTE:

    If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch these interfaces to Layer 3 mode in batches.

  4. Run any of the following commands to configure the interface authentication mode as required:

    • Run:

      ospf authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]

      Simple authentication is configured for the OSPF interface.

      • simple indicates simple authentication.
      • plain indicates the plain text password. For simple authentication, the authentication mode is in plain text by default.
      • cipher indicates the cipher text password. For MD5 or HMAC-MD5 authentication, the authentication mode is in cipher text by default.
    • Run:

      ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ]

      Authentication mode is configured for the OSPF interface.

      • md5 indicates the MD5 cipher text authentication mode.

      • hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.
      • hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.
    • Run:

      ospf authentication-mode null

      The OSPF interface is not authenticated.

    • Run:

      ospf authentication-mode keychain keychain-name

      The Keychain authentication is configured for the OSPF area.

      NOTE:

      Before using the Keychain authentication, you need to configure Keychain information in the system view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm, and key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

All configurations of improving the security of an OSPF network are complete.

Procedure

  • Run the display ospf [ process-id ] brief command to view the configurations of the system in the current view.

Configuring the Network Management Function of OSPF

OSPF supports the network management function. You can bind the OSPF MIB to a certain OSPF process.

Applicable Environment

Through the Simple Network Management Protocol (SNMP), the OSPF Management Information Base (MIB) manages multicast information exchanged between the NMS and agents.

Pre-configuration Tasks

Before configuring the network management function of OSPF, complete the following tasks:

  • Configuring a link layer protocol

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

  • Configuring Basic OSPF Functions

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospf mib-binding process-id

    The OSPF process is bound to the MIB.

  3. Run:

    commit

    The configuration is committed.

Checking the Configuration

Run the following commands to check the previous configuration.

  • Run the display ospf [ process-id ] brief command to check brief information about the binding between the OSPF process and the MIB.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59532

Downloads: 3623

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