Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 04-Track configuration | 232.92 KB |
Contents
Restrictions and guidelines: Track configuration
Collaboration application example
Associating the Track module with a detection module
Associating Track with interface management
Associating Track with route management
Associating Track with a tracked list
Associating Track with a Boolean list
Associating Track with a percentage threshold list
Associating Track with a weight threshold list
Associating the Track module with an application module
Prerequisites for associating the Track module with an application module
Associating Track with static routing
Display and maintenance commands for Track
Example: Configuring static routing-Track-NQA collaboration
Example: Configuring static routing-Track-LLDP collaboration
Configuring Track
About Track
Collaboration mechanism
The Track module collaborates with detection modules and application modules.
As shown in Figure 1, collaboration is enabled when you associate the Track module with a detection module and an application module, and it operates as follows:
1. The detection module probes specific objects such as interface status, link status, network reachability, and network performance, and informs the Track module of detection results.
2. The Track module sends the detection results to the application module.
3. When notified of changes for the tracked object, the application modules can react to avoid communication interruption and network performance degradation.
Figure 1 Collaboration through the Track module
Collaboration between the Track module and a detection module
The detection module sends the detection result of the tracked object to the Track module. The Track module changes the status of the track entry as follows:
· If the tracked object operates correctly, the state of the track entry is Positive. For example, the track entry state is Positive in one of the following conditions:
¡ The target interface is up.
¡ The target network is reachable.
· If the tracked object does not operate correctly, the state of the track entry is Negative. For example, the track entry state is Negative in one of the following conditions:
¡ The target interface is down.
¡ The target network is unreachable.
· If the detection result is invalid, the state of the track entry is NotReady. For example, the track entry state is NotReady if its associated NQA operation does not exist.
Collaboration between the Track module and an application module
Supported detection modules
The following detection modules can be associated with the Track module:
· NQA.
· CFD.
· Interface management.
· Route management.
· LLDP.
You can also associate a track entry with a list of objects called a tracked list. The state of a tracked list is determined by the states of all objects in the list. The following types of tracked lists are supported:
· Boolean AND list—The state of a Boolean AND list is determined by the states of the tracked objects using the Boolean AND operation.
· Boolean OR list—The state of a Boolean OR list is determined by the states of the tracked objects using the Boolean OR operation.
· Percentage threshold list—The state of a percentage threshold list is determined by comparing the percentage of Positive and Negative objects in the list with the percentage thresholds configured for the list.
· Weight threshold list—The state of a weight threshold list is determined by comparing the weight of Positive and Negative objects in the list with the weight thresholds configured for the list.
Supported application modules
The following application modules can be associated with the Track module:
· Static routing.
· Embedded Automation Architecture (EAA).
· Ethernet Ring Protection Switching (ERPS).
· Power over Ethernet (PoE).
Restrictions and guidelines: Track configuration
When configuring a track entry for an application module, you can set a notification delay to avoid immediate notification of status changes.
When the delay is not configured and the route convergence is slower than the link state change notification, communication failures occur.
Collaboration application example
The following is an example of collaboration between NQA, Track, and static routing.
Configure a static route with next hop 192.168.0.88 on the device. If the next hop is reachable, the static route is valid. If the next hop becomes unreachable, the static route is invalid. For this purpose, configure NQA-Track-static routing collaboration as follows:
1. Create an NQA operation to monitor the accessibility of IP address 192.168.0.88.
2. Create a track entry and associate it with the NQA operation.
¡ When next hop 192.168.0.88 is reachable, NQA sends the result to the Track module. The Track module sets the track entry to Positive state.
¡ When the next hop becomes unreachable, NQA sends the result to the Track module. The Track module sets the track entry to Negative state.
3. Associate the track entry with the static route.
¡ When the track entry is in Positive state, the static routing module considers the static route to be valid.
¡ When the track entry is in Negative state, the static routing module considers the static route to be invalid.
Track tasks at a glance
To implement the collaboration function, establish associations between the Track module and detection modules, and between the Track module and application modules.
To configure the Track module, perform the following tasks:
1. Associating the Track module with a detection module
¡ Associating Track with interface management
¡ Associating Track with route management
2. Associating Track with a tracked list
¡ Associating Track with a Boolean list
¡ Associating Track with a percentage threshold list
¡ Associating Track with a weight threshold list
3. Associating the Track module with an application module
¡ Associating Track with static routing
Associating the Track module with a detection module
Associating Track with NQA
About this task
NQA supports multiple operation types to analyze network performance and service quality. For example, an NQA operation can periodically detect whether a destination is reachable, or whether a TCP connection can be established.
An NQA operation operates as follows when it is associated with a track entry:
· If the consecutive probe failures reach the specified threshold, the NQA module notifies the Track module that the tracked object has malfunctioned. The Track module then sets the track entry to Negative state.
· If the specified threshold is not reached, the NQA module notifies the Track module that the tracked object is operating correctly. The Track module then sets the track entry to Positive state.
For more information about NQA, see Network Management and Monitoring Configuration Guide.
Restrictions and guidelines
If you associate a track entry with a nonexistent NQA operation or reaction entry, the state of the track entry is NotReady.
Procedure
1. Enter system view.
system-view
2. Create a track entry, associate it with an NQA reaction entry, and enter its view.
track track-entry-number nqa entry admin-name operation-tag reaction item-number
3. Set the delay for notifying the application module of track entry state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the track entry state changes.
Associating Track with interface management
About this task
The interface management module monitors the link status or network-layer protocol status of interfaces. The associated Track and interface management operate as follows:
· When the link or network-layer protocol status of the interface changes to up, the interface management module informs the Track module of the change. The Track module sets the track entry to Positive state.
· When the link or network-layer protocol status of the interface changes to down, the interface management module informs the Track module of the change. The Track module sets the track entry to Negative state.
Procedure
1. Enter system view.
system-view
2. Create a track entry, associate it with interface management, and enter its view.
¡ Create a track entry to monitor the link status of an interface.
track track-entry-number interface interface-type interface-number
¡ Create a track entry to monitor the physical status of an interface.
track track-entry-number interface interface-type interface-number physical
¡ Create a track entry to monitor the network layer protocol status of an interface.
track track-entry-number interface interface-type interface-number protocol { ipv4 | ipv6 }
3. Set the delay for notifying the application module of track entry state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the track entry state changes.
Associating Track with route management
About this task
The route management module monitors route entry changes in the routing table. The associated Track and route management operate as follows:
· Monitor the specified route entry:
¡ If the route entry exists in the routing table, the route management module informs the Track module. The Track module then sets the track entry to Positive state.
¡ When the route entry is removed from the routing table, the route management module informs the Track module of the change. The Track module then sets the track entry to Negative state.
· Monitor the number of ECMP routes associated with the specified route entry:
¡ When the number of ECMP routes is within the specified range, the route management module informs the Track module. The Track module then sets the track entry to Positive state.
¡ When the number of ECMP routes is out of the specified range, the route management module informs the Track module. The Track module then sets the track entry to Negative state.
Procedure
1. Enter system view.
system-view
2. Create a track entry, associate it with a route entry, and enter its view.
track track-entry-number ip route ipv4-address { mask-length | mask } reachability }
3. Set the delay for notifying the application module of track entry state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the track entry state changes.
Associating Track with LLDP
About this task
The LLDP module detects neighbor availability and informs the detection result to the Track module. The associated Track and LLDP operate as follows:
· When the neighbor is available, the Track module sets the track entry to Positive state.
· When the neighbor is unavailable, the Track module sets the track entry to Negative state.
For more information about LLDP, see Layer 2—LAN Switching Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Create a track entry, associate it with an LLDP interface, and enter its view.
track track-entry-number lldp neighbor interface interface-type interface-number
3. Set the delay for notifying the application module of track entry state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the track entry state changes.
Associating Track with a tracked list
Associating Track with a Boolean list
About this task
A Boolean list is a list of tracked objects based on a Boolean logic. It can be further divided into the following types:
· Boolean AND list—A Boolean AND list is set to the Positive state only when all objects are in Positive state. If one or more objects are in Negative state, the tracked list is set to the Negative state.
· Boolean OR list—A Boolean OR list is set to the Positive state if any object is in Positive state. If all objects are in Negative state, the tracked list is set to the Negative state.
Procedure
1. Enter system view.
system-view
2. Create a Boolean tracked list and enter its view.
track track-entry-number list boolean { and | or }
3. (Optional.) Set the delay for notifying the application module of tracked list state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the tracked list state changes.
4. Add the track entry as an object to the tracked list.
object track-entry-number [ not ]
By default, a tracked list does not contain any objects.
Repeat this step to add all interested objects to the tracked list.
Associating Track with a percentage threshold list
About this task
A percentage threshold list uses a percentage threshold to measure the state of the list.
· If the percentage of Positive objects is equal to or above the positive state threshold, the list is set to the Positive state.
· If the percentage of Positive objects is equal to or below the negative state threshold, the list is set to the Negative state.
· The state of a percentage threshold list remains unchanged if the percentage of Positive objects is below the positive state threshold and above the negative state threshold.
Procedure
1. Enter system view.
system-view
2. Create a percentage threshold list and enter its view.
track track-entry-number list threshold percentage
3. (Optional.) Set the delay for notifying the application module of tracked list state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the tracked list state changes.
4. Add the track entry as an object to the tracked list.
object track-entry-number
By default, a tracked list does not contain any objects.
Repeat this step to add all interested objects to the tracked list.
5. Configure the threshold values used to determine the state of the percentage threshold list.
threshold percentage { negative negative-threshold | positive positive-threshold } *
By default, the negative state threshold is 0% and the positive state threshold is 1%.
Associating Track with a weight threshold list
About this task
A weight threshold list uses a weight threshold to measure the state of the list.
· If the total weight of Positive objects is equal to or above the positive state threshold, the list is set to the Positive state.
· If the total weight of Positive objects is equal to or below the negative state threshold, the list is set to the Negative state.
· The state of a weight threshold list remains unchanged if the total weight of Positive objects is below the positive state threshold and above the negative state threshold.
Procedure
1. Enter system view.
system-view
2. Create a weight threshold list and enter its view.
track track-entry-number list threshold weight
3. (Optional.) Set the delay for notifying the application module of tracked list state changes.
delay { negative negative-time | positive positive-time } *
By default, the Track module notifies the application module immediately when the tracked list state changes.
4. Add the track entry as an object to the tracked list.
object track-entry-number [ weight weight ]
By default, a tracked list does not contain any objects.
Repeat this step to add all interested objects to the tracked list.
5. Configure the threshold values used to determine the state of the weight threshold list.
threshold weight { negative negative-threshold | positive positive-threshold } *
By default, the negative state threshold is 0 and the positive state threshold is 1.
Associating the Track module with an application module
Before you associate the Track module with an application module, make sure the associated track entry has been created.
Prerequisites for associating the Track module with an application module
Create a track entry first before you associate it with an application module.
An application module might obtain incorrect track entry status information if the associated track entry does not exist.
For more information about the Track and application module collaboration commands, see the command reference of the associated application module.
Associating Track with static routing
About this task
A static route is a manually configured route to route packets. For more information about static route configuration, see Layer 3—IP Routing Configuration Guide.
Static routes cannot adapt to network topology changes. Link failures or network topological changes can make the routes unreachable and cause communication interruption.
To resolve this problem, configure another route to back up the static route. When the static route is reachable, packets are forwarded through the static route. When the static route is unreachable, packets are forwarded through the backup route.
To check the accessibility of a static route in real time, associate the Track module with the static route.
If you specify the next hop but not the output interface when configuring a static route, you can configure the static routing-Track-detection module collaboration. This collaboration enables you to verify the accessibility of the static route based on the track entry state.
· If the track entry is in Positive state, the following conditions exist:
¡ The next hop of the static route is reachable.
¡ The configured static route is valid.
· If the track entry is in Negative state, the following conditions exist:
¡ The next hop of the static route is not reachable.
¡ The configured static route is invalid.
· If the track entry is in NotReady state, the following conditions exist:
¡ The accessibility of the next hop of the static route is unknown.
¡ The static route is valid.
Restrictions and guidelines
If a static route needs route recursion, the associated track entry must monitor the next hop of the recursive route. The next hop of the static route cannot be monitored. Otherwise, a valid route might be considered invalid.
Associating Track with an IPv4 static route
1. Enter system view.
system-view
2. Associate an IPv4 static route with a track entry to check the accessibility of the next hop.
ip route-static { dest-address { mask-length | mask } | group group-name } { interface-type interface-number [ next-hop-address ] track track-entry-number | next-hop-address [ recursive-lookup host-route ] track track-entry-number | vpn-instance d-vpn-instance-name next-hop-address [ recursive-lookup host-route ] track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]
By default, an IPv4 static route is not associated with any track entries.
Associating Track with an IPv6 static route
1. Enter system view.
system-view
2. Associate an IPv6 static route with a track entry to check the accessibility of the next hop.
ipv6 route-static ipv6-address prefix-length { interface-type interface-number [ next-hop-address ] track track-entry-number | [ vpn-instance d-vpn-instance-name ] next-hop-address [ recursive-lookup host-route ] track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]
Associating Track with EAA
About this task
You can configure EAA track event monitor policies to monitor the positive-to-negative or negative-to-positive state changes of track entries.
· If you specify only one track entry for a policy, EAA triggers the policy when it detects the specified state change on the track entry.
· If you specify multiple track entries for a policy, EAA triggers the policy when it detects the specified state change on the last monitored track entry. For example, if you configure a policy to monitor the positive-to-negative state change of multiple track entries, EAA triggers the policy when the last positive track entry monitored by the policy is changed to the Negative state.
You can set a suppression time for a track event monitor policy. The timer starts when the policy is triggered. The system does not process messages that report the monitored track event until the timer times out.
For more information about EAA, see Network Management and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Create a CLI-defined monitor policy and enter its view, or enter the view of an existing CLI-defined monitor policy.
rtm cli-policy policy-name
3. Configure a track event.
event track track-entry-number-list state { negative | positive } [ suppress-time suppress-time ]
By default, a monitor policy does not monitor any track event.
Associating Track with ERPS
About this task
Track changes the track entry state based on the monitoring result, and notifies the track entry state change to the associated EPRS ring.
· When the track entry is in Positive state, the link of the monitored ERPS ring member port is in normal state. The ERPS ring does not switch traffic to other links.
· When the track entry is in Negative state, the link of the monitored ERPS ring member port is faulty. The ERPS ring switches traffic to other links.
· When the track entry is in NotReady state, the state of the ERPS ring member port does not change.
For more information about ERPS, see "Configuring ERPS."
Restrictions and guidelines
Before you associate a port with a track entry, make sure the port has joined an ERPS instance.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.
interface interface-type interface-number
3. Associate an ERPS ring member port with a track entry.
port erps ring ring-id instance instance-id track track-entry-index
By default, an ERPS ring member port is not associated with any track entries.
Associating Track with PoE
About this task
The PoE module can collaborate with the Track module to monitor the link status between the device and the PD connected to a PI. For example, if the PD supports the NQA ICMP echo test, you can specify a track entry associated with NQA for the PI to test the reachability of the PD. The NQA ICMP echo test must be configured on a Layer 3 interface. If the PI is a Layer 2 interface, create a VLAN interace and assign the PI to the VLAN interface, or configure the Layer 2 PI to operate in Layer 3 mode.
The Track module notifies the PoE module of the following monitoring results:
· Positive—The monitored object is reachable.
· Negative—The monitored object is unreachable.
· NotReady—The monitoring result is not ready because of reasons such as nonexistence of the NQA group associated with the track entry.
When the Track module detects failure of the link, it changes the track entry state from Positive to Negative, which triggers the PoE module to take the following actions:
· alarm-only: Outputs an SNMP notification and log.
· alarm-reboot-pd: Outputs an SNMP notification and log and reboots the PD connected to the PI.
For information about SNMP notifications, see SNMP configuration in Network Management and Monitoring Configuration Guide.
For information about logs, see information center configuration in Network Management and Monitoring Configuration Guide.
For information about PoE, see PoE configuration in Network Management and Monitoring Configuration Guide.
Procedure
1. Enter system view.
system-view
2. Associate a PI with a track entry.
poe track track-entry-number action { alarm | alarm-reboot-pd }
By default, a PI does not associate with any track entry.
Display and maintenance commands for Track
Execute display commands in any view.
|
Task |
Command |
|
Display information about track entries. |
display track { track-entry-number | all [ negative | positive ] } [ brief ] |
Track configuration examples
The output shows that when the control-mode BFD session detects that Switch A fails, the Track module notifies VRRP to change the status of Switch B to master. The backup can quickly preempt as the master without waiting for a period three times the advertisement interval plus the Skew_Time.
Example: Configuring static routing-Track-NQA collaboration
Network configuration
As shown in Figure 2:
· Switch A is the default gateway of the hosts in network 20.1.1.0/24.
· Switch D is the default gateway of the hosts in network 30.1.1.0/24.
· Hosts in the two networks communicate with each other through static routes.
To ensure network availability, configure route backup and static routing-Track-NQA collaboration on Switch A and Switch D as follows:
· On Switch A, assign a higher priority to the static route to 30.1.1.0/24 with next hop Switch B. This route is the master route. The static route to 30.1.1.0/24 with next hop Switch C acts as the backup route. When the master route is unavailable, the backup route takes effect. Switch A forwards packets to 30.1.1.0/24 through Switch C.
· On Switch D, assign a higher priority to the static route to 20.1.1.0/24 with next hop Switch B. This route is the master route. The static route to 20.1.1.0/24 with next hop Switch C acts as the backup route. When the master route is unavailable, the backup route takes effect. Switch D forwards packets to 20.1.1.0/24 through Switch C.
Procedure
1. Create VLANs and assign ports to them. Configure the IP address of each VLAN interface, as shown in Figure 2. (Details not shown.)
2. Configure Switch A:
# Configure a static route to 30.1.1.0/24 with next hop 10.1.1.2 and the default priority (60). Associate this static route with track entry 1.
<SwitchA> system-view
[SwitchA] ip route-static 30.1.1.0 24 10.1.1.2 track 1
# Configure a static route to 30.1.1.0/24 with next hop 10.3.1.3 and priority 80.
[SwitchA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80
# Configure a static route to 10.2.1.4 with next hop 10.1.1.2.
[SwitchA] ip route-static 10.2.1.4 24 10.1.1.2
# Create an NQA operation with administrator name admin and operation tag test.
[SwitchA] nqa entry admin test
# Specify the ICMP echo operation type.
[SwitchA-nqa-admin-test] type icmp-echo
# Specify 10.2.1.4 as the destination address of the operation.
[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.4
# Specify 10.1.1.2 as the next hop of the operation.
[SwitchA-nqa-admin-test-icmp-echo] next-hop ip 10.1.1.2
# Configure the ICMP echo operation to repeat every 100 milliseconds.
[SwitchA-nqa-admin-test-icmp-echo] frequency 100
# Configure reaction entry 1, specifying that five consecutive probe failures trigger the Track module.
[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only
[SwitchA-nqa-admin-test-icmp-echo] quit
# Start the NQA operation.
[SwitchA] nqa schedule admin test start-time now lifetime forever
# Configure track entry 1, and associate it with reaction entry 1 of the NQA operation.
[SwitchA] track 1 nqa entry admin test reaction 1
[SwitchA-track-1] quit
3. Configure Switch B:
# Configure a static route to 30.1.1.0/24 with next hop 10.2.1.4.
<SwitchB> system-view
[SwitchB] ip route-static 30.1.1.0 24 10.2.1.4
# Configure a static route to 20.1.1.0/24 with next hop 10.1.1.1.
[SwitchB] ip route-static 20.1.1.0 24 10.1.1.1
4. Configure Switch C:
# Configure a static route to 30.1.1.0/24 with next hop 10.4.1.4.
<SwitchC> system-view
[SwitchC] ip route-static 30.1.1.0 24 10.4.1.4
# Configure a static route to 20.1.1.0/24 with next hop 10.3.1.1.
[SwitchC] ip route-static 20.1.1.0 24 10.3.1.1
5. Configure Switch D:
# Configure a static route to 20.1.1.0/24 with next hop 10.2.1.2 and the default priority (60). Associate this static route with track entry 1.
<SwitchD> system-view
[SwitchD] ip route-static 20.1.1.0 24 10.2.1.2 track 1
# Configure a static route to 20.1.1.0/24 with next hop 10.4.1.3 and priority 80.
[SwitchD] ip route-static 20.1.1.0 24 10.4.1.3 preference 80
# Configure a static route to 10.1.1.1 with next hop 10.2.1.2.
[SwitchD] ip route-static 10.1.1.1 24 10.2.1.2
# Create an NQA operation with administrator name admin and operation tag test.
[SwitchD] nqa entry admin test
# Specify the ICMP echo operation type.
[SwitchD-nqa-admin-test] type icmp-echo
# Specify 10.1.1.1 as the destination address of the operation.
[SwitchD-nqa-admin-test-icmp-echo] destination ip 10.1.1.1
# Specify 10.2.1.2 as the next hop of the operation.
[SwitchD-nqa-admin-test-icmp-echo] next-hop ip 10.2.1.2
# Configure the ICMP echo operation to repeat every 100 milliseconds.
[SwitchD-nqa-admin-test-icmp-echo] frequency 100
# Configure reaction entry 1, specifying that five consecutive probe failures trigger the Track module.
[SwitchD-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only
[SwitchD-nqa-admin-test-icmp-echo] quit
# Start the NQA operation.
[SwitchD] nqa schedule admin test start-time now lifetime forever
# Configure track entry 1, and associate it with reaction entry 1 of the NQA operation.
[SwitchD] track 1 nqa entry admin test reaction 1
[SwitchD-track-1] quit
Verifying the configuration
# Display information about the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
State: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Tracked object type: NQA
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
NQA entry: admin test
Reaction: 1
Remote IP/URL: 10.2.1.4
Local IP:--
Interface:--
The output shows that the status of the track entry is Positive, indicating that the NQA operation has succeeded and the master route is available.
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2
10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3
10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan6
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.0/24 Static 60 0 10.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output shows that Switch A forwards packets to 30.1.1.0/24 through Switch B.
# Remove the IP address of interface VLAN-interface 2 on Switch B.
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] undo ip address
# Display information about the track entry on Switch A.
[SwitchA] display track all
Track ID: 1
State: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Tracked object type: NQA
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
NQA entry: admin test
Reaction: 1
Remote IP/URL: 10.2.1.4
Local IP:--
Interface:--
The output shows that the status of the track entry is Negative, indicating that the NQA operation has failed and the master route is unavailable.
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.0/24 Static 60 0 10.1.1.2 Vlan2
10.3.1.0/24 Direct 0 0 10.3.1.1 Vlan3
10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan6
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.0/24 Static 80 0 10.3.1.3 Vlan3
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output shows that Switch A forwards packets to 30.1.1.0/24 through Switch C. The backup static route has taken effect.
# Verify that hosts in 20.1.1.0/24 can communicate with the hosts in 30.1.1.0/24 when the master route fails.
[SwitchA] ping -a 20.1.1.1 30.1.1.1
Ping 30.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 30.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 30.1.1.1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms
# Verify that the hosts in 30.1.1.0/24 can communicate with the hosts in 20.1.1.0/24 when the master route fails.
[SwitchB] ping -a 30.1.1.1 20.1.1.1
Ping 20.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 20.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 20.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=4 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 20.1.1.1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms
Example: Configuring static routing-Track-LLDP collaboration
Network requirements
As shown in Figure 3:
· Device A is the default gateway of the hosts in network 20.1.1.0/24.
· Device B is the default gateway of the hosts in network 30.1.1.0/24.
· Hosts in the two networks communicate with each other through static routes.
To ensure network availability, configure route backup and static routing-Track-LLDP collaboration on Device A and Device B as follows:
· On Device A, assign a higher priority to the static route to 30.1.1.0/24 with next hop Device B. This route is the master route. The static route to 30.1.1.0/24 with next hop Device C acts as the backup route. When the master route is unavailable, the backup route takes effect. Device A forwards packets destined for 30.1.1.0/24 to Device C.
· On Device B, assign a higher priority to the static route to 20.1.1.0/24 with next hop Device A. This route is the master route. The static route to 20.1.1.0/24 with next hop Device C acts as the backup route. When the master route is unavailable, the backup route takes effect. Device B forwards packets destined for 20.1.1.0/24 to Device C.
Procedure
1. Configure the IP address of each interface, as shown in Figure 3. (Details not shown.)
2. Configure Device A:
# Configure a static route to 30.1.1.0/24 with next hop 10.1.1.2 and the default priority (60). Associate this static route with track entry 1.
<DeviceA> system-view
[DeviceA] ip route-static 30.1.1.0 24 10.2.1.2 track 1
# Configure a static route to 30.1.1.0/24 with next hop 10.3.1.3 and priority 80.
[DeviceA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80
# Enable LLDP globally.
[DeviceA] lldp global enable
# Enable LLDP on GigabitEthernet 1/0/1. (This step is optional because LLDP is enabled on the port by default.)
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] lldp enable
# Configure track entry 1 and associate it with the availability of the neighbor for LLDP interface Gigabitethernet 1/0/1.
[DeviceA] track 1 lldp neighbor interface gigabitethernet 1/0/1
[DeviceA-track-1] quit
3. Configure Device B:
# Configure a static route to 20.1.1.0/24 with next hop 10.2.1.1 and the default priority (60). Associate this static route with track entry 1.
<DeviceB> system-view
[DeviceB] ip route-static 20.1.1.0 24 10.2.1.1 track 1
# Configure a static route to 20.1.1.0/24 with next hop 10.4.1.3 and priority 80.
[DeviceB] ip route-static 20.1.1.0 24 10.4.1.3 preference 80
# Enable LLDP globally.
[DeviceB] lldp global enable
# Enable LLDP on GigabitEthernet 1/0/1. (This step is optional because LLDP is enabled on the port by default.)
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] lldp enable
# Configure track entry 1 and associate it with the availability of the neighbor for LLDP interface GigabitEthernet 1/0/1.
[DeviceB] track 1 lldp neighbor interface gigabitethernet 1/0/1
[DeviceB-track-1] quit
4. Configure Device C:
# Configure a static route to 30.1.1.0/24 with next hop 10.4.1.2.
<DeviceC> system-view
[DeviceC] ip route-static 30.1.1.0 24 10.4.1.2
# Configure a static route to 20.1.1.0/24 with next hop 10.3.1.1.
[DeviceC] ip route-static 20.1.1.0 24 10.3.1.1
Verifying the configuration
# Display track entry information on Device A.
[DeviceA] display track all
Track ID: 1
State: Positive
Duration: 0 days 0 hours 0 minutes 32 seconds
Tracked object type: LLDP
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
LLDP interface: GigabitEthernet1/0/1
The output shows that the status of track entry 1 is Positive, indicating that the neighbor of LLDP interface GigabitEthernet 1/0/1 is available. The master route takes effect.
# Display the routing table of Device A.
[DeviceA] display ip routing-table
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 0 10.2.1.1 GE1/0/1
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 Direct 0 0 10.3.1.1 GE1/0/2
10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 Direct 0 0 20.1.1.1 GE1/0/3
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.0/24 Static 60 0 10.2.1.2 GE1/0/1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output shows that Device A forwards packets to 30.1.1.0/24 through Device B.
# On Device B, disable LLDP on GigabitEthernet 1/0/1.
<DeviceB> system-view
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] undo lldp enable
# Display track entry information on Device A.
[DeviceA] display track all
Track ID: 1
State: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Tracked object type: LLDP
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
LLDP interface: GigabitEthernet1/0/1
The output shows that the status of track entry 1 is Negative, indicating that the neighbor of LLDP interface GigabitEthernet 1/0/1 is unavailable. The master route fails.
# Display the routing table of Device A.
[DeviceA] display ip routing-table
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 0 10.2.1.1 GE1/0/1
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 Direct 0 0 10.3.1.1 GE1/0/2
10.3.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.0/24 Direct 0 0 20.1.1.1 GE1/0/3
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.0/24 Static 80 0 10.3.1.3 GE1/0/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
The output shows that Device A forwards packets destined for 30.1.1.0/24 to Device C. The backup static route has taken effect.
# Verify that hosts in 20.1.1.0/24 can communicate with the hosts in 30.1.1.0/24 when the master route fails.
[DeviceA] ping -a 20.1.1.1 30.1.1.1
Ping 30.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 30.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 30.1.1.1: bytes=56 Sequence=4 ttl=254 time=2 ms
Reply from 30.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 30.1.1.1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms
# Verify that the hosts in 30.1.1.0/24 can communicate with the hosts in 20.1.1.0/24 when the master route fails.
[DeviceB] ping -a 30.1.1.1 20.1.1.1
Ping 20.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 20.1.1.1: bytes=56 Sequence=1 ttl=254 time=2 ms
Reply from 20.1.1.1: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=4 ttl=254 time=1 ms
Reply from 20.1.1.1: bytes=56 Sequence=5 ttl=254 time=1 ms
--- Ping statistics for 20.1.1.1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.00% packet loss
round-trip min/avg/max/std-dev = 1/1/2/1 ms