As a network routing technology, adaptive routing enables routers to detect network-wide topology or traffic changes, and dynamically perform path selection based on the changes. This can optimize network performance, ensure packet forwarding efficiency, reduce latency, avoid congestion, and enhance the overall reliability and efficiency of the network.

Application scenario

Adaptive routing applies to the following traffic switchover scenario.

Figure 1 Application scenario

As shown in Figure 1, in the spine-leaf network architecture, east-west traffic between servers across different leaf devices must be forwarded through spine devices. In this network, multiple spine devices are deployed to enhance reliability. The spine devices, acting as route reflectors (RR), establish BGP sessions with each leaf device. The leaf devices exchange server route information through BGP route reflection. This scenario uses data exchange between Server A and Server H as an example. Leaf 1 has two paths to reach Leaf 4 (through Spine 1 and Spine 2). Each path contains two segments, namely, "local leaf to spine" and "spine to remote leaf." If the path that traverses Spine 1 is the preferred path, when this path fails, path switchover is typically performed through BGP route reselection. If the "local leaf to spine" segment (marked by callout 1 in the figure) fails, Leaf 1 can fast detect the failure for the BGP connection with Spine 1 through specific BGP settings (BFD for BGP). Leaf 1 then performs route reselection, and switch traffic to the path that traverses Spine 2. When the "spine to remote leaf" segment (marked by callout 2 in the figure) fails, Leaf 1 cannot detect directly the failure because it does not have a direct BGP connection to Leaf 4. Leaf 1 can reselect the optimal route, update the routing information, and then switch traffic destined for Leaf 4 to the path that traverses Spine 2 only after the spine device detects the link failure. Typically this path switchover process takes a long time, which might result in traffic loss.

After you enable adaptive routing, the leaf device can fast respond to link state changes across the network. Even if the link status changes (due to link down or traffic congestion) for the "spine to remote leaf" segment, the leaf device can still rapidly detect the change, calculate the optimal route, and complete the path switchover while ensuring service quality.

Adaptive routing types

You can enable adaptive routing in the following ways:

· General adaptive routing—The device can detect only the link up or down state in the network to complete traffic path switchover.

· Flexible global load balancing (FGLB) adaptive routing—The device can detect not only the link up or down state in the network, but also detect the link quality changes in the network. When the link quality deteriorates, it can switch traffic to the path with better link quality to ensure overall service quality of the network.

ARN packets

Adaptive routing introduced a new type of proprietary protocol packets, called (adaptive routing notification) ARN packets, which are advertised between spine and leaf devices. ARN packets are sent via the UDP protocol. After you enable adaptive routing, the device sends various types of ARN packets to carry different information.

Adaptive routing uses the following types of ARN packets:

· AD packets—Device ID advertisement packets used for advertising the local device ID.

· LS packets—Link state advertisement packets used to advertise the link up or down state events.

· LQ packets—Link quality advertisement packets used to advertise the link quality value that quantifies the state of the link quality. Only FGLB-mode adaptive routing supports this type of packets.

· CF packets—Congestion advertisement packets used to advertise flow table information associated with congested traffic flows. Only FGLB-mode adaptive routing supports this type of packets.

· CHG packets—Packets used by a spine device to notify leafs of device ID changes of remote leafs. Only FGLB-mode adaptive routing supports this type of packets.

· ACK packets—Used to acknowledge receipt of LS and CHG packets on the receiving end.

Among the previous types of packets, AD packets and LQ packets are sent at fixed intervals during the operation of adaptive routing. Sending of LS, CF, and CHG packets is triggered in specific conditions. A device keeps retransmitting LS and CHG packets until it receives the corresponding type of ACK packets from the peer end. Triggered CF packets will be continuously sent periodically upon traffic congestion until traffic switches to a non-congested path. If the local device ID has changed, the device immediately triggers the sending of AD packets to notify other devices of its new device ID.

Operating mechanism

Operating mechanism of FGLB adaptive routing

Figure 2 Network diagram of FGLB adaptive routing

As shown in Figure 2, FGLB adaptive routing operates as follows:

