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 OSPFv3

Configuring OSPFv3

This section describes how to configure OSPFv3.

Configuring Basic OSPFv3 Functions

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

Applicable Environment

You must enable OSPFv3 and specify the interface ,area ID and router ID before configuring other functions.

Pre-configuration Tasks

Before configuring basic OSPFv3 functions, complete the following tasks:

  • Enabling IPv6 capabilities

  • Making the network layers of the adjacent nodes accessible

Enabling OSPFv3

Context

OSPFv3 supports multiple processes. Multiple OSPFv3 processes running on one switch modules are differentiated by process IDs. OSPFv3 process ID is set when OSPFv3 is enabled and is only locally valid. It does not affect the packet exchange with other switch moduless.

In the format of an IPv4 address, a router ID is a 32-bit unsigned integer that uniquely identifies a switch modules within an AS. The router ID of OSPFv3 must be manually set. If no router ID is set, OSPFv3 fails to run normally.

When manually setting the router ID, ensure that the router IDs of any two switch moduless in an AS are different. When multiple processes are enabled on a switch modules, it is necessary to specify a unique route ID for each process.

To ensure the stable running of OSPFv3, you need to allocate router IDs and set them in network planning.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ]

    OSPFv3 is enabled and the OSPFv3 view is displayed.

  3. Run:

    router-id router-id

    A Router ID is set.

    If a router ID conflict occurs, perform either of the following operations:

    • Reconfigure a router ID.
    • Run the undo ospfv3 router-id auto-recover disable command to enable the router ID automatic recovery function. After the function is enabled, the system automatically allocates a new router ID.
      NOTE:
      • If the automatic recovery function is enabled and a router ID conflict occurs between indirectly connected switch moduleses in one OSPF area, the system replaces the conflicted router ID with a newly calculated one. The automatic recovery function takes effect on both configured and automatically generated router IDs.
      • The system can replace a router ID in a maximum of three attempts in case the router ID conflict persists.

  4. Run:

    commit

    The configuration is committed.

Enabling OSPFv3 on an Interface

Context

After enabling OSPFv3 in the system view, you need to enable OSPFv3 on the interface.

Because an interface has multiple instances, you need to specify which instance of the interface is enabled in the OSPFv3 process when OSPFv3 is enabled on the interface. If no instance ID is specified, the value defaults to 0. The same instance must be enabled on the interfaces between which the neighbor relationship is set up.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 process-id area area-id [ instance instance-id ]

    OSPFv3 is enabled on the interface.

    The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4 address format.

  5. (Optional) Run the ospfv3 network-type { broadcast | nbma | p2mp [ non-broadcast ] | p2p } [ instance instance-id ] command to configure the network type of an interface.

    NOTE:

    When an interface supports multi-instances, you must specify the value of instance-id when enabling OSPFv3 on the interface. If the value of instance-id is not specified, the default value 0 is adopted. In this case, the configured network type of an interface mismatches the actual network type of the interface. This step is mandatory in such a case.

  6. Run:

    commit

    The configuration is committed.

Entering the OSPFv3 Area View

Context

You must configure the switch moduless in the same area based on the area. Otherwise, the neighbor switch moduless cannot exchange information with each other. The congestion of routing information or routing loop is thus caused.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    area area-id

    The OSPFv3 area view is displayed.

    The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4 address format.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for the Basic OSPFv3 Functions are complete.

Procedure

  • Run the display ospfv3 [ process-id ] command to check the summary information about the OSPFv3 process.
  • Run the display ospfv3 [ process-id ] interface [ area area-id ] [ interface-type interface-number ] command to check the OSPFv3 interface information.
  • Run the commands as follow to check the LSDB information about OSPFv3:

    • display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-router-id | self-originate ] [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ] [ resolve-hostname ]

    • display ospfv3 [ process-id ] lsdb [ area area-id ] hostname hostname [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ]

  • Run the commands as follow to check the OSPFv3 routing table:

    • display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes | asbr-routes | intra-routes | inter-routes | ase-routes ] [ verbose ]

    • display ospfv3 [ process-id ] routing statistics

  • Run the display default-parameter ospfv3 command to check the default OSPFv3 configuration.

Establishing or Maintaining OSPFv3 Neighbor Relationship

By establishing and maintaining OSPFv3 neighbor relationships or adjacencies, you can build OSPFv3 networks.

Applicable Environment

