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

The track module reports the track entry status changes to the application module. The application module can then take correct actions to avoid communication interruption and network performance degradation.

Supported detection modules

The following detection modules can be associated with the Track module:

· NQA.

· BFD.

· Interface management.

· Route management.

You can associate a track entry with an object of a detection module, such as the state of an interface or reachability of an IP route. The state of the track entry is determined by the state of the tracked object.

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.

· PBR.

· Interface backup.

· Redundancy group.

· VXLAN.

· EAA.

· Security policy.

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 Track with a detection module object

¡ Associating Track with NQA

¡ Associating Track with BFD

¡ 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 Track with PBR

¡ Associating Track with interface backup

¡ Associating Track with the redundancy group module

¡ Associating Track with VXLAN

¡ Associating Track with EAA

¡ Associating Track with a security policy rule

Associating Track with a detection module object

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 BFD

About this task

BFD supports the control packet mode and echo packet mode. A track entry can be associated only with the echo-mode BFD session. For more information about BFD, see "Configuring BFD."

The associated Track and BFD operate as follows:

· If the BFD detects that the link fails, it informs the Track module of the link failure. The Track module sets the track entry to Negative state.

· If the BFD detects that the link is operating correctly, the Track module sets the track entry to Positive state.

Prerequisites

Before you associate Track with BFD, configure the source IP address of BFD echo packets. For more information, see "Configuring BFD."

Procedure

1. Enter system view.

system-view

2. Create a track entry, associate it with a BFD session, and enter its view.

track track-entry-number bfd echo interface interface-type interface-number remote ip remote-ip-address local ip local-ip-address

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, physical status, or network-layer protocol status of interfaces. The associated Track and interface management operate as follows:

· When the link status, physical status, 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 status, physical status, 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 an interface, 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:

· When a monitored route entry is found in the routing table, the route management module informs the Track module. The Track module sets the track entry to Positive state.

· When a monitored route entry is removed from the routing table, the route 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 an IP route, and enter its view.

track track-entry-number ip route [ vpn-instance vpn-instance-name ] ip-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 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 track entry.

See "Associating Track with a detection module object."

Create a track entry before you add it as a tracked object to a tracked list.

A minimum of one track entry must be created.

3. Create a Boolean tracked list and enter its view.

track track-entry-number list boolean { and | or }

4. Add the track entry as an object to the tracked list.

object track-entry-number [ not ]

Repeat this step to add all interested objects to the tracked list.