2. Each leaf device establishes EBGP connections with the two spine devices. The leaf devices advertise server route information between each other through BGP.

3. Configure load balancing on all leaf devices to implement ECMP for routes with the same prefix from Spine 1 and Spine 2.

4. After you configure the peer advertise device-id command on each leaf device, the leaf devices will advertise the device ID extended community attribute in public network unicast routes. The device ID extended community attribute is a proprietary extended community attribute that uses the configured global router ID to identify a device within an adaptive routing network.

5. Enable adaptive routing and link state information processing of FGLB adaptive routing on the leaf and spine devices globally and on the specified interfaces.

6. After you enable adaptive routing, as shown in Figure 3, both spine and leaf devices periodically send AD packets to advertise their device IDs. The spine device periodically collects quality of the link to each leaf device, and advertises LQ packets to each leaf device. Take the quality of the link between spine 1 and leaf 4 as an example. Spine 1 collects the quality of the link to Leaf 4, and advertises LQ packets to the other three leaf devices in the network. Based on the AD and LQ packets from the spine devices, the leaf devices can identify the links for which the spine devices have advertised the quality. For example, after Leaf 1 received the LQ packet forwarded by Spine 1 and the AD packet originated by Spine 1, it can identify that the ARN packet advertises the quality of the link to Leaf 4 from the Remote Device ID field. In addition, it can identify that the ARN packet advertises the quality of the link connecting Leaf 4 and Spine 1 from the My Device ID field.

Figure 3 AD and LQ packet advertisement diagram

7. Take the traffic from Leaf 1 to Leaf 4 as an example. After Leaf 1 receives the LQ packets sent from Spine 1 and Spine 2, it calculates the next hop for the BGP route originating from Leaf 4. The next hop value is determined by a specific algorithm that combines the link quality between Leaf 1 and the spine devices, as well as the link quality advertised in the LQ packets (the comprehensive value of the state of the two links along the path from Leaf 1 to Leaf 4), as shown in Figure 4. In this example, Leaf 1 receives LQ packets from both spine devices, so it calculates two next hops with different next hop device IDs but the same remote device ID.

Figure 4 BGP route next hop diagram

The link quality value of the local link on the device is calculated from the current real-time link bandwidth usage and queue depth based on the weight configured in the link-quality weight command.

8. When link congestion occurs in the forwarding path (determined automatically by the device), the following conditions occur:

¡ As shown in Figure 5, if multiple load-shared links exist between the spine and leaf devices, and only some of these links are congested, a traffic matrix dynamic flow table is generated to switch the traffic to the remaining non-congested links. The link quality value of the target link for traffic switchover cannot exceed the link quality threshold. If this condition is not met, the device does not switch traffic to that link.

NOTE:

A spine device determines whether to perform traffic switchover during traffic congestion based on the link quality threshold. The device calculates a link quality threshold based on the settings in the bandwidth high-threshold, buffer high-threshold, and link-quality weight commands, and then compares the threshold with the link quality values collected on each link.

Figure 5 Traffic switchover when load-shared links between devices are congested

9. As shown in Figure 6, if only one link exists between Spine 1 and Leaf 4, or the link quality values of all other links exceed the threshold, Spine 1 sends a CF packet to the originating leaf device of the congested traffic (Leaf 1, for example). The CF packet contains the following information:

¡ The flow table generated by the spine device based on the congested traffic, which is used to identify a congested traffic path. The key information in the flow table is the 5-tuple, including the source IP address, destination IP address, source port number, destination port number, and protocol type.

¡ The device ID of the spine device and the device ID of the peer leaf device.

Figure 6 Congestion advertisement ARN packet triggering diagram

After Leaf 1 receives the CF packet, it matches the BGP route prefix based on the destination IP address in the 5-tuple of the flow table. Then, Leaf 1 generates a dynamic traffic matrix flow table to switch the next hop for traffic destined to Leaf 4. In this flow table, the next hop corresponding to the device ID advertised in the ARN packet (the path via Spine 1 to Leaf 4). Instead, Leaf 1 selects the optimal next hop whose link quality value does not exceed the threshold from the remaining next hops with different next hop device IDs but the same remote device ID, achieving path switchover after traffic congestion, as shown in Figure 7.

