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 13

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).
TRILL Configuration

TRILL Configuration

Configuring Basic TRILL Functions

Enabling TRILL Globally

Context

When configuring the TRILL protocol, enable TRILL globally and then configure other TRILL features. To facilitate maintenance and management, you can configure the following additional TRILL functions:
  • Admin VLAN: allows administrators to manage routing bridges (RBs) using remote login.
  • Network entity title (NET) or dynamic host name: TRILL uses the MAC address of each RB as its system ID by default, and the MAC address is difficult to memorize.
  • Nickname: identifies an RB and is automatically generated by default. To prevent nickname conflicts and facilitate check and management, you can manually set a nickname for an RB.
  • Port mode: There are four port types for RBs. Based on the RB roles in the network, you can configure specified types for all RB ports to improve the network service efficiency.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    trill

    TRILL is enabled globally and the TRILL view is displayed.

  3. Run:

    carrier-vlan carrier-vlanid

    The carrier VLAN ID is specified.

    A created VLAN cannot be configured as the carrier VLAN.

  4. (Optional) Run:

    network-entity net

    The NET is configured.

    The NET must be unique on the network. If the NETs conflict, route flapping may occur. Therefore, the parameter should be planned before you perform the operations.

  5. (Optional) Run:

    nickname nicknamevalue [ priority priorityvalue ] [ root-priority rootpriorityvalue ]

    The nickname, priority, and root priority is configured.

    On the TRILL network, manually changing the nickname of a device will interrupt running services temporarily. Therefore, confirm your action before changing the nickname.

    The nickname must be unique on the network. If nicknames conflict, the TRILL protocol performs the following operations:
    • If a configured nickname conflicts with a generated nickname, the RB with a lower priority generates a new nickname.
    • If a configured nickname conflicts with another configured nickname, the nickname of the RB with a lower priority is suppressed, and is not advertised to the network.

  6. (Optional) Run:

    port-mode { access | hybrid | p2p | trunk }

    The port mode is configured.

    By default, the port mode is p2p. The port mode configuration rules are as follows:
    • When a port is located at the edge of a TRILL network to connect to a user VLAN, the port mode is access.
    • When a port is located in the middle of a TRILL network to transmit TRILL packets, the port mode is trunk.
    • On a P2P network, the mode of the port between two RBs is p2p.
    • If you require that a port should connect to a user VLAN and transmit TRILL packets, the port mode is hybrid.

    If the port mode is configured to hybrid in a stack, the interface may fail to forward packets. Therefore, the hybrid mode is not recommended.

  7. (Optional) If an RB is located at the edge of a TRILL network to connect to a server and the TRILL network, configure a CE VLAN as follows:

    1. Run the quit command to exit from the TRILL view.

    2. Run the vlan vlan-id command to create a VLAN and enter the VLAN view.

    3. Run the quit command to exit from the VLAN view.

    4. Run the trill command to enter the TRILL view.

    5. Run the ce-vlan { vlan-id1 [ to vlan-id2 ] } & <1-10> command to specify a CE VLAN for the TRILL process.

      The CE VLAN must have been created using the vlan command and must be different from the carrier VLAN.

  8. (Optional) Run:

    trill-name symbolic-name

    The TRILL dynamic host name mapping is configured and the host name is set for the local device.

    After this command is executed, the host name symbolic-name is advertised to other devices in the domain in LSP packets. When you check TRILL information using the related display commands on other devices, if the dynamic host name mapping is also configured on these devices, the system ID is replaced with symbolic-name.

  9. (Optional) To facilitate management on the TRILL network, configure the admin VLAN for an RB as follows:

    1. Run the quit command to exit from the TRILL view.

    2. Run the vlan vlan-id command to create a VLAN and enter the VLAN view.

    3. Run the quit command to exit from the VLAN view.

    4. Run the trill command to enter the TRILL view.

    5. Run the admin-vlan vlan-id command to specify the admin VLAN ID for the TRILL process.

      The admin VLAN must have been created using the vlan command and must be different from the carrier VLAN.

    6. Run the quit command to exit from the TRILL view.

    7. Run the interface vlanif vlan-id command to create a VLANIF interface and enter the interface view.

    8. Run the ip address ip-address { mask | mask-length } [ sub ] command to configure an IP address for the VLANIF interface.

      The IP address of the VLANIF interface must be on the same network segment as the IP address of the network edge device to ensure that the nickname is reachable.

  10. Run:

    commit

    The configuration is committed.