5. (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.

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 track entry.

See "Associating Track with a detection module object."

Create a track entry before you add it as a tracked object to a tracked list.

A minimum of one track entry must be created.

3. Create a percentage threshold list and enter its view.

track track-entry-number list threshold percentage

4. Add the track entry as an object to the tracked list.

object track-entry-number

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%.

6. (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.

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 track entry.

See "Associating Track with a detection module object."

Create a track entry before you add it as a tracked object to a tracked list.

A minimum of one track entry must be created.

3. Create a weight threshold list and enter its view.

track track-entry-number list threshold weight

4. Add the track entry as an object to the tracked list.

object track-entry-number [ weight weight ]

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.

6. (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.

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.

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

In static routing-Track-NQA collaboration, you must configure the same VPN instance name for the NQA operation and the next hop of the static route. Otherwise, the accessibility detection cannot operate correctly.

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.

Public network:

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 track track-entry-number | vpn-instance d-vpn-instance-name next-hop-address track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]

VPN:

ip route-static vpn-instance s-vpn-instance-name { dest-address { mask-length | mask } | group group-name } { interface-type interface-number [ next-hop-address ] track track-entry-number | next-hop-address [ public ] track track-entry-number | vpn-instance d-vpn-instance-name next-hop-address track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]

By default, Track is not associated with any IPv4 static routes.

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.

Public network:

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 track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]

VPN:

ipv6 route-static vpn-instance s-vpn-instance-name ipv6-address prefix-length { interface-type interface-number [ next-hop-address ] track track-entry-number | vpn-instance d-vpn-instance-name next-hop-address track track-entry-number } [ preference preference ] [ tag tag-value ] [ description text ]

By default, Track is not associated with any IPv6 static routes.

Associating Track with PBR

About this task

PBR uses user-defined policies to route packets. You can specify parameters in a PBR policy to guide the forwarding of the packets that match specific criteria. 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 might be discarded. For example, if the output interface specified for PBR fails, PBR cannot detect the failure, and continues to forward matching packets out of the interface.

To enable PBR to detect topology changes and improve the flexibility of the PBR application, configure Track-PBR-detection module collaboration.

After you associate a track entry with an apply clause, the detection module associated with the track entry sends Track the detection result of the availability of the tracked object.

· The Positive state of the track entry indicates that the object is available, and the apply clause is valid.

· The Negative state of the track entry indicates that the object is not available, and the apply clause is invalid.

· The NotReady state of the track entry indicates that the apply clause is valid.

The following objects can be associated with a track entry:

· Output interface.

· Next hop.

· Default output interface.

· Default next hop.

Prerequisites for Track association with PBR

Before you associate Track with PBR, create a policy node, and set the match criteria.

Associating Track with PBR

1. Enter system view.

system-view

2. Create a policy node and enter its view.

policy-based-route policy-name [ deny | permit ] node node-number

3. Set match criteria. Choose the options to configure as needed:

¡ Set an ACL match criterion.

if-match acl { acl-number | name acl-name }

By default, no ACL match criterion is set.

The ACL match criterion cannot match Layer 2 information.

¡ Set a packet length match criterion.

if-match packet-length min-len max-len

By default, no packet length match criterion is set.

4. Set actions and associate the policy node with a track entry. Choose the options to configure as needed:

¡ Set the output interface.

apply output-interface { interface-type interface-number [ track track-entry-number ] }&<1-4>

By default, no output interface is set.

¡ Set the next hop.

apply next-hop [ vpn-instance vpn-instance-name | inbound-vpn ] { ip-address [ direct ] [ track track-entry-number ] [ weight weight-value ] }&<1-4>

By default, no next hop is set.

¡ Set the default output interface.

apply default-output-interface { interface-type interface-number [ track track-entry-number ] }&<1-4>

By default, no default output interface is set.

¡ Set the default next hop.

apply default-next-hop [ vpn-instance vpn-instance-name | inbound-vpn ] { ip-address [ direct ] [ track track-entry-number ] }&<1-4>

By default, no default next hop is set.

Associating Track with IPv6 PBR

1. Enter system view.

system-view

2. Create an IPv6 policy node and enter its view.

ipv6 policy-based-route policy-name [ deny | permit ] node node-number

3. Set match criteria. Choose the options to configure as needed:

¡ Set an ACL match criterion.

if-match acl { ipv6-acl-number | name ipv6-acl-name }

By default, no ACL match criterion is set.

The ACL match criterion cannot match Layer 2 information.

¡ Set an IPv6 packet length match criterion.

if-match packet-length min-len max-len

By default, no packet length match criterion is set.

4. Set actions and associate the policy node with a track entry. Choose the options to configure as needed:

¡ Set the output interface.

apply output-interface { interface-type interface-number [ track track-entry-number ] }&<1-4>

By default, no output interface is set.

¡ Set the next hop.

apply next-hop [ vpn-instance vpn-instance-name | inbound-vpn ] { ipv6-address [ direct ] [ track track-entry-number ] [ weight weight-value ] } &<1-4>

By default, no next hop is set.

¡ Set the default output interface.

apply default-output-interface { interface-type interface-number [ track track-entry-number ] }&<1-4>

By default, no default output interface is set.

¡ Set the default next hop.

apply default-next-hop [ vpn-instance vpn-instance-name | inbound-vpn ] { ipv6-address [ direct ] [ track track-entry-number ] }&<1-4>

By default, no default next hop is set.

Associating Track with interface backup

About this task

To enable a standby interface to detect the status of the active interface, you can associate the standby interface with a track entry.

· If the track entry is in Positive state, the following conditions exist:

¡ The link where the active interface resides operates correctly.

¡ The standby interfaces stay in backup state.

· If the track entry is in Negative state, the following conditions exist:

¡ The link where the active interface resides has failed.

¡ A standby interface changes to the active interface for data transmission.

· If the track entry is in always NotReady state, the following conditions exist:

¡ The association does not take effect.

¡ Each interface keeps its original forwarding state.

When the track entry turns to NotReady from other state, a standby interface becomes the active interface.

For more information about configuring interface backup, see "Configuring interface backup."

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Associate the interface with a track entry.

backup track track-entry-number

By default, no track entry is associated with an interface.

You can associate an interface with only one track entry.

If you execute this command multiple times, the most recent configuration takes effect.

Associating Track with the redundancy group module

About this task

The redundancy group can fast detect the link and interface failures after you associate it with Track.

Track changes the track entry state based on the monitoring result of a detection module, and notifies the track entry state change to the redundancy group.

· If the track entry state changes to Positive, the system increases the weight value of the redundancy group node. When the value of the redundancy group is greater than 0, the node can operate correctly.

· If the track entry state changes to Negative or NotReady, the system reduces the weight value of redundancy group node. If the value of the redundancy group is less than 0, the node cannot operate correctly. A node switchover occurs. The members (including Reth interfaces) on the other node take over.

For more information about redundancy groups, see Virtual Technologies Configuration Guide.

Restrictions and guidelines

To associate Track with a redundancy group configured with automatic node switchover, you must specify the interface interface-type interface-number option in the track command. When the specified interface fails, it will not be shut down by the Reth module.

Procedure

1. Enter system view.

system-view

2. Create a redundancy group and enter its view.

redundancy group group-name

3. Create a redundancy group node and enter its view.

node node-id

4. Associate Track with the redundancy group.

track track-entry-number [ reduced weight-reduced ] [ interface interface-type interface-number ]

By default, no track entry is associated with a redundancy group.

Associating Track with VXLAN

About this task

When you associate Track with an AC on a VXLAN network, the AC is up only when one or more of the associated track entries are positive.

The AC can be a Layer 3 interface.

Hardware and feature compatibility

Hardware	Feature compatibility
F5010, F5020, F5020-GM, F5030, F5030-6GW, F5040, F5060, F5080, F5000-AI-20, F5000-AI-40, F5000-V30, F5000-C, F5000-S, F5000-M, F5000-A	Yes
F1000-AI-20, F1000-AI-30, F1000-AI-50, F1000-AI-60, F1000-AI-70, F1000-AI-80, F1000-AI-90	No
F1003-L, F1005-L, F1010-L	No
F1005, F1010	No
F1020, F1020-GM, F1030, F1030-GM, F1050, F1060, F1070, F1070-GM, F1070-GM-L, F1080, F1090, F1000-V70	No
F1000-AK1110, F1000-AK1120, F1000-AK1130, F1000-AK1140	No
F1000-AK1212, F1000-AK1222, F1000-AK1232, F1000-AK1312, F1000-AK1322, F1000-AK1332	No
F1000-AK1414, F1000-AK1424, F1000-AK1434, F1000-AK1514, F1000-AK1524, F1000-AK1534, F1000-AK1614	No
F1000-AK108, F1000-AK109, F1000-AK110, F1000-AK115, F1000-AK120, F1000-AK125, F1000-AK710	No
F1000-AK130, F1000-AK135, F1000-AK140, F1000-AK145, F1000-AK150, F1000-AK155, F1000-AK160, F1000-AK165, F1000-AK170, F1000-AK175, F1000-AK180, F1000-AK185, F1000-GM-AK370, F1000-GM-AK380, F1000-AK710	No
LSU3FWCEA0, LSUM1FWCEAB0, LSX1FWCEA1	No
LSXM1FWDF1, LSUM1FWDEC0, IM-NGFWX-IV, LSQM1FWDSC0, LSWM1FWD0, LSPM6FWD, LSQM2FWDSC0	No
vFW1000, vFW2000	Yes

‌

Associating a Layer 3 interface with a track entry

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Bind the interface to a VSI and associate it with a track entry.

xconnect vsi vsi-name [ access-mode { ethernet | vlan } ] track track-entry-number&<1-3>

By default, a Layer 3 interface is not bound to any VSI or associated with any track entries.

When the AC to be bound to a VSI is a Layer 3 subinterface, you can use the access-mode keyword to specify the AC access mode. The default access mode is VLAN.

The access-mode keyword is not configurable when the AC is a Layer 3 interface.

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 a security policy rule

About this task

Perform this task to enable the collaboration between Track and a security policy rule. The collaboration operates as follows:

· If the rule is associated with the Negative state of a track entry, the device takes the following actions:

¡ Sets the rule state to Active if the track entry is in Negative state.

¡ Sets the rule state to Inactive if the track entry is in Positive state.

· If the rule is associated with the Positive state of a track entry, the device takes the following actions:

¡ Sets the rule state to Active if the track entry is in Positive state.

¡ Sets the rule state to Inactive if the track entry is in Negative state.

Procedure

1. Enter system view.

system-view

2. Enter IPv4 or IPv6 security policy view.

security-policy { ip | ipv6 }

3. Enter security policy rule view.

rule { rule-id | name name } *

4. Associate the rule with a track entry.

track { negative | positive } track-entry-number

By default, no track entry is associated with a security policy rule.

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

Example: Configuring static routing-Track-NQA collaboration

Network configuration

As shown in Figure 2:

· Device A is the default gateway of the hosts in network 20.1.1.0/24.

· Device 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 Device A and Device D 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.

· On Device D, assign a higher priority to the static route to 20.1.1.0/24 with next hop Device B. 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.

Figure 2 Network diagram

‌

Configuring Device A

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 10.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a main static route to 30.1.1.0/24 with next hop 10.1.1.2 and default priority 60, and associate the static route with track entry 1.

[DeviceA] ip route-static 30.1.1.0 24 10.1.1.2 track 1

# Configure a backup 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

# Configure a static route to 10.2.1.4/24 with next hop 10.1.1.2 and default priority 60. This static route will be used in an NQA operation.

[DeviceA] ip route-static 10.2.1.4 24 10.1.1.2

3. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/3

[DeviceA-security-zone-Untrust] quit

4. Configure a security policy:

# Configure a rule named trust-untrust to permit packets from network 20.1.1.0/24 to network 30.1.1.0/24.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-1-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-1-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-1-trust-untrust] source-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-1-trust-untrust] destination-ip-subnet 30.1.1.0 24

[DeviceA-security-policy-ip-1-trust-untrust] action pass

[DeviceA-security-policy-ip-1-trust-untrust] quit

# Configure a rule named untrust-trust to permit packets from network 30.1.1.0/24 to network 20.1.1.0/24.

[DeviceA-security-policy-ip] rule name untrust-trust

[DeviceA-security-policy-ip-2-untrust-trust] source-zone untrust

[DeviceA-security-policy-ip-2-untrust-trust] destination-zone trust

[DeviceA-security-policy-ip-2-untrust-trust] source-ip-subnet 30.1.1.0 24

[DeviceA-security-policy-ip-2-untrust-trust] destination-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-2-untrust-trust] action pass