In applications, establishing or maintaining the OSPFv3 neighbor relationship is a premise for the construction of an OSPFv3 network. After the configuration in this section, you can:

  • Adjust the convergence speed of the OSPFv3 network and network load posed by protocol packets by modifying OSPFv3 timers.

  • Enable OSPFv3 to be disconnected from its neighbor when the number of OSPFv3 packet retransmissions exceeds the threshold by configuring Retransmission Limitation for OSPFv3. This prevents non-stop packet retransmissions if the neighbor does not receive packets.

  • Speed up the convergence of an OSPFv3 network by adjusting the intervals for updating and receiving LSAs.

Pre-configuration Tasks

Before establishing or maintaining the OSPFv3 neighbor relationship, complete the following tasks:

Configuring the Interval for Sending Hello Packets

Context

Hello packets are periodically sent to the neighbor switch modules to detect and maintain the neighbor relationship and to elect the DR and the BDR. RFC 2328 requires that the Hello timer values of neighbors be consistent. The value of the Hello timer is inversely proportional to the route convergence speed and network load.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 timer hello interval [ instance instance-id ]

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

  5. Run:

    commit

    The configuration is committed.

Configuring Dead Time of Neighbor Relationship

Context

If a switch modules does not receive any Hello packet from its neighbor during a specified period, the neighbor switch modules is considered invalid. The specified period is called the dead time of the neighbor relationship. The dead time must be at least four times the Hello interval on an interface.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 timer dead interval [ instance instance-id ]

    The dead time of the neighbor relationship is specified.

  5. Run:

    commit

    The configuration is committed.

Configuring the Interval for Retransmitting LSAs to Neighboring switch moduless

Context

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 timer retransmit interval [ instance instance-id ]

    The interval for retransmitting LSAs to the adjacent routers is set.

    The value of seconds must be greater than a round trip of one packet transmitted between two switch moduless.

    NOTE:

    Do not set a value which is too small, for the interval between LSA retransmissions. Otherwise, unnecessary retransmissions may occur.

  5. Run:

    commit

    The configuration is committed.

Configuring the Delay for Transmitting LSAs on the Interface

Context

The LSA ages out in the LSDB of a local switch modules instead of in the transmission process. You need to set the delay for an LSA before sending it. For a low-speed network, this configuration is necessary.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 trans-delay interval [ instance instance-id ]

    The delay in transmitting LSAs on the interface is set.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for the Establishing or Maintaining OSPFv3 Neighbor Relationship are complete.

Procedure

  • Run the display ospfv3 [ process-id ] interface [ area area-id ] [ interface-type interface-number ] command to check the OSPFv3 interface information.

Configuring OSPFv3 Areas

OSPFv3 supports stub areas, the principle and applicable environment of which are similar to those in OSPFv2.

Applicable Environment

To reduce the number of LSAs in the network and enhance OSPFv3 extensibility, define OSPFv3 areas. For some non-backbone areas at the edge of ASs, you can define them as stub areas for further reducing the size of the routing table and the number of LSAs.

Pre-configuration Tasks

Before configuring OSPFv3 area attributes, complete the following tasks:

Configuring OSPFv3 Stub Areas

Context

Do as follows on each switch modules that runs OSPFv3 in the stub area:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    area area-id

    The OSPFv3 area view is displayed.

  4. Run:

    stub [ no-summary ]

    The area is configured as a stub area.

  5. (Optional) Run:

    default-cost cost

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

    By default, the cost of the default route sent to the stub area is 1.

    This command is configured on the ABR of the stub area only to set the cost of the default route to be sent to the stub area. This command does not need to be configured on other switch moduless in the stub area.

    The parameter no-summary takes effect only when the stub command is configured on the ABR. If this parameter is configured, the ABR only sends the summary-LSA of a default route to the stub area without originating other summary-LSAs. The stub area without AS-external-LSAs or Summary-LSAs is called a totally stub area.

  6. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for the OSPFv3 Areas are complete.

Procedure

  • Run the commands as follow to check the LSDB information about OSPFv3:

    • display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-router-id | self-originate ] [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ] [ resolve-hostname ]

    • display ospfv3 [ process-id ] lsdb [ area area-id ] hostname hostname [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ]

  • Run the commands as follow to check the OSPFv3 routing table:

    • display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes | asbr-routes | intra-routes | inter-routes | ase-routes ] [ verbose ]

    • display ospfv3 [ process-id ] routing statistics