Enabling TRILL on an Interface

Context

After TRILL is enabled globally, TRILL neighbor relationships are not established between the RBs, and TRILL must be enabled on interfaces.

TRILL can be enabled only on trunk or hybrid interfaces. An access or dot1q-tunnel interface can only function as a user access interface and cannot run TRILL.

There are four port modes of TRILL, and the default port mode is p2p. Different port modes can be configured for interfaces of different roles based on their network locations, which reduces the number of packets processed by the interfaces and saves system resources.

In a broadcast network, the DRB communicates with each device on the network. Therefore, the DRB must have high performance. You can configure proper DRB priorities for interfaces to enable a high-performance device to be elected as the DRB.

An interface can establish neighbor relationships with at most one 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:

    port link-type { hybrid | trunk }

    The link type of the interface is set to hybrid or trunk.

  4. Run:

    trill enable [ port-mode { access | hybrid | p2p | trunk } ]

    The TRILL function is enabled and the port mode is configured on the interface.

    • By default, the port mode is p2p. The port mode configuration rules are as follows:
      • When a port is located at the edge of a TRILL network to connect to a user VLAN, the port mode is access.
      • When a port is located in the middle of a TRILL network to transmit TRILL packets, the port mode is trunk.
      • On a P2P network, the mode of the port between two RBs is p2p.
      • If you require that a port should connect to a user VLAN and transmit TRILL packets, the port mode is hybrid.
    • If the port mode is configured to hybrid in a stack, the interface may fail to forward packets. Therefore, the hybrid mode is not recommended.

    • When the stack and TRILL functions are both enabled on the device, if LAG is configured on the interface at the TRILL network access side, the LAG load balancing module only supports load balancing based on MAC addresses of user packets.

  5. (Optional) Run:

    trill drb-priority priority

    The DRB priority of the interface is configured.

    By default, the DRB priority of an interface is 64. If you want to configure the local RB as a DRB, set the priority of the local RB to a large value.

  6. Run:

    commit

    The configuration is committed.

(Optional) Configuring a Link Cost for a TRILL Interface

Context

Because TRILL uses the Shortest Path First (SPF) algorithm to calculate routing tables, the link cost is crucial to TRILL route selection. Adjusting link costs of TRILL interfaces directly affects route selection. The following link costs take effect on a TRILL interface in ascending order of priority:
  • Automatically calculated link cost: The default calculation formula is as follows: Link cost of a TRILL interface = Bandwidth reference value/Interface bandwidth. You can change the bandwidth reference value to adjust the link cost of an interface.
  • Global link cost: Configure a link cost for all TRILL interfaces on a specified RB.
  • Interface link cost: Configure the link cost for a specified interface.

Procedure

  • Adjusting the automatically calculated link cost
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      bandwidth-reference value

      The bandwidth reference value is adjusted.

    4. Run:

      commit

      The configuration is committed.

  • Configuring a global link cost
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      circuit-cost { cost | maximum }

      A global link cost is configured.

    4. Run:

      commit

      The configuration is committed.

  • Configuring an interface link cost
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill cost { cost | maximum }

      The link cost for the specified interface is configured.

    4. Run:

      commit

      The configuration is committed.

Checking the Configuration

Procedure

  • Run the display trill interface [ verbose ] command to view information about the TRILL-enabled interfaces.
  • Run the display trill lsdb [ verbose ] command to view the LSDB.
  • Run the display trill peer [ verbose ] command to view information about TRILL neighbors.
  • Run the display trill route [ nickname ] command to view information about TRILL unicast routes.
  • Run the display trill name-table command to view information about TRILL dynamic host names.
  • Run the display trill mroute [ vlan-id ] command to view information about TRILL multicast routes.

Adjusting TRILL Route Selection

Pre-configuration Task

Before adjusting TRILL route selection, complete the following task:

Configuration Procedure

You can choose one or more configuration tasks as required.

Specifying a DVLAN

Context

To combine or separate TRILL networks, configure multiple carrier VLANs in a TRILL network. However, only one carrier VLAN is responsible for forwarding TRILL data packets. Therefore, a VLAN must be selected from these carrier VLANs to forward TRILL data packets. The DRB can specify a carrier VLAN as the designated VLAN (DVLAN), but the specified VLAN may not meet the network planning requirement. In this case, you can specify the DVLAN based on the network requirement. Only the DVLAN is responsible for forwarding TRILL data.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. Run:

    trill designated-vlan vlan-id

    A DVLAN is specified.

    Make sure that the specified DVLAN is a TRILL carrier VLAN.

  4. Run:

    commit

    The configuration is committed.