Figure 7 Next hop switchover diagram

NOTE:

Fast traffic switchover upon congestion is implemented based on the BGP load balancing feature. Traffic can fast switch between the specified equal-cost paths.

10. As shown in Figure 8, when the link between Leaf 4 and Spine 1 is down, Spine 1 sends LS packets to the other three leaf devices other than Leaf 4. An LS packet contains the following information:

¡ Device ID of the remote leaf device.

¡ Information that the link between Spine 1 and Leaf 4 is down.

Figure 8 Network diagram for sending LS packets upon a link down event

After receiving the LS packets with link down information, Leaf 1, Leaf 2, and Leaf 3 locate the BGP routes carrying the device ID extended community attribute based on the device ID of Leaf 4. They then invalidate the next hops associated with these routes destined for Spine 1 in the forwarding table, and load share traffic among the remaining next hops, implementing fast path switchover upon the link failure.

NOTE:

If a traffic matrix static flow table pointing to the down link exists on the leaf device, the leaf device also invalidates that traffic matrix static flow table after receiving a link down LS packet.

In the previous procedure, if the device ID for a leaf device is changed, an AD packet is immediately triggered and sent to the spine device. Upon detecting the device ID change of that leaf device, the spine device generates a CHG packet to notify other leaf devices. The CHG packet contains the device IDs before and after the modification for the leaf device. Upon receiving the CHG packet, a leaf device immediately updates the relationship between the link quality value and device ID.

Operating mechanism of general adaptive routing

Figure 9 Network diagram of general adaptive routing

As shown in Figure 9, general adaptive routing operates as follows:

2. Each leaf device establishes EBGP connections with the two spine devices. The leaf devices advertise server route information between each other through BGP.

3. Configure load balancing on all leaf devices to implement ECMP for routes with the same prefix from Spine 1 and Spine 2.

4. After you configure the peer advertise device-id command on each leaf device, the leaf devices will advertise the device ID extended community attribute in public network unicast routes. The device ID extended community attribute is a proprietary extended community attribute that uses the global router ID to identify a device within an adaptive routing network.

5. Enable adaptive routing on the leaf and spine devices globally and on the specified interfaces.

6. After you enable adaptive routing, as shown in Figure 10, both spine and leaf devices periodically send AD packets to advertise their device IDs. The devices record the device IDs upon receiving the AD packets.

Figure 10 Network diagram for advertising AD packets

7. As shown in Figure 11, when the link between Leaf 4 and Spine 1 is down, Spine 1 sends LS packets to the other three leaf devices other than Leaf 4. An LS packet contains the following information:

¡ Device ID of the remote leaf device.

¡ Information that the link between Spine 1 and Leaf 4 is down.

Figure 11 Network diagram for sending LS packets upon a link down event

NOTE:

Adaptive routing tasks at a glance

To configure adaptive routing, perform the following tasks:

1. Enabling adaptive routing:

¡ Enabling FGLB adaptive routing

¡ Enabling general adaptive routing

2. Establishing a BGP IPv4 or IPv6 unicast session

3. (Optional.) Configuring a global router ID

4. (Optional.) Configuring ARN packet parameters

5. (Optional.) Optimizing adaptive routing performance

¡ Configuring the report threshold for local link quality fluctuations

¡ Configuring the delay timer for the device to generate a traffic matrix dynamic flow entry

Enabling FGLB adaptive routing

About this task

To enable FGLB adaptive routing, you must first enable adaptive routing globally and for the specified interface.

The link quality value of a device is determined by the following parameters:

· Bandwidth usage—Bandwidth usage refers to the ratio of the used bandwidth of a specific link to the maximum bandwidth supported by that link.

· Queue depth—Queue depth refers to the number of data packets waiting in the buffer queue.

The device uses the previous parameters in combination with the specified weights to calculate the following values:

· Link quality value—The link quality value of the local link on a device is calculated from the real-time bandwidth usage and queue depth based on the weight configured in the link-quality weight command. Additionally, the spine device can advertise the collected link quality values (for links to leaf devices) to leaf devices through LQ packets.