Configuring OSPFv3 Route Attributes

By setting OSPFv3 route attributes, you can change OSPFv3 routing policies to meet the requirements of complex networks.

Applicable Environment

In actual applications, to meet the requirements of a complicated networking environment, you can change OSPFv3 routing policies by configuring OSPFv3 route attributes. Through the following procedures, you can:

  • Set the cost on the OSPFv3 interface.

  • Configure load balancing among equal-cost routes.

Pre-configuration Tasks

Before configuring OSPFv3 route attributes, complete the following tasks:

Setting the Cost of the OSPFv3 Interface

Context

You can control route calculation by setting the link cost of OSPFv3 on different interfaces.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 cost cost [ instance instance-id ]

    The cost is set on the OSPFv3 interface.

    By default, the link cost on an OSPFv3 interface is 1.

  5. Run:

    commit

    The configuration is committed.

Setting the Maximum Number of Equal-Cost Routes

Context

Do as follows on the switch modules that runs OSPFv3:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    maximum load-balancing number

    The maximum number of equal-cost routes is set.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for the OSPFv3 Route Attributes are complete.

Procedure

  • Run the display ospfv3 interface [ area area-id ] [ interface-type interface-number ] command to check the OSPFv3 interface information.
  • Run the commands as follow to check the LSDB information about OSPFv3:

    • display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-router-id | self-originate ] [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ] [ resolve-hostname ]

    • display ospfv3 [ process-id ] lsdb [ area area-id ] hostname hostname [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ]

  • Run the commands as follow to check the OSPFv3 routing table:

    • display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes | asbr-routes | intra-routes | inter-routes | ase-routes ] [ verbose ]

    • display ospfv3 [ process-id ] routing statistics

Controlling OSPFv3 Routing Information

This section describes how to control OSPFv3 routing information. Detailed operations include configuring route aggregation, filtering the received routes, and importing external routes.

Applicable Environment

Through the configuration in this section, you can control the advertising and receiving of OSPFv3 routing information and configure OSPFv3 to import external routes.

Pre-configuration Tasks

Before controlling OSPFv3 routing information, complete the following tasks:

Configuring OSPFv3 to Filter the Received Routes

Context

After receiving LSAs, OSPFv3 determines whether to add the calculated routes to the local routing table according to the filtering policy.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name } import

    OSPFv3 is configured to filter the imported routes.

    Using the filter-policy command, you can only filter the routes calculated by OSPFv3. Routes that do not pass the filtering are neither added to the OSPFv3 routing table nor advertised.

  4. Run:

    commit

    The configuration is committed.

Configuring OSPFv3 to Import External Routes

Context

Because OSPFv3 is a link state-based routing protocol and cannot directly filter the advertised LSAs, OSPFv3 must filter the routes when importing them. Then, only the routes that pass the filtering can be advertised.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    default { cost cost | tag tag | type type }*

    The default parameters of the imported route is set.

  4. Run:

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

    External routes are imported.

    NOTE:

    Importing IBGP routes in OSPFv3 process can lead to routing loops.

    After you run the import-route command on an OSPFv3 switch modules to import external routes, the switch modules becomes an ASBR.

  5. (Optional) Run:

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

    Default routes are advertised to the OSPFv3 route area.

  6. (Optional) Run:

    filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name } export [ protocol [ process-id ] ]

    The imported external routes are filtered.

    You can configure OSPFv3 to filter a certain type of routing information by specifying the protocol. If protocol is not specified, OSPFv3 filters all the imported routes.

    NOTE:

    The filter-policy command takes effect only on the routes imported through the import-route command by the ASBR, that is, filters the imported routes. The routes that are filtered out do not generate LSAs and cannot be advertised by OSPFv3. If the import-route command is not configured to import other external routes (including OSPFv3 routes in different processes), the filter-policy command does not takes effect.

  7. Run:

    commit

    The configuration is committed.

(Optional) Configuring OSPFv3 to Filter LSAs in an Area

Context

After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Inter-Area-Prefix LSAs) in an area, only the Type 3 LSAs that meet the filtering conditions can be received or advertised. This filters unnecessary LSAs, reduces the LSDB size, and increases network convergence.