Configuring TRILL Load Balancing

Context

On large-scale TRILL networks, multiple equal-cost routes destined for the same node may exist. In this situation, traffic is forwarded randomly, which may result in traffic imbalance and poor traffic management. To resolve this issue, enable the equal-cost routes to load-balance the traffic, which can improve link utilization and prevent congestion.

Load balancing can be configured for a TRILL process or interface, and the load balancing configured for an interface takes precedence over that configured for a process.
  • To configure load balancing for a TRILL process, you need to specify the maximum number of equal-cost routes for load balancing.
  • To configure load balancing for a TRILL interface, you can designate an RB as an AF for a VLAN or VLANs. After an RB is designated as an AF for a VLAN or VLANs, the RB is always used as an AF by the VLAN or VLANs, and all the RBs in other VLANs are designated as AFs based on the AF priority in order for load balancing.

Procedure

  • Configure load balancing for a TRILL process.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      maximum load-balance number

      The maximum number of equal-cost routes for load balancing is configured.

      After the command is run, traffic is load-balanced among a maximum of the configured number of equal-cost routes.

      By default, TRILL supports load balancing, and the maximum number of equal-cost routes for load balancing is 32.

      If equal-cost routes available outnumber number specified in the command, TRILL selects number equal-cost routes in the following sequence:
      • Routes with smaller outbound interface indexes
      • Routes whose next hop RBs have smaller system IDs

    4. Run:

      commit

      The configuration is committed.

  • Configure load balancing for a TRILL interface.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill load-balance systemid vlan { vlan-id1 [ to vlan-id2 ] }&<1–10>

      The RB whose system ID is the specified systemid is designated as an AF for the specified VLAN or VLANs.

      The value of vlan-id2 must be greater than that of vlan-id1.

    4. Run:

      commit

      The configuration is committed.

Configuring an Overload Bit for an RB

Context

If an RB on a TRILL network fails or needs to be upgraded or maintained, you can configure an overload bit for it. After an overload bit is configured for the RB, the RB is isolated from the TRILL network temporarily so that other devices no longer forward traffic to the RB, which prevents traffic interruptions.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    trill

    The TRILL view is displayed.

  3. Run:

    set-overload [ on-startup [ timeout1 ] [ send-sa-bit [ timeout2 ] ] ] max-reachable-cost

    The RB is enabled to send LSPs whose overload bit is 1 and routes whose cost is the maximum link cost allowed (16777214).

    timeout1 specifies the period during which the RB stays in the overload state. The default value is 600s.

    If send-sa-bit is specified in the command, the SA bit carried in Hello packets sent by the RB is 1 so that neighbors of the RB will not advertise the neighbor relationship with the RB to others after receiving the Hello packets. timeout2 specifies the period during which the SA bit carried in Hello packets sent by the RB stays at 1. The default value is 30s.

  4. Run:

    commit

    The configuration is committed.

Enabling TRILL Multicast Group-based Pruning

Context

On a TRILL network, an RB calculates a multicast distribution tree (MDT) to forward multicast or broadcast traffic. If the MDT has more than one next hop, the RB replicates the traffic and forwards one copy to each next hop. As a result, each next hop needs to process the traffic on receiving it, wasting bandwidth and forwarding resources.

To address this issue, TRILL provides multicast group-based pruning to ensure that an RB forwards traffic only to the next hop in the same multicast group. This function improves bandwidth efficiency.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    trill

    The TRILL view is displayed.

  3. Run:

    multicast-group prune enable

    TRILL multicast group-based pruning is enabled.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Procedure

  • Run the display trill interface [ interface-type interface-number | verbose ] command to view information about TRILL interfaces.
  • Run the display trill route [ nickname ] command to view information about TRILL unicast routes.

Adjusting the TRILL Network Convergence Speed

Pre-configuration Task

Before adjusting the TRILL network convergence speed, complete the following task:

Configuration Procedure

You can choose one or more configuration tasks as required.

Configuring the Interval for Detecting Neighboring Device Faults

Context