· Link quality threshold—The device determines whether to perform traffic switchover during traffic congestion based on the link quality threshold. The device calculates a link quality threshold based on the settings in the bandwidth high-threshold, buffer high-threshold, and link-quality weight commands, and then compares the threshold with the link quality values collected on each link. When multiple load-shared links exist between the spine and leaf devices, and some of these links experience traffic congestion (determined automatically by the device), the device generates a traffic matrix dynamic flow table to switch traffic to the remaining non-congested links. The link quality value of the target link for traffic switchover cannot exceed the link quality threshold. If this condition is not met, the device does not switch traffic to that link. If only one link exists between the spine and leaf devices, or the link quality values of all other links connected to the leaf devices from the spine device exceed the threshold, the spine device triggers the sending of CF packets to notify the originating leaf device of the traffic to switch traffic to another spine device.

Restrictions and guidelines

If you execute the activate mod command in UFA instance view of the unified flow analytics (UFA) feature, the device cannot identify whether the traffic matching the UFA instance is congested, and cannot perform fast path switchover for the traffic via flow table deployment. To avoid this issue, do not configure the activate mod command.

For more information about the UFA feature, see NetAnalysis in Network Management and Monitoring Command Reference.

Procedure

1. Enter system view.

system-view

2. Enable adaptive routing globally and enter adaptive routing view.

adaptive-routing enable

By default, adaptive routing is disabled globally.

3. Enable FGLB adaptive routing globally.

flexible-global-loadbalance [ ls-advertise ]

By default, FGLB adaptive routing is disabled.

In the FGLB adaptive routing architecture, you must specify the ls-advertise keyword on the spine devices. The ls-advertise keyword is not required on the leaf devices.

4. (Optional.) Configure the intervals for sending ARN packets for link quality advertisement.

advertise link-quality interval interval-value

By default, ARN packets for link quality advertisement are sent every 5 seconds.

5. (Optional.) Configure the link quality parameters.

¡ Configure the upper threshold for the bandwidth usage level.

bandwidth high-threshold high-threshold-value

By default, the upper threshold for the bandwidth usage level is 1.

¡ Configure the upper threshold for the queue depth level.

buffer high-threshold high-threshold-value

By default, the upper threshold for the queue depth level is 1.

¡ Configure the calculation weights for the link quality parameters.

link-quality weight { bandwidth bandwidth-weight | buffer buffer-weight } *

By default, the bandwidth usage and queue depth calculation weights are both 100.

6. Return to system view.

quit

7. Enter interface view.

interface interface-type interface-number

8. Enable adaptive routing for the interface.

adaptive-routing detect

By default, adaptive routing is disabled for an interface.

9. Return to system view.

quit

10. Enable the device to identify link congestion.

a. Enable unified flow analytics and enter unified flow analytics view.

netanalysis unified-flow

b. Set the delay threshold for the hardware flow table.

hardware-flow delay-threshold threshold-value

c. Create a UFA instance and enter its view.

instance instance-id name instance-name

d. Configure a rule to match all IP traffic for the UFA instance.

flow any-ip

e. Enable flow analysis for the UFA instance.

activate flow-analysis

The device can identify link congestion only after you configure this step. You can configure this step on both the leaf and spine devices.

For more information about the command, see NetAnalysis in Network Management and Monitoring Command Reference.

Enabling general adaptive routing

About this task

To enable general adaptive routing, you only need to enable adaptive routing globally and for the specified interface.

Procedure

1. Enter system view.

system-view

2. Enable adaptive routing globally and enter adaptive routing view.

adaptive-routing enable

By default, adaptive routing is disabled globally.

3. Return to system view.

quit

4. Enter interface view.

interface interface-type interface-number

5. Enable adaptive routing for the interface.

adaptive-routing detect

By default, adaptive routing is disabled for an interface.

Establishing a BGP IPv4 or IPv6 unicast session

About this task

In an adaptive routing network, you must establish an EBGP IPv4 or IPv6 unicast session between a spine device and a leaf device, and enable the spine and leaf devices to advertise the device ID extended community attribute via BGP IPv4 or IPv6 unicast routes.