This function is applicable only to the ABR.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 process view is displayed.

  3. Run:

    area area-id

    The OSPFv3 area view is displayed.

  4. Filter incoming or outgoing Type 3 LSAs in the area.

    • Filter incoming Type 3 LSAs in the area.

      Run the filter { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name } import command to filter incoming Type 3 LSAs in the area.

    • Filter outgoing Type 3 LSAs in the area.

      Run the filter { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name } export command to filter outgoing Type 3 LSAs in the area.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for Controlling OSPFv3 Routing Information are complete.

Procedure

  • Run the commands as follow to check the LSDB information about OSPFv3:

    • display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-router-id | self-originate ] [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ] [ resolve-hostname ]

    • display ospfv3 [ process-id ] lsdb [ area area-id ] hostname hostname [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ]

  • Run the commands as follow to check the OSPFv3 routing table:

    • display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes | asbr-routes | intra-routes | inter-routes | ase-routes ] [ verbose ]

    • display ospfv3 [ process-id ] routing statistics

Optimizing an OSPFv3 Network

By configuring OSPFv3 functions in special network environments, you can adjust and optimize the OSPFv3 network performance.

Applicable Environment

By adjusting the OSPFv3 timer, you can change the convergence speed of an OSPFv3 network and the network overload caused by protocol packets. On low-speed links, you need to consider the delay in transmitting LSAs on the interface. By adjusting the SPF calculation interval, you can mitigate resource consumption due to frequent network changes.

You can specify the DR priority of an interface to affect the DR/BDR election in a broadcast network.

Pre-configuration Tasks

Before optimizing an OSPFv3 network, complete the configuration tasks:

Configuring the SPF Timer

Context

When the OSPFv3 link state database (LSDB) changes, SPF calculation needs to be performed again. A shorter SPF calculation interval can increase the network convergence speed, but also occupies more resources. If the network changes frequently, the bandwidth may be used up. A longer SPF calculation interval occupies less resources, which prevents the bandwidth from being used up due to frequent network changes. However, the network convergence speed becomes slower in this scenario. Set the interval based on the actual network.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  • Configure an SPF normal timer.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospfv3 [ process-id ]

      The OSPFv3 view is displayed.

    3. Run:

      spf timers delay-interval hold-interval

      An SPF normal timer is configured.

    4. Run:

      commit

      The configuration is committed.

  • Configure an SPF intelligent timer.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospfv3 [ process-id ]

      The OSPFv3 view is displayed.

    3. Run:

      spf-schedule-interval { delay-interval hold-interval | intelligent-timer max-interval start-interval hold-interval-1 }

      An SPF intelligent timer is configured.

    4. Run:

      commit

      The configuration is committed.

Setting the Interval for Receiving LSAs

Context

When a network is instable, control the minimum interval for receiving the same LSA update. To prevent unnecessary LSA updates caused by network changes, by default, an intelligent timer is enabled. The interval for receiving LSAs is expressed in milliseconds. The maximum interval for updating LSAs is 1000 milliseconds (ms), the initial interval is 500 ms, and the Holdtime interval is 500 ms.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

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

    The interval for receiving LSAs is set.

  4. Run:

    commit

    The configuration is committed.

Configuring an Intelligent Timer for Generating LSAs

Context

Setting the millisecond-level interval for generating the same LSA speeds up network convergence. When a network becomes instable, reduce the interval for generating the same LSA by using an intelligent timer.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

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

    The interval interval for updating OSPFv3 LSAs by using an SPF intelligent timer is set.

    • 0 indicates that the interval for updating OSPFv3 LSAs is not set.
    • lsa-originate-max-interval specifies the maximum interval for updating LSAs. The value ranges from 1 to 10000, in milliseconds.
    • lsa-originate-start-interval specifies the initial interval for updating LSAs. The value ranges from 0 to 1000, in milliseconds.
    • hold-interval specifies the hold interval for updating LSAs. The value ranges from 1 to 5000, in milliseconds.

    By default, the maximum interval for updating LSAs is 5000ms, the initial interval for updating LSAs is 500ms, the hold interval for updating LSAs is 1000ms.

  4. Run:

    commit

    The configuration is committed.

Suppressing an Interface from Sending and Receiving OSPFv3 Packets

Context

To prevent a switch modules from advertising routes to the switch modules on a certain network and from importing the routes of other switch moduless, you can suppress the interface on which OSPFv3 is enabled from receiving and sending OSPFv3 packets.

