Table of Contents
Advertisement
Command Reference Guide
The test if not command specifies a conditional test where the track state (pass or fail) is dependent upon
the state of the object (probe, schedule, or interface) being tested. The not keyword indicates that the track
state will negate the result of the object test. For example, the track will FAIL if the schedule or probe is in
an ACTIVE or PASS state. Conversely, the track will PASS if the schedule or probe is in an INACTIVE or
FAIL state.
An interface is IP routing if its line-protocol state is up and if it has a valid, nonzero IP address. This means
that interfaces using Dynamic Host Configuration Protocol (DHCP) or negotiated Point-to-Point Protocol
(PPP) will not pass until their primary IP address is dynamically configured.
Command History
Release 15.1
Release 16.1
Release A4.01
Usage Examples
The following example demonstrates the use of the test if probe command to specify a single object to
test:
(config)#track PINGTEST
(config-track-PINGTEST)#test if probe PINGREMOTE
The following example demonstrates the logic of the test if not command used with schedule tracking:
(config)#track DELAY
(config-track-DELAY)#test if not schedule DELAY-AFTER-BOOT
The inverse logic of this command means that track DELAY will pass only if the schedule
DELAY-AFTER-BOOT is inactive.
The explanation that follows uses a real-world example to provide insight into the example above:
A customer has a primary Ethernet wide area network (WAN) interface, as well as a dial-on-demand
interface enabled on an AOS unit. The demand interface is intended as a backup for the primary Ethernet
interface. During router initialization and bootup, the Ethernet interface negotiates an IP address and
default route from a DHCP server. Due to this negotiation process, the active state of the Ethernet interface
lags behind that of the demand interface. As a result, the Ethernet interface appears down and the
demand interface dials out to back up the connection. The customer would like to prevent the demand
interface from dialing out before the Ethernet connection has had a chance to obtain its DHCP settings and
become active. It is determined that 180 seconds is a sufficient amount of time to allow for the Ethernet
interface to become active.
The following bullets describe the setup via command line interface (CLI) to accomplish the customer's
goals:
60000CRG0-35E
Command was introduced.
Command was expanded to include the interface parameter.
Command was expanded to include the Metro Ethernet Forum (MEF) Metro
Ethernet interface.
Copyright © 2012 ADTRAN, Inc.
Network Monitor Track Command Set
2984
Advertisement
Table of Contents
