Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 05-Track Configuration | 174.13 KB |
Contents
Associating the track module with a detection module
Associating track with interface management
Associating the track module with an application module
Associating track with static routing
Displaying and maintaining track entries
Static routing-Track-BFD collaboration configuration example
VRRP-track-interface management collaboration configuration example
Overview
The track module works between application and detection modules, as shown in Figure 1. It shields the differences between various detection modules from application modules.
Collaboration is enabled after you associate the track module with a detection module and an application module. The detection module probes specific objects such as interface status and link status, and informs the track module of detection results. The track module sends the detection results to the associated application module. 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 fundamentals
The track module collaborates with detection modules and application modules:
· Collaboration between the track module and a detection module
· Collaboration between the track module and an application module
Collaboration between the track module and a detection module
The detection module sends the detection result of the associated tracked object to the track module. Depending on the result, the track module changes the status of the track entry:
· If the tracked object functions normally (for example, the target interface is up), the state of the track entry is Positive.
· If the tracked object functions abnormally (for example, the target interface is down), the state of the track entry is Negative.
· If the detection result is not valid (for example, the BFD session that is associated with the track entry does not exist), the state of the track entry is NotReady.
The following detection modules can be associated with the track module:
· BFD.
· Interface management module.
Collaboration between the track module and an application module
The following application modules can be associated with the track module:
· VRRP.
· Static routing.
· Policy-based routing.
|
|
NOTE: The track entries that are associated with BFD cannot be associated with VRRP. |
Track configuration task list
To implement the collaboration function, establish associations between the track module and the detection modules, and between the track module and the application modules.
To configure the track module, perform the following tasks:
|
Tasks at a glance |
Remarks |
|
(Required.) Associating the track module with a detection module: |
Use either approach. |
|
(Required.) Associating the track module with an application module: |
Use one of the approaches. |
Associating the track module with a detection module
Associating track with BFD
BFD supports the control packet mode and echo packet mode. A track entry can only be associated with the echo-mode BFD session, and cannot be associated with the control-mode BFD session. For more information about BFD, see "Configuring BFD."
The BFD functions as follows when it is associated with a track entry:
· If the BFD detects that the link fails, it informs the track entry of the link failure. The track module then sets the track entry to the Negative state.
· If the BFD detects that the link is operating properly, the track module sets the track entry to the Positive state.
Configuration prerequisites
Before you associate track with BFD, configure the source IP address of BFD echo packets. For more information, see "Configuring BFD."
Configuration procedure
To associate track with BFD:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create a track entry, associate it with the BFD session, and specify the delay time for the track module to notify the associated application module when the track entry status changes. |
track track-entry-number bfd echo interface interface-type interface-number remote ip remote-ip local ip local-ip [ delay { negative negative-time | positive positive-time } * ] |
By default, no track entry is created. |
Associating track with interface management
The interface management module monitors the physical status or network-layer protocol status of the interface. The interface management module functions as follows when it is associated with a track entry:
· When the physical or network-layer protocol status of the interface changes to up, the interface management module informs the track module of the change and the track module sets the track entry to Positive.
· When the physical or network-layer protocol status of the interface changes to down, the interface management module informs the track module of the change and the track module sets the track entry to Negative.
To associate track with interface management:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Associating track with interface management. |
·
Create a track entry, associate it with the interface
management module to monitor the physical status of an interface, and specify
the delay time for the track module to notify the associated application
module when the track entry status changes: ·
Create a track entry, associate it with the interface
management module to monitor the Layer 3 protocol status of an interface, and
specify the delay time for the track module to notify the associated
application module when the track entry status changes: |
Use either approach. By default, no track entry is created. |
Associating the track module with an application module
Associating track with VRRP
VRRP is an error-tolerant protocol. It adds a group of routers that can act as network gateways to a VRRP group, which forms a virtual router. Depending on their priority level, routers in the VRRP group elect the master router to act as the gateway. A router with a higher priority is more likely to become the master. The other routers function as the backups. When the master fails, the backups in the VRRP group elect a new master from among them. This makes sure the hosts in the network segment can communicate with external networks without interruption. For more information about VRRP, see "Configuring VRRP."
When VRRP is operating in standard protocol mode or load balancing mode, associate the track module with the VRRP group to implement the following actions:
· Change the priority of a router according to the status of the uplink. If a fault occurs on the uplink of the router, the VRRP group is not aware of the uplink failure. If the router is the master, hosts in the LAN cannot access the external network. This problem can be solved by establishing a track-VRRP group association. Use the detection modules to monitor the status of the uplink of the router and establish collaborations between the detection modules, track module and VRRP. When the uplink fails, the detection modules notify the track module to change the status of the monitored track entry to Negative, and the priority of the master decreases by a specific value. This allows a higher priority router in the VRRP group to become the master, and maintains proper communication between the hosts in the LAN and the external network.
· Monitor the master on a backup. If a fault occurs on the master, the backup operating in switchover mode will switch to the master immediately to maintain normal communication.
When VRRP is operating in load balancing mode, associate the track module with the VRRP Virtual Forwarder (VF) to implement the following functions:
· Change the priority of the active VF (AVF) according to its uplink state. When the uplink of the AVF fails, the track entry changes to Negative state and the weight of the AVF decreases by a specific value so that the VF with a higher priority becomes the new AVF to forward packets.
· Monitor the AVF status from the listening VF (LVF), which refers to the VF in listening state. When the AVF fails, the LVF that is operating in switchover mode becomes the new AVF to ensure continuous forwarding.
Follow these guidelines when you associate track with VRRP:
· VRRP tracking is not valid on an IP address owner. An IP address owner refers to a router when the IP address of the virtual router is the IP address of an interface on the router in the VRRP group.
· When the status of the track entry changes from Negative to Positive or NotReady, the associated router or VF restores its priority automatically.
· You can associate a nonexistent track entry with a VRRP group or VF. The association takes effect only after you use the track command to create the track entry.
To associate track with VRRP group:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter interface view. |
interface interface-type interface-number |
N/A |
|
3. Associate a track entry with a VRRP group. |
vrrp [ ipv6 ] vrid virtual-router-id track track-entry-number [ reduced priority-reduced | switchover ] |
No track entry is specified for a VRRP group by default. This command is supported when VRRP is operating in both standard protocol mode and load balancing mode. |
To associate track with VRRP VF:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter interface view. |
interface interface-type interface-number |
N/A |
|
3. Associate track with VRRP VF. |
vrrp [ ipv6 ] vrid virtual-router-id weight track track-entry-number [ reduced weight-reduced ] |
By default, no track entry is specified for a VF. This command is configurable when VRRP is operating in standard mode or load balancing mode. However, this command takes effect only when VRRP is operating in load balancing mode. |
Associating track with static routing
A static route is a manually configured route. With a static route configured, packets to the specified destination are forwarded through the path specified by the administrator. For more information about static route configuration, see Layer 3—IP Routing Configuration Guide.
The disadvantage of using static routes is that they cannot adapt to network topology changes. Faults or topological changes in the network can make the routes unreachable, causing network breaks.
To prevent 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, avoiding network breaks and enhancing network reliability.
To check the accessibility of a static route in real time, establish an association between the track and the static route.
If you specify the next hop but not the egress interface when configuring a static route, you can establish collaborations among the static route, the track module, and detection modules. This enables you to check the accessibility of the static route by the status of the track entry.
· The Positive state of the track entry shows that the next hop of the static route is reachable, and that the configured static route is valid.
· The Negative state of the track entry shows that the next hop of the static route is not reachable, and that the configured static route is invalid.
· The NotReady state of the track entry shows that the accessibility of the next hop of the static route is unknown, and that the static route is valid.
Follow these guidelines when you associate track with static routing:
· You can associate a nonexistent track entry with a static route. The association takes effect only after you use the track command to create the track entry.
· If a static route needs route recursion, the associated track entry must monitor the next hop of the recursive route instead of that of the static route. Otherwise, a valid route may be considered invalid.
To associate track with static routing:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Associate the static route with a track entry to check the accessibility of the next hop. |
·
Approach 1: ·
Approach 2: |
Not configured by default. |
Associating track with PBR
PBR is a routing mechanism based on user-defined policies. Different from the traditional destination-based routing mechanism, PBR allows you to use a policy (based on such criteria as the source address and packet length) to route packets. You can specify the next hop to guide the forwarding of packets that match specific ACLs. For more information about PBR, see Layer 3—IP Routing Configuration Guide.
PBR cannot detect the availability of any action taken on packets. When an action is not available, packets processed by the action may be discarded.
Associating track with PBR can improve the flexibility of the PBR application and enable PBR to sense topology changes.
After you associate a track entry with an apply clause, the detection module associated with the track entry sends the detection result of the availability of the object (an interface or an IP address) specified in the apply clause.
· The Positive state of the track entry shows that the object is available, and the apply clause is valid.
· The Negative state of the track entry shows that the object is not available, and the apply clause is invalid.
· The NotReady state of the track entry shows that the apply clause is valid.
The next hop can be associated with a track entry.
Configuration prerequisites
Before you associate track with PBR, create a policy or a policy node and configure the match criteria as well.
Configuration procedure
You can associate a nonexistent track entry with PBR. The association takes effect only after you use the track command to create the track entry.
To associate track with PBR:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create a policy or policy node and enter PBR policy node view. |
policy-based-route policy-name [ deny | permit ] node node-number |
N/A |
|
3. Define an ACL match criterion. |
if-match acl acl-number |
By default, no packets are filtered. |
|
4. Set the next hop, and associate it with a track entry. |
apply ip-address next-hop [ vpn-instance vpn-instance-name ] { ip-address [ direct ] [ track track-entry-number ] }&<1-2> |
N/A |
Displaying and maintaining track entries
|
Task |
Command |
Remarks |
|
Display information about the specified or all track entries. |
display track { track-entry-number | all } |
Available in any view. |
Track configuration examples
By default, Ethernet, VLAN, and aggregate interfaces are down. To configure such an interface, bring the interface up by executing the undo shutdown command.
Static routing-Track-BFD collaboration configuration example
Network requirements
As shown in Figure 2, Switch A, Switch B, and Switch C are connected to two segments 20.1.1.0/24 and 30.1.1.0/24. Configure static routes on these routers so that the two segments can communicate with each other. Configure route backup to improve network reliability.
Switch A is the default gateway of the hosts in segment 20.1.1.0/24. Two static routes to 30.1.1.0/24 exist on Switch A, with the next hop being Switch B and Switch C, respectively. These two static routes back up each other as follows:
· The static route with Switch B as the next hop has a higher priority and is the master route. If this route is available, Switch A forwards packets to 30.1.1.0/24 through Switch B.
· The static route with Switch C as the next hop acts as the backup route.
· Configure static routing-track-BFD collaboration to determine whether the master route is available in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the backup route take effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C and Switch B.
Similarly, Switch B is the default gateway of the hosts in segment 30.1.1.0/24. Two static routes to 20.1.1.0/24 exist on Switch B, with the next hop being Switch A and Switch C, respectively. These two static routes back up each other as follows:
· The static route with Switch A as the next hop has a higher priority and is the master route. If this route is available, Switch B forwards packets to 20.1.1.0/24 through Switch A.
· The static route with Switch C as the next hop acts as the backup route.
· Configure static routing-track-BFD collaboration to determine whether the master route is available in real time. If the master route is unavailable, BFD can quickly detect the route failure to make the backup route take effect, and Switch B forwards packets to 20.1.1.0/24 through Switch C and Switch A.
Configuration procedure
1. Create VLANs and assign corresponding 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 the address of the next hop as 10.2.1.2 and the default priority 60. This static route is associated with track entry 1.
<SwitchA> system-view
[SwitchA] 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 the address of the next hop as 10.3.1.3 and the priority 80.
[SwitchA] ip route-static 30.1.1.0 24 10.3.1.3 preference 80
# Configure the source address of BFD echo packets as 10.10.10.10.
[SwitchA] bfd echo-source-ip 10.10.10.10
# Configure track entry 1, and associate it with the BFD session. Check whether Switch A can be interoperated with the next hop of static route (Switch B).
[SwitchA] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.2 local ip 10.2.1.1
3. Configure Switch B:
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.2.1.1 and the default priority 60. This static route is associated with track entry 1.
<SwitchB> system-view
[SwitchB] 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 the address of the next hop as 10.4.1.3 and the priority 80.
[SwitchB] ip route-static 20.1.1.0 24 10.4.1.3 preference 80
# Configure the source address of BFD echo packets as 1.1.1.1.
[SwitchB] bfd echo-source-ip 1.1.1.1
# Configure track entry 1 that is associated with the BFD session to check whether Switch B can communicate with the next hop (Switch A) of the static route.
[SwitchB] track 1 bfd echo interface vlan-interface 2 remote ip 10.2.1.1 local ip 10.2.1.2
4. Configure Switch C:
# Configure a static route to 30.1.1.0/24, with the address of the next hop as 10.4.1.2.
<SwitchC> system-view
[SwitchC] ip route-static 30.1.1.0 24 10.4.1.2
# Configure a static route to 20.1.1.0/24, with the address of the next hop as 10.3.1.1.
[SwitchB] ip route-static 20.1.1.0 24 10.3.1.1
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
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
Remote IP: 10.2.1.2
Local IP: 10.2.1.1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan2
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 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 Vlan5
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 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 the BFD detection result: the next hop 10.2.1.2 is reachable (the status of the track entry is Positive). The master static route takes effect. 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
Notification delay: Positive 0, Negative 0 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Vlan-interface2
VPN instance name: -
Remote IP: 10.2.1.2
Local IP: 10.2.1.1
# Display the routing table of Switch A.
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan2
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 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 Vlan5
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 the BFD detection result: the next hop 10.2.1.2 is unreachable (the status of the track entry is Negative), and the backup static route takes effect, and Switch A forwards packets to 30.1.1.0/24 through Switch C and Switch B.
# When the master route fails, the hosts in 20.1.1.0/24 can still communicate with the hosts in 30.1.1.0/24.
[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
--- 30.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
# The output on Switch B is similar to that on Switch A. When the master route fails, the hosts in 30.1.1.0/24 can still communicate with the hosts in 20.1.1.0/24.
[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
--- 20.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
VRRP-track-interface management collaboration configuration example
In this example, the master monitors the uplink interface.
Network requirements
· As shown in Figure 3, Host A needs to access Host B on the Internet. The default gateway of Host A is 10.1.1.10/24.
· Switch A and Switch B belong to VRRP group 1, whose virtual IP address is 10.1.1.10.
· When Switch A works properly, packets from Host A to Host B are forwarded through Switch A. When VRRP detects that a fault is on the uplink interface of Switch A through the interface management module, packets from Host A to Host B are forwarded through Switch B.
Configuration procedure
1. Create VLANs and assign corresponding ports to them. Configure the IP address of each VLAN interface as shown in Figure 3. (Details not shown.)
2. Configure a track entry on Switch A:
# Configure track entry 1 and associate it with the physical status of the uplink interface VLAN-interface 3.
[SwitchA] track 1 interface vlan-interface 3
3. Configure VRRP on Switch A:
# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
# Set the priority of Switch A in VRRP group 1 to 110.
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# Configure to monitor track entry 1, and specify the priority decrement as 30.
[SwitchA-Vlan-interface2] vrrp vrid 1 track 1 reduced 30
4. Configure VRRP on Switch B:
<SwitchB> system-view
[SwitchB] interface vlan-interface 2
# Create VRRP group 1 and configure the virtual IP address 10.1.1.10 for the group.
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 10.1.1.10
Verifying the configuration
After configuration, ping Host B on Host A, and you can see that Host B is reachable. Use the display vrrp command to view the configuration result.
# Display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 110 Running Pri : 110
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 10.1.1.10
Virtual MAC : 0000-5e00-0101
Master IP : 10.1.1.1
VRRP Track Information:
Track Object : 1 State : Positive Pri Reduced : 30
# Display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Become Master : 2200ms left
Auth Type : None
Virtual IP : 10.1.1.10
Master IP : 10.1.1.1
The output shows that in VRRP group 1, Switch A is the master, and Switch B is a backup. Packets from Host A to Host B are forwarded through Switch A.
# Shut down the uplink interface VLAN-interface 3 on Switch A.
[SwitchA-Vlan-interface2] interface vlan-interface 3
[SwitchA-Vlan-interface3] shutdown
After shutting down the uplink interface on Switch A, you can still successfully ping Host B on Host A. Use the display vrrp command to view information about VRRP group 1.
# After shutting down the uplink interface on Switch A, display detailed information about VRRP group 1 on Switch A.
[SwitchA-Vlan-interface3] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 110 Running Pri : 80
Preempt Mode : Yes Delay Time : 0
Become Master : 2200ms left
Auth Type : None
Virtual IP : 10.1.1.10
Master IP : 10.1.1.2
VRRP Track Information:
Track Object : 1 State : Negative Pri Reduced : 30
# After shutting down the uplink interface on Switch A, display detailed information about VRRP group 1 on Switch B.
[SwitchB-Vlan-interface2] display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface Vlan-interface2
VRID : 1 Adver Timer : 1
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 10.1.1.10
Virtual MAC : 0000-5e00-0101
Master IP : 10.1.1.2
The output shows that when the uplink interface on Switch A is shut down, the priority of Switch A decreases to 80. Switch A becomes the backup, and Switch B becomes the master. Packets from Host A to Host B are forwarded through Switch B.