The device ID extended community attribute is an H3C-proprietary attribute. For interoperability purposes, you can use the extcommunity-type device-id command to change the type value for the device ID extended community attribute to a value that can be identified by other vendors.

Configuring a spine device

1. Enter system view.

system-view

2. Enable a BGP instance for establishing an EBGP IPv4 or IPv6 unicast session with the leaf device.

For more information, see BGP configuration in Layer 3—IP Routing Configuration Guide.

3. Enter BGP instance view.

bgp as-number [ instance instance-name ]

4. (Optional.) Configure the type value for the device ID extended community attribute.

extcommunity-type device-id device-type-value

By default, the type value for the device ID extended community attribute is 84ef in hexadecimal format.

5. Enter BGP IPv4 unicast address family view or BGP IPv6 unicast address family view.

¡ Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

¡ Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

6. Enable load balancing and set the maximum number of BGP ECMP routes for load balancing.

balance [ ebgp | eibgp | ibgp ] number [ ecmp-nexthop-local | ecmp-nexthop-unchanged ]

By default, load balancing is disabled.

7. (Optional.) Enable BGP to ignore the AS_PATH attribute when it implements load balancing.

balance as-path-neglect

By default, BGP does not ignore the AS_PATH attribute when it implements load balancing.

8. Enable BGP to advertise the device ID extended community attribute to the leaf device.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise device-id

By default, BGP does not advertise the device ID extended community attribute to a peer or peer group.

9. Enable BGP to advertise the extended community attribute to the leaf device.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-ext-community

By default, BGP does not advertise the extended community attribute to a peer or peer group.

For more information about this command, see Layer 3—IP Routing Command Reference.

Configuring a leaf device

1. Enter system view.

system-view

2. Enable a BGP instance for establishing a BGP IPv4 or IPv6 unicast session with the spine device.

For more information, see BGP configuration in Layer 3—IP Routing Configuration Guide.

3. Enter BGP instance view.

bgp as-number [ instance instance-name ]

4. (Optional.) Configure the type value for the device ID extended community attribute.

extcommunity-type device-id device-type-value

By default, the type value for the device ID extended community attribute is 84ef in hexadecimal format.

5. Enter BGP IPv4 unicast address family view or BGP IPv6 unicast address family view.

¡ Enter BGP IPv4 unicast address family view.

address-family ipv4 [ unicast ]

¡ Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

6. Enable load balancing and set the maximum number of BGP ECMP routes for load balancing.

balance [ ebgp | eibgp | ibgp ] number [ ecmp-nexthop-local | ecmp-nexthop-unchanged ]

By default, load balancing is disabled.

7. (Optional.) Enable BGP to ignore the AS_PATH attribute when it implements load balancing.

balance as-path-neglect

By default, BGP does not ignore the AS_PATH attribute when it implements load balancing.

8. Enable BGP to advertise the device ID extended community attribute to the spine device.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise device-id

By default, BGP does not advertise the device ID extended community attribute to a peer or peer group.

9. Enable BGP to advertise the extended community attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise-ext-community

By default, BGP does not advertise the extended community attribute to a peer or peer group.

For more information about this command, see Layer 3—IP Routing Command Reference.

Configuring a global router ID

About this task

After you enable adaptive routing, the device will advertise the configured global router ID as its device ID. You can perform this task to edit the global router ID.

Procedure

1. Enter system view.

system-view

2. Configure a global router ID.

router id router-id

By default, if no global router ID is configured, the device selects a router ID as follows:

If loopback interfaces configured with IP addresses exist, the device uses the highest loopback interface IP address as the router ID.

If no loopback interface configured with an IP address exists, the device uses the highest IP address of other interfaces as the router ID, regardless of the interface state (up or down).

If no IP address is configured for any interface, the router ID is 0.0.0.0. BGP cannot use router ID 0.0.0.0 for session establishment, because the router ID is invalid.

For more information about this command, see Layer 3—IP Routing Command Reference.

Configuring ARN packet parameters

Configuring the ARN packet sending interval

About this task