Connection status between a TRILL device and its neighboring devices can be monitored by exchanging Hello packets at intervals. A neighboring device is considered Down if the TRILL device does not receive any Hello packets from the neighboring device within the specified period (called the holding time). The device fault then triggers routing table recalculation, and the TRILL network reconverges. To speed up fault detection, use the following methods to accelerate the speed of detecting TRILL neighboring device faults:

Procedure

  • Setting an interval at which Hello packets are sent
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill timer hello hello-interval

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

      By default, Hello packets are sent on the interface every 10 seconds.

    4. Run:

      commit

      The configuration is committed.

  • Setting the holding time for TRILL neighboring devices
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill timer holding-multiplier number

      The multiplier between the expiration time of TRILL neighboring devices and the Hello packet sending interval is configured to determine the holding time for the TRILL neighboring devices.

      By default, a TRILL neighboring device is considered Down after failing to receive three Hello packets.

    4. Run:

      commit

      The configuration is committed.

Adjusting SNP and LSP Attributes

Context

When the network status changes, LSPs are sent to advertise these changes on TRILL networks, and SNPs are responsible for synchronizing the LSDB of each device on the network. You can adjust SNP and LSP attributes based on the actual network status to improve the network performance and reliability. The following table describes the SNP and LSP attributes.
Table 10-6 SNP and LSP attributes

Attribute

Description

Default Setting

Interval for sending CSNPs

All devices on a TRILL network periodically send CSNPs through the DRB to synchronize the LSDBs. After the interval for sending CSNPs is adjusted based on the network scale, the LSDBs can be synchronized in real time and CSNPs are not frequently sent to occupy a large amount of the device memory.

10 seconds

LSP intelligent timer

In the TRILL network, if the local routing information changes, the device generates a new LSP to notify this change. Many new LSPs caused by frequent routing information changes will occupy a large number of system resources. The LSP intelligent timer can automatically adjust the delay based on the change frequency of routing information, which accelerates the network convergence speed and does not affect the system performance.

The intelligent timer provides three parameters. The parameter functions are as follows:
  • If only max-interval is configured, the intelligent timer functions as an ordinary one-time triggering timer and TRILL generates LSPs at a specified interval.

  • If max-interval and init-interval are configured, init-interval determines the delay in LSP generation for the first time, and from the second time on, max-interval determines the delay in LSP generation. After the delay remains at the value specified by max-interval for three times or the TRILL process is restarted, the delay restores to the value specified by init-interval.

  • If max-interval, init-interval, and incr-interval are configured, init-interval determines the delay in LSP generation for the first time, and incr-interval determines the delay in generating the LSPs with the same ID for the second time. From the third time on, the delay in generating an LSP increases twice every time until the delay reaches the value specified by max-interval. After the delay remains at the value specified by max-interval for three times or the TRILL process is restarted, the delay restores to the value specified by init-interval.

  • max-interval: 2 seconds
  • init-interval: 0 milliseconds
  • incr-interval: 0 milliseconds

LSP refresh interval

When the network status changes, LSPs are sent to advertise these changes to other devices on the network. Based on the network scale, a long LSP refresh interval may delay the real-time change synchronization and a short interval may result in frequent LSP update and much memory occupation. After the LSP refresh interval is adjusted, the network can converge in real time and a proper number of LSPs are sent.

By default, the LSP refresh interval is 900s, and the maximum lifetime of an LSP is 1200s. Ensure that the LSP refresh interval is more than 300s shorter than the maximum LSP lifetime. This allows new LSPs to reach all routers in an area before existing LSPs expire.

Maximum LSP lifetime

The maximum LSP lifetime determines how long LSPs exist on the device. An LSP is deleted if the device does not receive the updated one after the maximum LSP lifetime expires. If the maximum LSP lifetime is set to an excessively short period, the device may discard the original LSPs when receiving new ones, which results in the failure of LSDB synchronization on the network. If the maximum LSP lifetime is set to an excessively long period, the LSDB cannot be updated in real time when the network status changes, which decreases the network convergence speed.

1200 seconds

Minimum interval at which LSPs are sent

When there are a large number of LSPs on the device, multiple LSPs are sent each time at a specified interval. This attribute defines the minimum interval at which LSPs are sent. If the minimum interval is set to an excessively short period or there are too many LSPs to be sent each time, the network resources are occupied. Therefore, the device must be configured to send all LSPs equally based on the actual network load capability.

50 milliseconds

Interval at which LSPs are retransmitted over a P2P link