Do as follows on the switch modules that runs OSPFv3.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 view is displayed.

  3. Run:

    silent-interface interface-type interface-number

    The interface is suppressed from sending and receiving OSPFv3 packets.

  4. Run:

    commit

    The configuration is committed.

Follow-up Procedure

Different processes can suppress the same interface from sending and receiving OSPFv3 packets, but the silent-interface command is valid only for the OSPFv3 interface on which the specified process is enabled, and does not take effect on the interface of other processes.

After an OSPFv3 interface is set to be silent, the interface can still advertise its direct routes through the Intra-Area-Prefix-LSA of the same switch modules. No OSPFv3 neighbor relationship can be set up on the interface. Therefore, the OSPFv3 adaptability is enhanced.

Configuring DR Priority of an Interface

Context

The DR priority on a switch modules interface qualifies the interface for the DR election. If the DR priority is 0, the switch modules cannot be elected as a DR or BDR.

Do as follows on the switch modules that runs OSPFv3.

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:

    ospfv3 dr-priority priority [ instance instance-id ]

    The DR priority of the interface is set.

  5. Run:

    commit

    The configuration is committed.

Follow-up Procedure

After the DR priority is changed, you can re-elect a DR or BDR through the following methods, which, however, will result in the interruption of the OSPFv3 neighbor relationship between switch moduless and therefore are used only when necessary.

  • Restarting all switch moduless.

  • Running the shutdown and undo shutdown commands on the interface on which the OSPFv3 neighbor relationship is set up.

Configuring Stub Routers

Context

A stub router is used to control traffic. It notifies OSPFv3 switch moduleses not to forward data by the stub router, but they can have a route to the stub router.

Do as follows on the switch modules that runs OSPFv3:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 process view is displayed.

  3. Run:

    stub-router [ on-startup [ interval ] ]

    The stub router is configured.

    NOTE:

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

  4. Run:

    commit

    The configuration is committed.

Ignoring MTU Check on DD Packets

Context

Do as follows on the switch modules that runs OSPFv3:

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:

    ospfv3 mtu-ignore [ instance instance-id ]

    The MTU check on DD packets is ignored.

    After the command is used, the interface does not check the MTU field of a received DD packet.

  5. Run:

    commit

    The configuration is committed.

Checking the Configuration

Prerequisites

The configurations for Optimizing an OSPFv3 Network are complete.

Procedure

  • Run the display ospfv3 interface [ area area-id ] [ interface-type interface-number ] command to check the OSPFv3 interface information.
  • Run the commands as follow to check the LSDB information about OSPFv3:

    • display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-router-id | self-originate ] [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ] [ resolve-hostname ]

    • display ospfv3 [ process-id ] lsdb [ area area-id ] hostname hostname [ { external | grace | inter-prefix | inter-router | intra-prefix | link | network | router | router-information } [ link-state-id ] ] [ age { min-value min-age-value | max-value max-age-value }* ]

  • Run the commands as follow to check the OSPFv3 routing table:

    • display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes | asbr-routes | intra-routes | inter-routes | ase-routes ] [ verbose ]

    • display ospfv3 [ process-id ] routing statistics

Configuring an OSPFv3 Dynamic Hostname

Compared with router IDs, Open Shortest Path First (OSPFv3) dynamic hostnames are easier to memorize. Therefore, using dynamic hostnames to identify routers can facilitate network management.

Pre-configuration Tasks

Before configuring a dynamic hostname, complete the following tasks:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 [ process-id ]

    The OSPFv3 process view is displayed.

  3. Run:

    hostname [ hostname ]

    An OSPFv3 dynamic hostname is configured.

    NOTE:

    If you specify hostname in hostname command, hostname is advertised as the dynamic hostname. If no hostname is specified in hostname command, the hostname specified in the sysname command is advertised as the dynamic hostname.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Run the display ospfv3 hostname-table command to check OSPFv3 hostname information.

Configuring OSPFv3 IP FRR

With OSPFv3 IP FRR, devices can rapidly switch traffic from faulty links to backup links without interrupting traffic. This protects traffic and greatly improves the reliability of OSPFv3 networks.

Applicable Environment

With the development of networks, Voice over IP (VoIP) and on-line video services require high-quality real-time transmission. Nevertheless, if an OSPFv3 fault occurs, traffic can be switched to a new link after far more than 50 ms, which does not meet the requirement for real-time services on the network.