Adaptive routing requires the peer end to acknowledge the sent ARN packets. If no acknowledgment packets are received, the device will retransmit the ARN packets at the specified intervals.

Procedure

1. Enter system view.

system-view

2. Enter adaptive routing view.

adaptive-routing enable

3. Configure the ARN packet sending interval.

adaptive-routing interval interval-value

By default, the ARN packet sending interval is 500 milliseconds.

Configuring the source and destination UDP port numbers for ARN packets

Restrictions and guidelines

You must specify the UDP port numbers as the same value for the devices that receive and send ARN packets.

Procedure

1. Enter system view.

system-view

2. Enter adaptive routing view.

adaptive-routing enable

3. Configure the source and destination UDP port numbers for ARN packets.

adaptive-routing udp-port port-number

By default, the source and destination UDP port numbers for ARN packets are both 4780.

Configuring the source IPv4 address for ARN packets

Procedure

1. Enter system view.

system-view

2. Enter adaptive routing view.

adaptive-routing enable

3. Configure the source IPv4 address for ARN packets.

adaptive-routing udp-source-ip ipv4-address

By default, the source IPv4 address for ARN packets is 1.1.1.1.

Optimizing adaptive routing performance

Configuring the report threshold for local link quality fluctuations

About this feature

In an adaptive routing network, traffic path switchover decisions are made based on calculated link quality values. By default, the device driver reports the link quality value of the local interface to the adaptive routing module at fixed intervals. In dynamic network environments, link quality values might change frequently. If the values are not updated in time, the calculation results of the adaptive routing module might be different from the actual link conditions, resulting in traffic path switchover errors.

To address the previous issues, the device introduced a real-time local link quality report and update mechanism. When the percentage change in the link quality value of the local interface exceeds the report threshold specified in this feature, the device driver immediately reports the most recent link quality value to the adaptive routing module. This mechanism ensures that the adaptive routing module can perform correct calculations based on current link conditions, enhancing the stability and accuracy of traffic path switchover.

Procedure

1. Enter system view.

system-view

2. Enter adaptive routing view.

adaptive-routing enable

3. Set the report threshold for local link quality fluctuations.

link-quality fluctuation-threshold threshold-value

By default, the report threshold for local link quality fluctuations is 10%.

Configuring the delay timer for the device to generate a traffic matrix dynamic flow entry

About this feature

If multiple load-shared links exist between the spine and leaf devices, and only some links are congested, the device that detects the congestion generates a traffic matrix dynamic flow entry to switch the traffic to the remaining uncongested links.

This feature delays generation of the traffic matrix dynamic flow entry by the device to prevent incorrect traffic switchover caused by transient link fluctuations, ensuring stable link operation and accurate data transmission.

Procedure

1. Enter system view.

system-view

2. Enter adaptive routing view.

adaptive-routing enable

3. Configure the delay timer for the device to generate a traffic matrix dynamic flow entry.

adaptive-routing dynamic-flow delay delay-value

By default, the device generates a traffic matrix dynamic flow entry upon detecting congestion to guide traffic switchover.

Display and maintenance commands for adaptive routing

Execute display commands in any view.

Task	Command
Display device ID-to-interface mapping information.	display adaptive-routing device status [ device-id ]
Display information about the flow table on the device.	display adaptive-routing flow ipv4
Display statistics of the flow table on the device.	display adaptive-routing flow statistics
Display the link quality values collected by the device.	display adaptive-routing link-quality [ device-id ]

Adaptive routing configuration examples

Example: Configuring basic FGLB adaptive routing

Network configuration

Leaf 1 resides in AS 10, Spine 1 resides in AS 20, Spine 2 resides in AS 30, and Leaf 2 resides in AS 40. Spine 1 and Spine 2 establish EBGP connections with Leaf 1 and Leaf 2, respectively.

Configure FGLB adaptive routing to enable Leaf 1 and Leaf 2 to detect link quality and state changes of the entire backbone in real time, and perform fast traffic path switchover.

Figure 12 Network diagram

‌

Procedure

1. Configure IP addresses for interfaces. (Details not shown.)

2. Configure Spine 1:

# Configure a global router ID, and enable adaptive routing and FGLB adaptive routing globally and on the specified interfaces.