[DeviceA-security-policy-ip-2-untrust-trust] quit

# Configure a rule named nqalocalout to allow Device A to send NQA probe packets to Device D.

[DeviceA-security-policy-ip] rule name nqalocalout

[DeviceA-security-policy-ip-3-nqalocalout] source-zone local

[DeviceA-security-policy-ip-3-nqalocalout] destination-zone untrust

[DeviceA-security-policy-ip-2-nqalocalout] service ping

[DeviceA-security-policy-ip-3-nqalocalout] action pass

[DeviceA-security-policy-ip-3-nqalocalout] quit

# Configure a rule named nqalocalin to allow Device A to receive the NQA probe packets from Device D.

[DeviceA-security-policy-ip] rule name nqalocalin

[DeviceA-security-policy-ip-4-nqalocalin] source-zone untrust

[DeviceA-security-policy-ip-4-nqalocalin] destination-zone local

[DeviceA-security-policy-ip-4-nqalocalin] service ping

[DeviceA-security-policy-ip-4-nqalocalin] action pass

[DeviceA-security-policy-ip-4-nqalocalin] quit

[DeviceA-security-policy-ip] quit

5. Create an NQA operation to test connectivity of path Device A—Device B—Device D.

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type icmp-echo

[DeviceA-nqa-admin-test-icmp-echo] destination ip 10.2.1.4