On a P2P network, the devices on the two ends of the link synchronize the LSDBs through LSP flooding. The device on one end sends an LSP; the device on the other end receives the LSP and replies with a PSNP. If the sending device does not receive the PSNP from the peer within a certain period, it resends the LSP.

If the retransmission interval is set to an excessively short period, LSPs are retransmitted improperly, which results in high CPU, memory and bandwidth usage.

5 seconds

Procedure

  • Setting an interval at which CSNPs are sent
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill timer csnp csnp-interval

      The interval for sending CSNPs is set on the interface.

    4. Run:

      commit

      The configuration is committed.

  • Configuring the LSP intelligent timer
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      timer lsp-generation max-interval [ init-interval [ incr-interval ] ]

      The intelligent timer used for generating LSPs is configured.

    4. Run:

      commit

      The configuration is committed.

  • Setting the LSP refresh interval
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      timer lsp-refresh refresh-time

      The LSP refresh interval is set.

    4. Run:

      commit

      The configuration is committed.

  • Setting the maximum LSP lifetime
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      trill

      The TRILL view is displayed.

    3. Run:

      timer lsp-max-age age-time

      The maximum lifetime is set for LSPs.

    4. Run:

      commit

      The configuration is committed.

  • Setting the minimum interval at which LSPs are sent
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill timer lsp-throttle throttleinterval [ count countnumber ]

      The minimum interval for sending LSPs is set.

    4. Run:

      commit

      The configuration is committed.

  • Setting an interval at which LSPs are retransmitted over a P2P link
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The interface view is displayed.

    3. Run:

      trill timer lsp-retransmit retransmit-interval

      The interval for retransmitting LSPs over a P2P link is set.

    4. Run:

      commit

      The configuration is committed.

Setting the SPF Calculation Interval

Context

When the network status changes, TRILL calculates routes using the SPF algorithm to ensure accuracy. However, when the network status is unstable, frequent SPF calculation consumes excessive CPU resources, affecting services.

To solve this problem, configure an intelligent timer to control the SPF calculation interval. That is, set the SPF calculation interval to a small value to speed up TRILL route convergence, and set the interval to a large value after the TRILL network becomes stable.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    trill

    The TRILL view is displayed.

  3. Run:

    timer spf max-interval [ init-interval [ incr-interval ] ]

    The SPF intelligent timer is configured.

    Specify the parameters based on the following rules:
    • If you only specify max-interval, the intelligent timer functions as an ordinary timer, and TRILL performs SPF calculation after routes are converged and max-interval expires.

    • If you specify both max-interval and init-interval, init-interval determines the delay in SPF calculation for the first time, and from the second time on, max-interval determines the delay in SPF calculation. After the delay remains at the value specified by max-interval for three times or the TRILL process is restarted, the delay restores to the value specified by init-interval.

    • If you specify max-interval, init-interval, and incr-interval, init-interval determines the delay in SPF calculation for the first time, and incr-interval determines the delay in SPF calculation for the second time. From the third time on, the delay in SPF calculation increases twice every time until the delay reaches the value specified by max-interval. After the delay remains at the value specified by max-interval for three times or the TRILL process is restarted, the delay restores to the value specified by init-interval.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Procedure

  • Run the display trill interface verbose command to view detailed information about TRILL interfaces.

Configuring the Association Between STP/RSTP/MSTP and TRILL

Context

As shown in Figure 10-30, TRILL runs on RB1 to RB6, and the servers communicate through the TRILL network. MSTP runs on MS1 to MS3 to avoid loops. On this network, a loop may also occur on RB1, RB3, RB4, MS1, and MS2. However, RB1 does not support MSTP. In this situation, you may run MSTP on RB3 and RB4, and configure RB3 and RB4 to simulate the same root bridge. That is, the bridge protocol data units (BPDUs) sent by RB3 and RB4 must have the same bridge ID. In addition, MSTP blocks an interface on either of RB3 or RB4 to eliminate the loop among RB1, RB3, RB4, MS1, and MS2 after performing the spanning tree calculation. In most cases, each device has a unique bridge MAC address, and therefore the bridge IDs of devices are different. You can configure the same bridge MAC address for RB3 and RB4 to ensure that they have the same bridge ID.

In Figure 10-30, MSTP blocks the MS3 interface connecting to MS2 and the MS2 interface connecting to MS1, and the traffic from Server1 to Server3 is forwarded along the following path: Server1 -> MS3 -> MS1 -> RB3 -> RB1 -> RB5 -> Server3.