<Spine1> system-view

[Spine1] router id 2.2.2.2

[Spine1] adaptive-routing enable

[Spine1-adaptive-routing] flexible-global-loadbalance ls-advertise

[Spine1-adaptive-routing] quit

[Spine1] interface hundredgige 1/1/1

[Spine1-HundredGigE1/1/1] adaptive-routing detect

[Spine1-HundredGigE1/1/1] quit

[Spine1] interface hundredgige 1/1/2

[Spine1-HundredGigE1/1/2] adaptive-routing detect

[Spine1-HundredGigE1/1/2] quit

# Configure BGP.

[Spine1] bgp 20

[Spine1-bgp-default] router-id 2.2.2.2

[Spine1-bgp-default] peer 11.1.1.2 as-number 10

[Spine1-bgp-default] peer 12.1.1.2 as-number 40

[Spine1-bgp-default] address-family ipv4 unicast

[Spine1-bgp-default-ipv4] peer 11.1.1.2 enable

[Spine1-bgp-default-ipv4] peer 12.1.1.2 enable

[Spine1-bgp-default-ipv4] peer 11.1.1.2 advertise device-id

[Spine1-bgp-default-ipv4] peer 12.1.1.2 advertise device-id

[Spine1-bgp-default-ipv4] peer 11.1.1.2 advertise-ext-community

[Spine1-bgp-default-ipv4] peer 12.1.1.2 advertise-ext-community

[Spine1-bgp-default-ipv4] quit

[Spine1-bgp-default] quit

# Enable the device to identify link congestion.

[Spine1] netanalysis unified-flow

[Spine1-netanalysis-unified-flow] hardware-flow delay-threshold 400

[Spine1-netanalysis-unified-flow] instance 1 name FGLB

[Spine1-netanalysis-instance-1] flow any-ip

[Spine1-netanalysis-instance-1] activate flow-analysis

[Spine1-netanalysis-instance-1] quit

[Spine1-netanalysis-unified-flow] quit

3. Configure Spine 2:

# Configure a global router ID, and enable adaptive routing and FGLB adaptive routing globally and on the specified interfaces.

<Spine2> system-view

[Spine2] router id 3.3.3.3

[Spine2] adaptive-routing enable

[Spine2-adaptive-routing] flexible-global-loadbalance ls-advertise

[Spine2-adaptive-routing] quit

[Spine2] interface hundredgige 1/1/1

[Spine2-HundredGigE1/1/1] adaptive-routing detect

[Spine2-HundredGigE1/1/1] quit

[Spine2] interface hundredgige 1/1/2

[Spine2-HundredGigE1/1/2] adaptive-routing detect

[Spine2-HundredGigE1/1/2] quit

# Configure BGP.

[Spine2] bgp 30

[Spine2-bgp-default] router-id 3.3.3.3

[Spine2-bgp-default] peer 21.1.1.2 as-number 10

[Spine2-bgp-default] peer 22.1.1.2 as-number 40

[Spine2-bgp-default] address-family ipv4 unicast

[Spine2-bgp-default-ipv4] peer 21.1.1.2 enable

[Spine2-bgp-default-ipv4] peer 22.1.1.2 enable

[Spine2-bgp-default-ipv4] peer 21.1.1.2 advertise device-id

[Spine2-bgp-default-ipv4] peer 22.1.1.2 advertise device-id

[Spine2-bgp-default-ipv4] peer 21.1.1.2 advertise-ext-community

[Spine2-bgp-default-ipv4] peer 22.1.1.2 advertise-ext-community

[Spine2-bgp-default-ipv4] quit

[Spine2-bgp-default] quit

# Enable the device to identify link congestion.

[Spine2] netanalysis unified-flow

[Spine2-netanalysis-unified-flow] hardware-flow delay-threshold 400

[Spine2-netanalysis-unified-flow] instance 1 name FGLB

[Spine2-netanalysis-instance-1] flow any-ip

[Spine2-netanalysis-instance-1] activate flow-analysis

[Spine2-netanalysis-instance-1] quit

[Spine2-netanalysis-unified-flow] quit