[DeviceA-nqa-admin-test-icmp-echo] next-hop ip 10.1.1.2

[DeviceA-nqa-admin-test-icmp-echo] frequency 100

[DeviceA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[DeviceA-nqa-admin-test-icmp-echo] quit

[DeviceA] nqa schedule admin test start-time now lifetime forever

6. Associate track entry 1 with reaction entry 1 of the NQA operation.

[DeviceA] track 1 nqa entry admin test reaction 1

[DeviceA-track-1] quit

Configuring Device B

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 10.1.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a static route to 30.1.1.0/24 with next hop 10.2.1.4.

[DeviceB] 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.

[DeviceB] ip route-static 20.1.1.0 24 10.1.1.1

Configuring Device C

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceC> system-view

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] ip address 10.3.1.3 255.255.255.0

[DeviceC-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a static route to 30.1.1.0/24 with next hop 10.4.1.4.

[DeviceC] 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.

[DeviceC] ip route-static 20.1.1.0 24 10.3.1.1

Configuring Device D

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceD> system-view

[DeviceD] interface gigabitethernet 1/0/1

[DeviceD-GigabitEthernet1/0/1] ip address 10.2.1.4 255.255.255.0

[DeviceD-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a main static route to 20.1.1.0/24 with next hop 10.2.1.2 and default priority 60, and associate the static route with track entry 1.

[DeviceD] ip route-static 20.1.1.0 24 10.2.1.2 track 1

# Configure a backup static route to 20.1.1.0/24 with next hop 10.4.1.3 and priority 80.

[DeviceD] ip route-static 20.1.1.0 24 10.4.1.3 preference 80

# Configure a static route to 10.1.1.1/24 with next hop 10.2.1.2 and default priority 60. This static route will be used in an NQA operation.

[DeviceD] ip route-static 10.1.1.1 24 10.2.1.2

3. Add interfaces to security zones.

[DeviceD] security-zone name untrust

[DeviceD-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceD-security-zone-Untrust] import interface gigabitethernet 1/0/2

[DeviceD-security-zone-Trust] quit

[DeviceD] security-zone name trust

[DeviceD-security-zone-Untrust] import interface gigabitethernet 1/0/3

[DeviceD-security-zone-Untrust] quit

4. Configure a security policy:

# Configure a rule named trust-untrust to permit packets from network 30.1.1.0/24 to network 20.1.1.0/24.

[DeviceD] security-policy ip

[DeviceD-security-policy-ip] rule name trust-untrust

[DeviceD-security-policy-ip-1-trust-untrust] source-zone trust

[DeviceD-security-policy-ip-1-trust-untrust] destination-zone untrust

[DeviceD-security-policy-ip-1-trust-untrust] source-ip-subnet 30.1.1.0 24

[DeviceD-security-policy-ip-1-trust-untrust] destination-ip-subnet 20.1.1.0 24

[DeviceD-security-policy-ip-1-trust-untrust] action pass

[DeviceD-security-policy-ip-1-trust-untrust] quit

# Configure a rule named untrust-trust to permit packets from network 20.1.1.0/24 to network 30.1.1.0/24.

[DeviceD-security-policy-ip] rule name untrust-trust

[DeviceD-security-policy-ip-2-untrust-trust] source-zone untrust

[DeviceD-security-policy-ip-2-untrust-trust] destination-zone trust

[DeviceD-security-policy-ip-2-untrust-trust] source-ip-subnet 20.1.1.0 24

[DeviceD-security-policy-ip-2-untrust-trust] destination-ip-subnet 30.1.1.0 24

[DeviceD-security-policy-ip-2-untrust-trust] action pass

[DeviceD-security-policy-ip-2-untrust-trust] quit

# Configure a rule named nqalocalout to allow Device D to send NQA probe packets to Device A.

[DeviceD-security-policy-ip] rule name nqalocalout

[DeviceD-security-policy-ip-3-nqalocalout] source-zone local

[DeviceD-security-policy-ip-3-nqalocalout] destination-zone untrust

[DeviceD-security-policy-ip-3-nqalocalout] service ping

[DeviceD-security-policy-ip-3-nqalocalout] action pass

[DeviceD-security-policy-ip-3-nqalocalout] quit

# Configure a rule named nqalocalin to allow Device D to receive the NQA probe packets from Device A.

[DeviceD-security-policy-ip] rule name nqalocalin

[DeviceD-security-policy-ip-4-nqalocalin] source-zone untrust

[DeviceD-security-policy-ip-4-nqalocalin] destination-zone local

[DeviceD-security-policy-ip-4-nqalocalin] service ping

[DeviceD-security-policy-ip-4-nqalocalin] action pass

[DeviceD-security-policy-ip-4-nqalocalin] quit

[DeviceD-security-policy-ip] quit

5. Create an NQA operation to test connectivity of path Device D—Device B—Device A.

[DeviceD] nqa entry admin test

[DeviceD-nqa-admin-test] type icmp-echo

[DeviceD-nqa-admin-test-icmp-echo] destination ip 10.1.1.1

[DeviceD-nqa-admin-test-icmp-echo] next-hop ip 10.2.1.2

[DeviceD-nqa-admin-test-icmp-echo] frequency 100

[DeviceD-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[DeviceD-nqa-admin-test-icmp-echo] quit

[DeviceD] nqa schedule admin test start-time now lifetime forever

6. Associate track entry 1 with reaction entry 1 of the NQA operation.

[DeviceD] track 1 nqa entry admin test reaction 1

[DeviceD-track-1] quit

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: 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 track entry 1 is Positive, indicating that the NQA operation has succeeded and the master route is available.

# Display the routing table of Device A.

[DeviceA] 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 GE1/0/1

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 GE1/0/1

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.1.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.

# Remove the IP address of GigabitEthernet 1/0/1 on Device B.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo ip address

# Display information about the track entry on Device A.

[DeviceA] 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 Device A.

[DeviceA] 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 GE1/0/1

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 GE1/0/1

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 to 30.1.1.0/24 through 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.

[DeviceD] 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-BFD collaboration

Network configuration

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-BFD collaboration on Device A and Device B as follows:

· 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, BFD can quickly detect the route failure to make the backup route take effect.

Figure 3 Network diagram

‌

Configuring Device A

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 10.2.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a main static route to 30.1.1.0/24 with next hop 10.2.1.2 and default priority 60, and associate the static route with track entry 1.

[DeviceA] ip route-static 30.1.1.0 24 10.2.1.2 track 1

# Configure a backup 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

3. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/3

[DeviceA-security-zone-Untrust] quit

4. Configure a security policy:

# Configure a rule named trust-untrust to permit packets from network 20.1.1.0/24 to network 30.1.1.0/24.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-1-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-1-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-1-trust-untrust] source-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-1-trust-untrust] destination-ip-subnet 30.1.1.0 24

[DeviceA-security-policy-ip-1-trust-untrust] action pass

[DeviceA-security-policy-ip-1-trust-untrust] quit

# Configure a rule named untrust-trust to permit packets from network 30.1.1.0/24 to network 20.1.1.0/24.

[DeviceA-security-policy-ip] rule name untrust-trust

[DeviceA-security-policy-ip-2-untrust-trust] source-zone untrust

[DeviceA-security-policy-ip-2-untrust-trust] destination-zone trust

[DeviceA-security-policy-ip-2-untrust-trust] source-ip-subnet 30.1.1.0 24

[DeviceA-security-policy-ip-2-untrust-trust] destination-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-2-untrust-trust] action pass

[DeviceA-security-policy-ip-2-untrust-trust] quit

# Configure a rule named bfdlocalout to allow Device A to send BFD echo packets to Device D.

[DeviceA-security-policy-ip] rule name bfdlocalout

[DeviceA-security-policy-ip-3-bfdlocalout] source-zone local

[DeviceA-security-policy-ip-3-bfdlocalout] destination-zone untrust

[DeviceA-security-policy-ip-2-bfdlocalout] service bfd-echo

[DeviceA-security-policy-ip-3-bfdlocalout] action pass

[DeviceA-security-policy-ip-3-bfdlocalout] quit

# Configure a rule named bfdlocalin to allow Device A to receive BFD echo packets.

[DeviceA-security-policy-ip] rule name bfdlocalin

[DeviceA-security-policy-ip-4-bfdlocalin] source-zone untrust

[DeviceA-security-policy-ip-4-bfdlocalin] destination-zone local

[DeviceA-security-policy-ip-2-bfdlocalin] service bfd-echo

[DeviceA-security-policy-ip-4-bfdlocalin] action pass

[DeviceA-security-policy-ip-4-bfdlocalin] quit

# Configure a rule named untrust-untrust to allow Device A to respond to the BFD echo packets from Device D.

[DeviceA-security-policy-ip] rule name untrust-untrust

[DeviceA-security-policy-ip-5-untrust-untrust] source-zone untrust

[DeviceA-security-policy-ip-5-untrust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-5-untrust-untrust] source-ip-host 1.1.1.1

[DeviceA-security-policy-ip-5-untrust-untrust] destination-ip-host 10.2.1.2

[DeviceA-security-policy-ip-5-untrust-untrust] action pass

[DeviceA-security-policy-ip-5-untrust-untrust] quit

# Configure a rule named pinglocalout to allow Device A to send ping packets to Device D.

[DeviceA-security-policy-ip] rule name pinglocalout

[DeviceA-security-policy-ip-6-pinglocalout] source-zone local

[DeviceA-security-policy-ip-6-pinglocalout] destination-zone untrust

[DeviceA-security-policy-ip-6-pinglocalout] service ping

[DeviceA-security-policy-ip-6-pinglocalout] action pass

[DeviceA-security-policy-ip-6-pinglocalout] quit

# Configure a rule named pinglocalin to allow Device A to respond to the ping packets from Device D.

[DeviceA-security-policy-ip] rule name pinglocalin

[DeviceA-security-policy-ip-7-pinglocalin] source-zone untrust

[DeviceA-security-policy-ip-7-pinglocalin] destination-zone local

[DeviceA-security-policy-ip-7-pinglocalin] service ping

[DeviceA-security-policy-ip-7-pinglocalin] action pass

[DeviceA-security-policy-ip-7-pinglocalin] quit

[DeviceA-security-policy-ip] quit

5. Specify 10.10.10.10 as the source address for BFD echo packets.

[DeviceA] bfd echo-source-ip 10.10.10.10

6. Configure track entry 1, and associate it with the BFD session to verify the connectivity between Device A and Device B.

[DeviceA] track 1 bfd echo interface gigabitethernet 1/0/1 remote ip 10.2.1.2 local ip 10.2.1.1

[DeviceA-track-1] quit

Configuring Device B

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 10.2.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a main static route to 20.1.1.0/24 with next hop 10.2.1.1 and default priority 60, and associate the static route with track entry 1.

[DeviceB] ip route-static 20.1.1.0 24 10.2.1.1 track 1

# Configure a backup 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

3. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/3

[DeviceB-security-zone-Untrust] quit

4. Configure a security policy:

# Configure a rule named trust-untrust to permit packets from network 30.1.1.0/24 to network 20.1.1.0/24.

[DeviceB] security-policy ip

[DeviceB-security-policy-ip] rule name trust-untrust

[DeviceB-security-policy-ip-1-trust-untrust] source-zone trust

[DeviceB-security-policy-ip-1-trust-untrust] destination-zone untrust

[DeviceB-security-policy-ip-1-trust-untrust] source-ip-subnet 30.1.1.0 24

[DeviceB-security-policy-ip-1-trust-untrust] destination-ip-subnet 20.1.1.0 24

[DeviceB-security-policy-ip-1-trust-untrust] action pass

[DeviceB-security-policy-ip-1-trust-untrust] quit

# Configure a rule named untrust-trust to permit packets from network 20.1.1.0/24 to network 30.1.1.0/24.

[DeviceB-security-policy-ip] rule name untrust-trust

[DeviceB-security-policy-ip-2-untrust-trust] source-zone untrust

[DeviceB-security-policy-ip-2-untrust-trust] destination-zone trust

[DeviceB-security-policy-ip-2-untrust-trust] source-ip-subnet 20.1.1.0 24

[DeviceB-security-policy-ip-2-untrust-trust] destination-ip-subnet 30.1.1.0 24

[DeviceB-security-policy-ip-2-untrust-trust] action pass

[DeviceB-security-policy-ip-2-untrust-trust] quit

# Configure a rule named bfdlocalout to allow Device D to send BFD echo packets to Device A.

[DeviceB-security-policy-ip] rule name bfdlocalout

[DeviceB-security-policy-ip-3-bfdlocalout] source-zone local

[DeviceB-security-policy-ip-3-bfdlocalout] destination-zone untrust

[DeviceB-security-policy-ip-3-bfdlocalout] service bfd-echo

[DeviceB-security-policy-ip-3-bfdlocalout] action pass

[DeviceB-security-policy-ip-3-bfdlocalout] quit

# Configure a rule named bfdlocalin to allow Device D to receive BFD echo packets.

[DeviceB-security-policy-ip] rule name bfdlocalin

[DeviceB-security-policy-ip-4-bfdlocalin] source-zone untrust

[DeviceB-security-policy-ip-4-bfdlocalin] destination-zone local

[DeviceB-security-policy-ip-4-bfdlocalin] service bfd-echo

[DeviceB-security-policy-ip-4-bfdlocalin] action pass

[DeviceB-security-policy-ip-4-bfdlocalin] quit

# Configure a rule named local-untrust to allow Device D to respond to the BFD echo packets from Device A.

[DeviceB-security-policy-ip] rule name untrust-untrust

[DeviceB-security-policy-ip-5-untrust-untrust] source-zone untrust

[DeviceB-security-policy-ip-5-untrust-untrust] destination-zone untrust

[DeviceB-security-policy-ip-5-untrust-untrust] source-ip-host 10.10.10.10

[DeviceB-security-policy-ip-5-untrust-untrust] destination-ip-host 10.2.1.1

[DeviceB-security-policy-ip-5-untrust-untrust] action pass

[DeviceB-security-policy-ip-5-untrust-untrust] quit

# Configure a rule named pinglocalout to allow Device D to send ping packets to Device A.

[DeviceB-security-policy-ip] rule name pinglocalout

[DeviceB-security-policy-ip-6-pinglocalout] source-zone local

[DeviceB-security-policy-ip-6-pinglocalout] destination-zone untrust

[DeviceB-security-policy-ip-6-pinglocalout] service ping

[DeviceB-security-policy-ip-6-pinglocalout] action pass

[DeviceB-security-policy-ip-6-pinglocalout] quit

# Configure a rule named pinglocalin to allow Device D to respond to the ping packets from Device A.

[DeviceB-security-policy-ip] rule name pinglocalin

[DeviceB-security-policy-ip-7-pinglocalin] source-zone untrust

[DeviceB-security-policy-ip-7-pinglocalin] destination-zone local

[DeviceB-security-policy-ip-7-pinglocalin] service ping

[DeviceB-security-policy-ip-7-pinglocalin] action pass

[DeviceB-security-policy-ip-7-pinglocalin] quit

[DeviceB-security-policy-ip] quit

5. Specify 1.1.1.1 as the source address of BFD echo packets.

[DeviceB] bfd echo-source-ip 1.1.1.1

6. Configure track entry 1, and associate it with the BFD session to verify the connectivity between Device B and Device A.

[DeviceB] track 1 bfd echo interface gigabitethernet 1/0/1 remote ip 10.2.1.1 local ip 10.2.1.2

[DeviceB-track-1] quit

Configuring Device C

1. Assign IP addresses to interfaces:

# Assign an IP address to interface GigabitEthernet 1/0/1.

<DeviceC> system-view

[DeviceC] interface gigabitethernet 1/0/1

[DeviceC-GigabitEthernet1/0/1] ip address 10.3.1.3 255.255.255.0

[DeviceC-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

2. Configure settings for routing:

# Configure a static route to 30.1.1.0/24 with next hop 10.4.1.2.

[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 information about the track entry on Device A.

[DeviceA] display track all

Track ID: 1

State: Positive

Duration: 0 days 0 hours 0 minutes 32 seconds

Tracked object type: BFD

Notification delay: Positive 0, Negative 0 (in seconds)

Tracked object:

BFD session mode: Echo

Outgoing interface: GigabitEthernet1/0/1

VPN instance name: --

Remote IP: 10.2.1.2

Local IP: 10.2.1.1

The output shows that the status of the track entry is Positive, indicating that next hop 10.2.1.2 is reachable.

# 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. The master static route has taken effect.

# Remove the IP address of GigabitEthernet 1/0/1 on Device B.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] undo ip address

# Display information about the track entry on Device A.

[DeviceA] display track all

Track ID: 1

State: Negative

Duration: 0 days 0 hours 0 minutes 32 seconds

Tracked object type: BFD

Notification delay: Positive 0, Negative 0 (in seconds)

Tracked object:

BFD session mode: Echo

Outgoing interface: GigabitEthernet1/0/1

VPN instance name: --

Remote IP: 10.2.1.2

Local IP: 10.2.1.1

The output shows that the status of the track entry is Negative, indicating that next hop 10.2.1.2 is unreachable.

# 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 to 30.1.1.0/24 through Device C. The backup static route has taken effect.

# Verify that the 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

17-Network Management and Monitoring Configuration Guide

Configuring Track

About this task

Restrictions and guidelines

Procedure

About this task

Prerequisites

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Associating Track with an IPv4 static route

Associating Track with an IPv6 static route

About this task

Prerequisites for Track association with PBR

Associating Track with PBR

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Hardware and feature compatibility

Associating a Layer 3 interface with a track entry

About this task

Procedure

About this task

Procedure

Display and maintenance commands for Track

Network configuration

Configuring Device A

Configuring Device B

Configuring Device C

Configuring Device D

Verifying the configuration

Network configuration

Configuring Device A

Configuring Device B

Configuring Device C

Verifying the configuration

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us