Figure 10-30 Networking of the association between STP/RSTP/MSTP and TRILL (with normal links)

In Figure 10-31, if the link between MS1 and MS3 fails, MSTP recalculates the spanning tree, blocks the MS3 interface connecting to MS1, and unblocks the MS3 interface connecting to MS2. All devices, including those on the TRILL network and connected networks, must be notified of the topology change and update their MAC address entries and ARP entries accordingly. However, devices on the TRILL network cannot process topology change (TC) packets generated by MSTP. To allow TRILL devices to process TC packets and ensure uninterrupted traffic forwarding, configure the association between MSTP and TRILL. In Figure 10-31, MSTP blocks the MS3 interface connecting to MS1, and the traffic from Server1 to Server3 is forwarded along the following path: Server1 -> MS3 -> MS2 -> RB4 -> RB1 -> RB5 -> Server3.

Figure 10-31 Networking of the association between STP/RSTP/MSTP and TRILL (with a faulty link)

Pre-configuration Tasks

Before configuring the association between STP/RSTP/MSTP and TRILL, complete the following tasks:

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    stp bridge-address mac-address

    The bridge MAC address for spanning tree calculation is configured on RB3 and RB4.

    By default, a device uses its MAC address as the bridge MAC address to calculate the spanning tree.

    • A bridge ID identifies a device. If two devices send packets with the same bridge ID to another device, the packets are considered to be sent by one device. Exercise caution when you run the stp bridge-address command.

    • After you run the stp bridge-address command to configure the same bridge MAC address for two devices, to allow the devices to simulate the same root bridge, ensure that the devices have the same spanning tree protocol configurations, such as the device priority and timer settings.

  3. Run:

    stp tc-notify trill vlan vlan-id

    The association between STP/RSTP/MSTP and TRILL is enabled on RB3 and RB4.

    By default, the association between STP/RSTP/MSTP and TRILL is disabled.

    vlan-id must be ID of an admin VLAN on the TRILL network. A VLANIF interface must be configured for the admin VLAN.

    Before the stp tc-notify trill vlan vlan-id command is configured on the device, the stp disable command must be configured on the interface configured with the trill enable port-mode { hybrid | p2p | trunk } command.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Run the display current-configuration command to view the bridge MAC address involved in spanning tree calculation and check whether the association between STP/RSTP/MSTP and TRILL is enabled.

Configuring TRILL Network Dual-Homing Through an E-Trunk

Eth-Trunk provides board-level reliability, whereas E-Trunk provides device-level reliability.

Pre-configuration Tasks

Before configuring TRILL network dual-homing through an E-Trunk, Configuring Basic TRILL Functions.

Configuring a DFS Group

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dfs-group group-id

    A DFS group is configured, and the DFS group view is displayed.

  3. Run:

    peer-nickname nickname-value

    A nickname is configured for the peer RB in a TRILL active-active scenario.

    Before configuring a nickname for the peer RB in a TRILL active-active scenario, configure a nickname for the local RB.

  4. (Optional) Run:

    pseudo-nickname nickname-value [ priority priority ]

    A pseudo nickname are configured for the RB.

    In a TRILL active-active scenario, configure the same pseudo nickname for the two RBs. Therefore, the CE considers that it accesses the TRILL network through only one RB.

    Configuring the same pseudo nickname for the RBs through which a CE is dual-homed to access a TRILL network is recommended. If different pseudo nicknames are configured, the pseudo nickname with a higher priority takes effect.

  5. (Optional) Run:

    authentication-mode hmac-sha256 cipher cipher-key

    An authentication and a password are configured for the DFS group.

    Configuring an authentication and a password for the DFS group improves E-Trunk and TRILL negotiation security in a TRILL network dual-homing scenario.

  6. Run:

    commit

    The configuration is committed.