Normally, traffic can be switched to a new link after the following processes: fault detection in milliseconds, notifying the fault to the routing control plane in milliseconds, generating and flooding new topology information in tens of milliseconds, triggering SPF calculation in tens of milliseconds, and notifying and installing a new route in hundreds of milliseconds. As a result, all the processes take far more than 50 milliseconds.

With OSPFv3 IP FRR that calculates a backup link in advance, devices can rapidly switch traffic to the backup link without interrupting services when the primary link becomes faulty. This protects traffic and thus greatly improves the reliability of OSPFv3 networks.

Pre-configuration Tasks

Before Configuring OSPFv3 IP FRR, complete the following tasks:

Procedure

  1. Enabling OSPFv3 IP FRR
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospfv3 [ process-id ]

      An OSPFv3 process is enabled, and the OSPFv3 view is displayed.

    3. Run:

      frr

      The OSPFv3 IP FRR view is displayed.

    4. Run:

      loop-free-alternate

      OSPFv3 IP FRR is enabled, and a loop-free backup link is generated.

      NOTE:

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

    5. Run:

      commit

      The configuration is committed.

  2. (Optional) Blocking FRR on an OSPFv3 Interface
    1. In system view, run:

      interface interface-type interface-number

      The view of the OSPFv3 interface running FRR is displayed.

    2. Run:

      ospfv3 frr block [ instance instance-id ]

      FRR is blocked on the OSPFv3 interface.

    3. Run:

      commit

      The configuration is committed.

Checking the Configuration

Run the display ospfv3 [ process-id ] routing verbose command to view the primary link and backup link after OSPFv3 IP FRR is enabled.

Configuring BFD for OSPFv3

To speed up OSPFv3 convergence when the link status changes, you can configure BFD for OSPFv3. 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.

Usage Scenario

To speed up OSPFv3 convergence when the link status changes, you can configure BFD for OSPFv3 links.

BFD detects links much faster than keep-alive protocols do. If OSPFv3 is bound to BFD sessions, BFD can notify OSPFv3 of link failures immediately, and then OSPFv3 perform route calculation and convergence in the new network topology.

Pre-configuration Tasks

Before configuring BFD for OSPFv3, complete the following tasks:

  • Configure basic OSPFv3 functions.

Configuration Procedures
Figure 7-62 Flowchart for configuring BFD for OSPFv3
Configuring BFD Globally

Context

On the two devices that need to establish a BFD session, you can configure BFD for all the interfaces in a certain OSPFv3 process.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 process-id

    The OSPFv3 view is displayed.

  3. Run:

    bfd all-interfaces enable

    BFD for OSPFv3 is enabled to establish a BFD session.

    By default, BFD is disabled in an OSPFv3 process.

  4. Run:

    commit

    The configuration is committed.

Configuring BFD for OSPFv3

Context

After enabling BFD for OSPFv3, you need to configure BFD parameters in the OSPFv3 process.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 process-id

    The OSPFv3 view is displayed.

  3. Run:

    bfd all-interfaces { min-transmit-interval min-transmit-value | min-receive-interval min-receive-value | detect-multiplier detect-multiplier-value }*

    OSPFv3 BFD parameters are configured.

    By default, BFD parameters are not configured in an OSPFv3 process.

  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 used in an OSPFv3 process, the following situations occur:

  • On a P2P network, all OSPFv3 interfaces whose neighbor status is Up set up dynamic BFD sessions.

  • On a broadcast network, all OSPFv3 interfaces whose neighbor status is Up set up dynamic sessions between DRs and non-DRs.

To prevent certain interfaces from setting up dynamic BFD sessions, perform the following steps on the interfaces:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. Run:

    ospfv3 bfd block

    The interface is prevented from dynamically setting up BFD sessions.

  4. Run:

    commit

    The configuration is committed.

(Optional) Configuring BFD for a Specified Interface

Context

To configure BFD only on a specified interface, or enable an interface to detect link failures faster after BFD for OSPFv3 is enabled globally, perform the following steps on the interface:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. Run:

    ospfv3 bfd enable

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

    When BFD is configured globally and the neighbor status is Full, OSPFv3 establishes BFD sessions on all the neighbors in the process using default BFD parameters.

    You can run the ospfv3 bfd { min-transmit-interval min-transmit-value | min-receive-interval min-receive-value | detect-multiplier detect-multiplier-value }* [ instance instance-id ] } command to set parameters for BFD sessions.

    NOTE:
    • The BFD configured on an interface takes precedence over that configured in a process. Specifically, if BFD is enabled on an interface, BFD parameters on the interface are used to establish BFD sessions.

    • If the parameters of a BFD session are set but the ospfv3 bfd enable command is not run, BFD cannot be enabled.

  4. Run:

    commit

    The configuration is committed.