4. Configure Leaf 1:

# Configure a global router ID, and enable adaptive routing and FGLB adaptive routing globally and on the specified interfaces.

<Leaf1> system-view

[Leaf1] router id 1.1.1.1

[Leaf1] adaptive-routing enable

[Leaf1-adaptive-routing] flexible-global-loadbalance

[Leaf1-adaptive-routing] quit

[Leaf1] interface hundredgige 1/1/1

[Leaf1-HundredGigE1/1/1] adaptive-routing detect

[Leaf1-HundredGigE1/1/1] quit

[Leaf1] interface hundredgige 1/1/2

[Leaf1-HundredGigE1/1/2] adaptive-routing detect

[Leaf1-HundredGigE1/1/2] quit

# Configure BGP.

[Leaf1] bgp 10

[Leaf1-bgp-default] router-id 1.1.1.1

[Leaf1-bgp-default] peer 11.1.1.1 as-number 20

[Leaf1-bgp-default] peer 21.1.1.1 as-number 30

[Leaf1-bgp-default] address-family ipv4 unicast

[Leaf1-bgp-default] balance 2

[Leaf1-bgp-default] balance as-path-neglect

[Leaf1-bgp-default-ipv4] peer 11.1.1.1 enable

[Leaf1-bgp-default-ipv4] peer 21.1.1.1 enable

[Leaf1-bgp-default-ipv4] peer 11.1.1.1 advertise device-id

[Leaf1-bgp-default-ipv4] peer 21.1.1.1 advertise device-id

[Leaf1-bgp-default-ipv4] peer 11.1.1.1 advertise-ext-community

[Leaf1-bgp-default-ipv4] peer 21.1.1.1 advertise-ext-community

[Leaf1-bgp-default-ipv4] network 10.1.1.0 24

[Leaf1-bgp-default-ipv4] quit

[Leaf1-bgp-default] quit

5. Configure Leaf 2:

# Configure a global router ID, and enable adaptive routing and FGLB adaptive routing globally and on the specified interfaces.

<Leaf2> system-view

[Leaf2] router id 4.4.4.4

[Leaf2] adaptive-routing enable

[Leaf2-adaptive-routing] flexible-global-loadbalance

[Leaf2-adaptive-routing] quit

[Leaf2] interface hundredgige 1/1/1

[Leaf2-HundredGigE1/1/1] adaptive-routing detect

[Leaf2-HundredGigE1/1/1] quit

[Leaf2] interface hundredgige 1/1/2

[Leaf2-HundredGigE1/1/2] adaptive-routing detect

[Leaf2-HundredGigE1/1/2] quit

# Configure BGP.

[Leaf2] bgp 40

[Leaf2-bgp-default] router-id 4.4.4.4

[Leaf2-bgp-default] peer 12.1.1.1 as-number 20

[Leaf2-bgp-default] peer 22.1.1.1 as-number 30

[Leaf2-bgp-default] address-family ipv4 unicast

[Leaf2-bgp-default] balance 2

[Leaf2-bgp-default] balance as-path-neglect

[Leaf2-bgp-default-ipv4] peer 12.1.1.1 enable

[Leaf2-bgp-default-ipv4] peer 22.1.1.1 enable

[Leaf2-bgp-default-ipv4] peer 12.1.1.1 advertise device-id

[Leaf2-bgp-default-ipv4] peer 22.1.1.1 advertise device-id

[Leaf2-bgp-default-ipv4] peer 12.1.1.1 advertise-ext-community

[Leaf2-bgp-default-ipv4] peer 22.1.1.1 advertise-ext-community

[Leaf2-bgp-default-ipv4] network 10.2.1.0 24

[Leaf2-bgp-default-ipv4] quit

[Leaf2-bgp-default] quit

05-Layer 3—IP Routing Configuration Guide

Adaptive routing tasks at a glance

About this task

Procedure

About this task

Procedure

About this task

Configuring a spine device

Configuring a leaf device

About this task

Procedure

About this task

Procedure

Procedure

Procedure

About this feature

Procedure

About this feature

Procedure

Network configuration

Procedure

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us