Configuring an E-Trunk

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    e-trunk e-trunk-id

    An E-Trunk is configured, and the E-Trunk view is displayed.

    Two RBs in a TRILL active-active scenario must be configured with the same E-Trunk.

  3. Run:

    dfs-group group-id

    The E-Trunk is associated with a DFS group.

  4. Run:

    quit

    Return to the system view.

  5. (Optional) Configure E-Trunk parameters.

    To ensure reliable communication through the E-Trunk, configure proper parameters for it.

    The Link Aggregation Control Protocol (LACP) system priority of an E-Trunk member interface (Eth-Trunk interface) is called an LACP E-Trunk system priority, and the LACP system ID of an E-Trunk member interface is called an LACP E-Trunk system ID.

    If an E-Trunk consists of Eth-Trunk interfaces in static or dynamic LACP mode, LACP E-Trunk system priorities are used to determine the LACP Actor from the two ends of an Eth-Trunk link. The end with a smaller LACP E-Trunk system priority value functions as the Actor. After the Actor selects active interfaces from its local Eth-Trunk member interfaces, the other end selects its local Eth-Trunk member interfaces that are directly connected to the active interfaces of the Actor as active interfaces.

    If both the LACP E-Trunk system priority and LACP E-Trunk system ID are configured and Eth-Trunk interfaces in static or dynamic LACP mode are added to an E-Trunk, the Eth-Trunk interfaces use the LACP E-Trunk system priority.

    If the two ends of an Eth-Trunk link have the same LACP E-Trunk system priority, the end with the smaller LACP E-Trunk system ID functions as the LACP Actor.

    • Configure E-Trunk parameters in the system view.

      Configure one or more of the E-Trunk parameters listed in Table 10-7 as required.

      Table 10-7 E-Trunk parameters

      E-Trunk Parameters

      Command

      Description

      LACP E-Trunk system ID

      lacp e-trunk system-id mac-address

      The RBs on which the E-Trunk is configured must use the same LACP E-Trunk system ID.

      By default, the system MAC address is used as the LACP E-Trunk system ID.

      LACP E-Trunk system priority

      lacp e-trunk priority priority

      The RBs on which the E-Trunk is configured must use the same LACP E-Trunk system priority.

      By default, the LACP E-Trunk system priority is 32768.

    • Configure E-Trunk parameters in the E-Trunk view.

      1. Run the e-trunk e-trunk-id command to enter the E-Trunk view.
      2. Configure one or more of the E-Trunk parameters listed in Table 10-8 as required.

        Table 10-8 E-Trunk parameters

        E-Trunk Parameters

        Command

        Description

        E-Trunk priority

        priority priority

        E-Trunk priorities determine the master/backup status of the devices in an E-Trunk. The smaller the E-Trunk priority value, the higher the priority. If two devices have the same E-Trunk priority, the device with a smaller system ID functions as the master device.

        By default, the E-Trunk priority is 100.

        E-Trunk description

        description description

        The E-Trunk description may contain the name of the remote device to facilitate maintenance.

        By default, no E-Trunk description is configured.

        E-Trunk authentication

        authentication-mode { hmac-sha196 | hmac-sha256 }

        By default, the E-Trunk authentication and encryption mode is HMAC-SHA196. To improve system security, run the authentication-mode command to set the E-Trunk authentication and encryption mode to HMAC-SHA256.

  6. Run:

    commit

    The configuration is committed.

Adding an Eth-Trunk Interface to an E-Trunk

Context

Currently, Eth-Trunk interfaces in manual load balancing mode or static or dynamic LACP mode can be added to an E-Trunk.

Figure 10-32 TRILL network dual-homing through an E-Trunk

In Figure 10-32, an E-Trunk is deployed between RB1 and RB2, and the two RBs connect to the access side through Eth-Trunks. The working mode of the server (switch) determines the Eth-Trunk configurations of the two RBs.

  • Eth-Trunk interfaces working in manual load balancing mode on RBs

    Configure Ethernet operation, administration and maintenance (OAM) to implement link-level reliability. In such a scenario, Ethernet OAM also needs to be configured on each RB.

  • Eth-Trunk interfaces working in static or dynamic LACP mode on RBs

    Configure Eth-Trunk interfaces in static or dynamic LACP mode on the switch and add switches' interfaces that are connected to RBs to the Eth-Trunk interface to implement link-level reliability.

    If Eth-Trunk interfaces in manual load balancing mode are added to an E-Trunk, packet loss lasts for a long time when one RB restarts and user traffic is switched back to the RB for forwarding. Therefore, you are advised to add Eth-Trunk interfaces in static or dynamic LACP mode to an E-Trunk.

    If the link through which RB1 is uplink connected to the TRILL network fails, RB1 discards all received user traffic because no uplink outbound interface is available. You can configure a monitor-link to associate the uplink and downlink interfaces of RB1. When the uplink outbound interface of RB1 becomes Down, the downlink interface also becomes Down. Then user traffic will not be forwarded or discarded by RB1. For details about the monitor-link configuration, see Configuring Uplink and Downlink Interfaces in a Monitor Link Group.