Checking the Configurations

Procedure

  • Run the display ospfv3 [process-id ] bfd session [ interface-type interface-number ] [ neighbor-id ] [ verbose ] command to check information about the BFD session.

Configuring the OSPFv3 GR Helper

As a neighbor of the GR restarter, the GR helper can identify GR signaling. The GR helper maintains its adjacency with the GR restarter when the restarter performs the master/slave switchover, helping the restarter recover the network topology.

Context

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 the master/slave switchover and system upgrade.

NOTE:

The CX11x&CX31x&CX91x series switch modules can be configured as a GR helper rather than a GR restarter.

Pre-configuration Tasks

Before configuring OSPFv3 GR, 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 OSPFv3 Functions

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 process-id

    The OSPFv3 view is displayed.

  3. Run:

    helper-role [ { ip-prefix ip-prefix-name | acl-number acl-number | acl-name acl-name } | max-grace-period period | planned-only | lsa-checking-ignore ]*

    OSPFv3 GR is enabled.

    By default, the OSPFv3 GR helper function is disabled.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Run the display ospfv3 [ process-id ] graceful-restart-information command to view the OSPFv3 GR status.

Improving OSPFv3 Network Security

If an Open Shortest Path First version 3 (OSPFv3) network requires high security, you can configure OSPFv3 authentication to improve network security.

Context

In OSPFv3 authentication, an authentication field is added to each OSPFv3 packet for encryption. When a local device receives an OSPFv3 packet from a remote device, the local device discards the packet if the authentication password carried in the packet is different from the local one, which protects the local device against potential attacks. Therefore, OSPFv3 authentication improves network security.

Procedure

  • Configure OSPFv3 area authentication.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospfv3 [ process-id ]

      The OSPFv3 process view is displayed.

    3. Run:

      area area-id

      The OSPFv3 area view is displayed.

    4. Run:

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

      OSPFv3 area authentication is configured.

      NOTE:

      If you use OSPFv3 area authentication, the authentication and password configurations on all switch modules in the same area must be the same.

    5. Run:

      commit

      The configuration is committed.

  • Configure OSPFv3 process authentication.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      ospfv3 [ process-id ]

      The OSPFv3 process view is displayed.

    3. Run:

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

      OSPFv3 process authentication is configured.

    4. Run:

      commit

      The configuration is committed.

  • Configure OSPFv3 interface authentication.
    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:

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

      OSPFv3 interface authentication is configured.

      NOTE:

      OSPFv3 interface authentication takes precedence over OSPFv3 area authentication.

      If you use OSPFv3 interface authentication, the authentication and password configurations on all the interfaces on the same network segment must be the same.

    5. Run:

      commit

      The configuration is committed.

Configuring the Network Management Function of OSPFv3

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

Applicable Environment

OSPFv3 supports the network management function. You can bind OSPFv3 MIB and a certain OSPFv3 process. In addition, OSPFv3 also supports the trap function and the log function.

Pre-configuration Tasks

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

Configuring OSPFv3 MIB Binding

Context

When multiple OSPFv3 processes are enabled, you can configure OSPFv3 MIB to select the process to be processed, that is, that is, configure OSPFv3 MIB to select the process to which it is bound.

Do as follows on the OSPFv3 switch modules.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    ospfv3 mib-binding process-id

    OSPFv3 MIB binding OSPFv3 process is configured.

  3. Run:

    commit

    The configuration is committed.

Configuring OSPFv3 Trap

Context

Do as follows on the OSPFv3 switch modules.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    snmp-agent trap enable feature-name ospfv3 [ trap-name { ifconfigerror | ifrxbadpacket | ifstatechange | nbrrestarthelperstatuschange | ospfv3nbrstatechange } ]

    The trap function for the OSPFv3 module is enabled.

  3. Run:

    commit

    The configuration is committed.

Check the Configuration

Prerequisites

The configurations of the Network Management Function of OSPFv3 are complete.

Procedure

  • Run the display current-configuration command to check the configuration currently validated on the switch modules.
Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 58900

Downloads: 3621

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