The E-Trunk is transparent to the switch.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface eth-trunk trunk-id

    An Eth-Trunk interface is created, and the Eth-Trunk interface view is displayed.

  3. Run:

    mode { lacp-dynamic | lacp-static | manual [ load-balance ] }

    A working mode is configured for the Eth-Trunk interface.

  4. Run:

    e-trunk e-trunk-id [ remote-eth-trunk eth-trunk-id ]

    The Eth-Trunk interface is added to the specified E-Trunk.

    One Eth-Trunk interface can be added to only one E-Trunk.

  5. Run:

    commit

    The configuration is committed.

Checking the Configurations

Prerequisites

TRILL network dual-homing through an E-Trunk has been configured.

Before you check correct statistics about packets transmitted through an E-Trunk over a period, run the reset e-trunk packet-statistics command to clear the current statistics.

Procedure

  • Run the display e-trunk etrunk-id command to check E-Trunk configurations.

Improving TRILL Network Security

Pre-configuration Task

Before configuring TRILL authentication, complete the following task:

Configuration Procedure

You can choose one or more configuration tasks as required.

Configuring TRILL Packet Authentication

Context

In most cases, RBs do not encapsulate authentication information into TRILL packets before sending them or authenticate received TRILL packets. Therefore, networks are open to attacks. To improve network security, configure TRILL authentication.

In TRILL packet authentication, LSPs and SNPs carry authentication information. After receiving the packets, the remote RB authenticates them and discards those that fail the authentication.

RBs in the same area must share the same authentication mode and password so that TRILL packets can be properly flooded. Whether packets pass the authentication does not affect the establishment of neighbor relationships.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    trill

    The TRILL view is displayed.

  3. Run:

    area-authentication-mode { { simple | md5 | hmac-sha256 key-id key-id } { [ cipher ] password-key | plain password } | keychain keychain-name } [ snp-packet { authentication-avoid | send-only } | all-send-only ]

    The LSP authentication is configured.

    The authentication involves the following situations:

    • The RB encapsulates the authentication information into LSPs and SNPs to be sent and checks whether the received packets pass authentication. The RB then discards the packets that do not pass the authentication. In this case, the parameter snp-packet all-send-only does not need to be configured.

    • The RB encapsulates authentication information into LSPs to be sent and checks whether the received LSPs pass the authentication. The RB neither encapsulates the SNPs to be sent with authentication information nor checks whether the received SNPs pass the authentication. In this case, the parameter snp-packet authentication-avoid needs to be specified.

    • The RB encapsulates the LSPs and SNPs to be sent with authentication information; however, it checks the authentication result of only the received LSPs, not SNPs. In this case, the parameter snp-packet send-only needs to be configured.

    • The RB encapsulates the LSPs and SNPs to be sent with authentication information, but does not check whether the received LSPs or SNPs pass the authentication. In this case, the parameter all-send-only needs to be specified.

    If keychain authentication is used, the encryption algorithm must be configured to HMAC-MD5 algorithm.

  4. Run:

    commit

    The configuration is committed.

Configuring TRILL Interface Authentication

Context

In TRILL interface authentication, authentication information is configured on a TRILL interface, and Hello packets sent through the interface are encapsulated with the information. Only the authenticated Hello packets can be received.

If TRILL interface authentication is configured on both ends, they must share the same authentication mode and password so that neighbor relationships can be established between them.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. Run:

    trill authentication-mode { { simple | md5 | hmac-sha256 key-id key-id } { [ cipher ] password-key | plain password } | keychain keychain-name } [ send-only ]

    The authentication mode and password are configured on the interface.

    • Configure send-only if the TRILL interface needs to encapsulate authentication information into Hello packets to be sent and does not need to check whether the received packets pass the authentication.

    • Do not configure send-only if the TRILL interface needs to encapsulate authentication information into Hello packets to be sent and check whether the received packets pass the authentication. In addition, configure the same authentication information for all TRILL interfaces in the same VLAN to ensure normal communication.

    If keychain authentication is used, the encryption algorithm must be configured to HMAC-MD5 algorithm.

  4. Run:

    commit

    The configuration is committed.

Checking the Configuration

Procedure

  • Run the display trill lsdb verbose command to view the verbose LSDB information.
Translation
Download
Updated: 2019-12-13

Document ID: EDOC1000041694

Views: 60909

Downloads: 3623

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