Abstract:
An extend ping protocol is described that allow connectivity tests to be performed for individual network interfaces of a target device without requiring network reachability between the testing device and the remote interface whose status is being queried. Moreover, the extend ping protocol supports a plurality of different probe types that allow an administrator to control how identification information within an extended ping echo request is resolved to the unreachable interfaces.

Description:
TECHNICAL FIELD 
       [0001]    This disclosure relates to computer networks and, more particularly, to utilities for determining the status of network interfaces. 
       BACKGROUND 
       [0002]    Conventional software utilities, such as the commonly used ping utility, are useful tools for determining whether a remote interface is active. These tools typically require a user to enter a unique identifier, such as a particular internet protocol (IP) address, of a remote host in order to test the status of a corresponding network interface. For example, the ping protocol tests status of a remote interface by sending an Internet Control Message Protocol (ICMP) echo request packet to a specific IP address assigned to that interface. If an echo reply packet is not received within a defined time period, connectivity to that interface is assumed to be down. 
         [0003]    In general, utilizing conventional ping to test the status of a particular network interface of a remote network device requires network reachability between the testing device and the remote network interface. For example, by specifying a global, publicly-reachable IP address of a particular interface of a remote device, an administrator may direct ping to that interface of the target device. When a private IP addresses is assigned to a network interface, such an interface can generally only be tested from a network device having network reachability to the private IP address, i.e., a network device within the same private network. Network interfaces having link-local IP addresses can generally only be tested using an interface connected to the same network link, i.e., from directly connected devices. 
         [0004]    In this sense, global IP addresses may be preferable in terms of testability via software utilities such as conventional ping. However, assignment of global IP addresses to each individual network interface may be undesirable for many reasons. For example, assigning known IP addresses to each individual interface exposes the device to interface-specific network attacks, such as packet-flooding of a particular interface. Furthermore, assigning and managing individual IP addresses for each interface of each network device within a network may increase operational expenses. 
         [0005]    For these reasons, network administrators may elect to forego assignment of an individual publicly known identifier, such as an IP address, to each network interface. Although this approach avoids the security risks and operational expenses associated with assignment of IP address to each interface, the network administrators are unable to use conventional testing utilities, such as ping, to test the status of particular network interfaces. 
       SUMMARY 
       [0006]    In general, principles of the invention relate techniques and protocols for extending network connectivity software utilities, such as ping, to support testing the status of unreachable interfaces. More specifically, in accordance with the principles described herein, the software utilities allow connectivity tests to be performed for individual network interfaces of a target device without requiring network reachability between the testing device and the remote interface whose status is being queried. Moreover, the extend ping protocol supports a plurality of different probe types that allow an administrator to control how identification information within an extended ping echo request is resolved to the unreachable interfaces, such as by interface address, interface name, interface description or interface index. In this way, even when interfaces of a remote target device have not been assigned a known unique identifier, such as a dedicated, publicly-known internet protocol (IP) address, an administrator may still use the software utilities to test the interfaces for connectivity. 
         [0007]    In one example, a source network device comprises a hardware-based programmable processor; and an extended ping software utility executing on the processor of source network device that presents a user interface to receive input from a user. The input identifies a network address of a reachable network interface of a target device, identification information for an unreachable network interface, and a probe type that specifies one of a plurality of probe types by which the identification information identifies the unreachable interface. The software utility outputs a ping echo request packet to test the status of the unreachable interface of the target device, wherein the ping echo request packet includes a header having a destination address of the network address of the reachable network interface of the target device, an identification information object specifying the identification information, and a probe type field specifying the probe type by which the identification information identifies the unreachable interface of the target device. 
         [0008]    In another example, a method comprises executing an extended ping software utility on a source network device and presenting, with the extended ping software utility, a user interface to receive input from a user. The input identifies a network address of a reachable network interface of a target device, identification information for an unreachable network interface of the target device, and a probe type that specifies one of a plurality of probe types by which the identification information identifies the unreachable interface. The method further includes outputting, from the source device with the software utility, a ping echo request packet to test the status of the unreachable interface of the target device. The ping echo request packet includes a header having a destination address of the network address of the reachable network interface of the target device. The ping echo request packet includes an identification information object specifying the identification information and a probe type field specifying the probe type by which the identification information identifies the unreachable interface of the target device. 
         [0009]    In another embodiment, a method receiving, from a source device and via a reachable interface on a target device, an echo request packet to test the status of an unreachable interface on the target device. The ping echo request packet includes a header having a destination address of the reachable network interface of the target device. The ping echo request packet further includes an identification information object specifying identification information for the unreachable network interface of the target device and a probe type field specifying a probe type by which the identification information identifies the unreachable interface of the target device. The method further includes processing the probe type specified within the probe type field to select a mode for comparing the identification information to configuration data of the target device and, based on the selected mode, comparing the identification information to parameters within the configuration data of the target device to resolve the identification information to the unreachable network interface of target device. The method includes outputting, to the source device and via the reachable interface, a reply packet indicating a status of the unreachable interface. 
         [0010]    The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0011]      FIG. 1  is a block diagram illustrating an exemplary computer network in which an administrator utilizes a software utility to test the status of unreachable network interfaces of a target device. 
           [0012]      FIG. 2  is a block diagram illustrating an example embodiment of a network device that allows an administrator to test the status of unreachable interfaces. 
           [0013]      FIG. 3  is a block diagram illustrating an exemplary packet format for use in testing connectivity of unnumbered interfaces. 
           [0014]      FIG. 4  is an exemplary screen illustration depicting an example command line interface as viewed on a server or other network device when executing the extend ping protocol described herein. 
           [0015]      FIG. 5  is a flowchart illustrating exemplary operation of a computer network in probing the status of an unreachable interface using a ping protocol that has been extended as described herein. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]      FIG. 1  is a block diagram illustrating an exemplary network environment  10  in which an administrator  16  (ADMIN) uses a software utility executing on network device  12  to test the status of unreachable network interfaces  15 B of remote router  13 . In the example of  FIG. 1 , network device  12  and router  13  support use of a diagnostic software utility, such as a ping protocol, that has been extended to test the status of network interfaces for which there is no direct network reachability from the testing device. 
         [0017]    In this example, network environment  10  includes network device  12  and router  13  connected across a first network  14  via intermediate routers, switches and other devices, shown for purposes of example as routers  18 A- 18 C (collectively, routers  18 ). As shown, network device  12  and router  13  includes network interfaces  15 A,  15 B, respectively, connected to network  14 A. Network  14   a  may comprise any public or private network or the Internet. For example, network  14 A may be a public network such that network interfaces  15 A and  15 B may be assigned globally routable, public IP address. Alternatively, network  14 A may be a private network such that each of network interfaces  15 A,  15 B are assigned private IP addresses from an address space utilized with network  14 A. In any event, network  14 A provides network reachability between interface  15 A of network device  12  and interface  15 B of router  13 . Network device  12  and router  13  are described for purposes of example and may be desktops, laptops, servers, routers, gateways or other devices suitable for implementing the techniques described herein. 
         [0018]    In this example, router  13  further includes network interfaces  15 C that couple router  13  to routers  21 A,  21 B of a second network  14 B via links  17 A,  17 B, respectively. As one example, network  14 B may be a private network having an address space different from network  14 A such that, in general, network reachability does not exist between network device  12  and network devices located within network  12 B. As such, network device  12  does not have network reachability to network interfaces  15 C of router  13  since, in this example, network interfaces  15 C have IP addresses of scope that is not reachable from network device  12 . Although network interfaces  15 A and  15 C are shown for purposes of example as being positioned on separate networks  14 A,  14 B, the techniques described herein may be applied to test the status of remote network interfaces that are ureachable from the testing network device for a variety of reasons, such as simply being unassigned a specific IP address. 
         [0019]    As described herein, administrator  16  accesses network device  12  and invokes a diagnostic software utility that has been extended in such a manner so as to allow the administrator to initiate a status test with respect to unreachable network interfaces  15 C of router  13 . That is, this document describes a new diagnostic tool called Extended Ping (eping). Network operators use eping to determine whether a remote interface is active. In this respect, eping is similar to ping. Eping differs from ping in that it does not require reachability between the probing node and the probed interface. Or, said another way, eping does not require network reachability between the node upon which it executes and the interface whose status is being queried. 
         [0020]    During the testing process, administrator may specify a specific reachable network interface of router  13 , e.g., network interface  15 B, and further specify at least one unreachable interface, such as any of interfaces  15 C, to be probed. In this example, the Internet Control Message Protocol (ICMP) has been extended to support testing the status of unreachable interfaces  15 , and ICMP packets between network device  12  and  12 B include additional fields so as to allow router  13  to disambiguate the request to a particular unreachable network interfaces. 
         [0021]    For example, in general, Eping utilizes two new ICMP messages, called Extended Echo and Extended Echo Reply, described herein. The Extended Echo message makes a semantic distinction between the destination interface (e.g., network interface  15 B of router  13 ) and the probed interface (e.g., either of network interfaces  15 C). The destination interface is the interface to which the Extended Echo message is delivered and reachable from the probing node (network device  12 ). The probed interface (e.g., either network interface  15 C) is the interface whose status is being queried and does not need to be reachable from the probing node. However, the destination and probed interfaces are local to one another (i.e., the same node supports both interfaces), e.g., network interfaces  15 B,  15 C on router  13 ). Because the Extended Echo message makes a distinction between the destination interface  15 B and probed interfaces  15 C, eping executing on network device  12  can probe every interface  15 C on router  13  as long as can the utility can reach at least one network interface on the probed node (router  13 ). In many cases, this allows network operators to decrease their dependence on widely-scoped interface addressing. 
         [0022]    In some embodiments, the software utility is extended in a manner in which the additional fields are opaque to the intermediate routing devices as well as the target device being tested. In these embodiments, when a target device does not support the extension, the target device replies in a conventional fashion. Moreover, although described by way of example to ping, the techniques may be applied to extend other network software utilities for diagnosing network conditions with respect to unreachable interfaces. Moreover, the techniques need not necessarily be applied to extend an existing, conventional protocol. Rather, the techniques may be incorporated in a new diagnostic utility. 
         [0023]      FIG. 2  is a block diagram illustrating an example embodiment of a network device, such as network device  12 , that allows administrator  16  to perform status testing of unreachable interfaces as described herein. 
         [0024]    In the example embodiment, network device  12  includes interface cards  24 A- 24 N (collectively, “IFCs  24 ”) that send and receive packet flows via inbound network links  26 A- 26 N (collectively, “inbound network links  26 ”) and outbound network links  28 A- 28 N (collectively, “outbound network links  28 ”), respectively. IFCs  24  coupled to control unit  20  by an input/output bus  30 . In general, control unit  20  provides an operating environment of executing software instructions stored within storage device  33 . For example, control unit  20  may include one or more programmable processors  34  capable of executing software instructions. Operating system  35 , when executed by processor  34 , provides an execution environment for software components, including diagnostic protocols such as eping  36 . Diagnostic protocols  36  allow network device  12  to output enhanced request packets, and receive enhanced reply packets, as described herein. Although described for exemplary purposes with respect to a computer, the source device or the target device may be any form of network device, and either or both of the devices may have one or more unnumbered interfaces. Examples of other devices include servers, laptops, desktops, mobile devices, intrusion detection devices, virtual private network (VPN) appliances, routers, hubs, switches, gateways, firewalls, security devices and other network devices and appliances. 
         [0025]      FIG. 3  is a block diagram illustrating an exemplary format of a packet  40  for use in testing connectivity of specific unnumbered interfaces. Packet  40  may, for example, be an ICMP Extended Echo message that has been extended to include additional fields. Packet  40  includes an IP header  42  that contains destination information for purposes of routing. For example, IP header  42  may contain a source IP address, a destination IP address, and a Time to Live (TTL) value that indicates a maximum number of hops the packet can traverse on the way to the packet&#39;s destination prior to expiration. 
         [0026]    The source IP address identifies an interface on the probing node, such as network interface  15 A of network device  12 . The destination IP address identifies the destination interface to which the message is to be delivered. That is, the destination IP address specifies an IP address for a reachable interface, IP address assigned to network interface  15 B of router  13 . 
         [0027]    In addition, packet  40  includes an ICMP header  43  having a type field  44 , a code field  46 , and a checksum  48 . Type field  44  is used to identify the type of message. For example, a type value of “8” indicates that the packet is an echo request. This type of packet is used by both the ping and traceroute utilities. A type value of “0” indicates that the packet is an echo reply. Code field  46  varies depending on the particular type of message, as specified by type field  44 . For example, for a traceroute reply packet having type  11  (“time exceeded”), a code value of “0” indicates that the time to live expired while the packet was in transit. Checksum  48  may be calculated taking into account the entire ICMP packet. Identifier  50  is an identifier to aid in matching Extended Echo Replies to Extended Echo Requests. Sequence number  52  carries an incremented sequence number for the particular eping message and also aids in matching Extended Echo replies to Extended Echo requests. 
         [0028]    Moreover, in accordance with the techniques described herein, packet  40  includes an additional interface identification object  54  that carries information for identifying the unreachable interface to be probed. Within interface identification object  54 , probe type field  56  specifies how the information contained within the interface identification object identifies the interface to be probed. As one example, probe type field  56  supports the following modes for identifying the probed interface:
       1. INTERFACE ADDRESS—the unreachable interface to be probed is specified by a unique network address assigned to the unreachable interface. The address family of the probed address specified by interface identification object  54  need not be the same address family as that of the destination address for the probed device as specified in IP header  42 . For example, the probed interface can be identified by its Ethernet address while the destination address for IP header  42  can be an IPv4 or IPv6 network address.   2. INTERFACE NAME—the unreachable interface to be probed is specified by the textual name assigned to the particular interface at the targeted device. This allows the user to specify the interface&#39;s local name on the probed network device, i.e., the textual name used at the probed device&#39;s local console for the interface. Examples include “wan1” or “wan1-2” as specified in an interface table on the probed machine. The interface name may, for example, comply with the ifName object described in RFC2863, “The Interfaces Group MIB,” the entire contents if which are incorporated herein by reference.   3. INTERFACE DESCRIPTION—The Interface Description field contains the human-readable interface description. This allows the user to enter a textual string containing information about the interface to be compared with interface descriptions specified within the configuration data of the probed device. This string may, for example, specify the name of the manufacturer, the product name and the version of the interface hardware/software. The interface description may, for example, comply with the ifDescr object described in RFC2863.   4. INTERFACE INDEX—the unreachable interface to be probed is specified by an index number, which is an positive integer within a enumerated sequence of integer values up to the number of interfaces allocated in the probed device (e.g., 1-64), where the indexes are sequentially assigned to the interfaces within the probed device and have scope limited to that device. The interface description may, for example, comply with the ifIndex object described in RFC2863.       
 
         [0033]    An extended ICMP echo reply message may take a form similar to that of packet  40  of  FIG. 3  excluding interface identification object  54 . In the extended ICMP echo reply message, code  46  indicates the operational status of the probed interface. Defined values for code  46  may be, for example, INACTIVE, ACTIVE, INTERFACE_DOES_NOT_EXIST and QUERY NOT SUPPORTED. 
         [0034]      FIG. 4  is an exemplary screen illustration depicting an example command line interface  56  generated by eping  36  when executing on a device, such as network device  12  of  FIGS. 1 and 2 . As shown in  FIG. 4 , the eping software utility accepts a variety of parameters. In operation, eping  36  generally accepts input parameters, sets a counter and enters a loop to be exited when the counter is equal to zero. For each iteration of the loop, eping emits an ICMP Extended Echo, decrements the counter, sets a timer, and waits for the timer to expire. If an expected ICMP Extended Echo Reply arrives while eping is waiting for the timer to expire, eping relays information returned by that message to its user. 
         [0035]    Command line interface  56  illustrates one example syntax format  58  for the eping utility. Syntax format  58  includes a number of options for the eping utility, enclosed in brackets. 
         [0036]    As shown in this example, the user invokes eping  36  by entering the “ping” command at the CLI presented by network device  12 . At this time, the user may enter the source interface address to specify the source address to be used in the header of the ICMP extended echo packet and destination interface address to be used as the destination address in the header of the ICMP extended echo packet, i.e., the reachable interface to which the ICMP extended echo message is sent. For example, the destination interface address can be an IPv4 address or an IPv6 address reachable the network device  12 . 
         [0037]    Optional field “-c” allows administrator  16  to define a number (count) of echo requests to be sent, i.e., the number of iterations to perform until terminating the process. Optional field “-w” allows administrator  16  to define the duration between each transmission of eping packets, in seconds. Optional field “-hc” allows administrator  16  to limit the number of hops that the packet will traverse on the network. 
         [0038]    “PROBED_INTERFACE_IDENTIFIER” is an optional field in which administrator  16  can further input information for identifying an unreachable network interface to be probed, i.e., an interface that is reachable via the probed device associated with the destination interface address specified above. If the interface is probed interface identifier is specified, it can be:
       an interface description   an interface name   an address from any address family (e.g., IPv4, IPv6, MAC)   an interface index       
 
         [0043]    The probed interface identifier can have any scope. As examples, the probed interface identifier can be:
       an IPv6 or IPv4 address having a scope that is global   an IPv6 or IPv4 address having a scope that is link-local   an interface name having a scope that is node-local at the target device   an interface description having a scope that is node-local at the target device   an interface index having a scope that is node-local at the target device
 
Moreover, if the probed interface identifier is an address, it does not need to be of the same address family as the destination interface address. For example, eping accepts an IPv4 destination interface address and an IPv6 probed interface identifier or an Ethernet MAC address.
       
 
         [0049]    As described herein, aspects of this disclosure allow the status of unreachable interfaces of a remote device to be determined. Moreover, a user may specify a identify the probed interface in a variety of ways. 
         [0050]    The following examples illustrate example implementations of the extended ePing described herein. For purposes of illustration, the examples will be explained in reference to the example network environment of  FIG. 1 . In particular, the following examples are explained with respect to utilizing ePing on network device  12  to ping an unreachable interface, such as either of interfaces  15 C of router  13 : 
         [0051]    This example illustrates utilizing ePing on network device  12  to determine the status of a global IP address of a reachable network interface  15 B of router  1 : 
         [0052]    &gt;eping 1.1.1.1 &lt;to ping the loopback&gt; 
         [0053]    This example illustrates utilizing ePing on network device  12  to determine the status of an unreachable interface  15 C of router  13  using a link-local address of that interface that is limited in scope to devices coupled to link  17 A: 
         [0054]    &gt;eping 1.1.1.1 -I FE08::1 &lt;to ping an interface by its link-local address&gt; 
         [0055]    This example illustrates utilizing ePing on network device  12  to determine the status of an unreachable interface  15 C of router  13  using an interface name (“ge-0/0/0.2”) of that interface as defined in the configuration data of router  13 : 
         [0056]    &gt;eping 1.1.1.1 -I ge-0/0/0.2 &lt;to ping the same interface by its ifName 
         [0057]    This example illustrates utilizing ePing on network device  12  to determine the status of an unreachable interface  15 C of router  13  using a string (“SONET interface; ACME manufacturing v1.1”) to match all or portions of an interface description of that interface as defined in the configuration data of router  13 :
       &gt;eping 1.1.1.1 -I “SONET interface; ACME manufacturing v1.1” &lt;to ping the same interface by its ifDescr&gt;       
 
         [0059]    This example illustrates utilizing ePing on network device  12  to determine the status of an unreachable interface  15 C of router  13  using an interface index (5) as defined in the configuration data of router  13 : 
         [0060]    &gt;eping 1.1.1.1 -I5 &lt;to ping the same interface by its ifIndex 
         [0061]    The following sections illustrate additional examples in which the target device is addressable by a global IP address of 10.10.10.2. In this first set of examples, ePing is used to determine the status of an unreachable interface of the target device by specifying an interface name “ge-0/0/0.0” of the interface as defined within the configuration data for the interface. 
         [0062]    Query Using Interface Name 
         [0063]    A. ge-0/0/0.0 is UP 
         [0064]    root@R11_re0:˜# eping -I ge-0/0/0.0 10.10.10.2 
         [0065]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0066]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0067]    Extended Ping Results
       Queried for status of Interface name: ge-0/0/0.0   Status: ACTIVE       
 
         [0070]    —10.10.10.2 ping statistics— 
         [0071]    1 packets transmitted, 1 packets received, ON packet loss 
         [0072]    B. ge-0/0/1.0 is DOWN 
         [0073]    root@R11_re0:˜# eping -I ge-0/0/1.0 10.10.10.2 
         [0074]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0075]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0076]    Extended Ping Results
       Queried for status of Interface name: ge-0/0/1.0   Status: INACTIVE       
 
         [0079]    —10.10.10.2 ping statistics— 
         [0080]    1 packets transmitted, 1 packets received, ON packet loss 
         [0081]    C. ge-0/0/3.0 does not exist 
         [0082]    root@R11 re0:˜# eping -I ge-0/0/3.0 10.10.10.2 
         [0083]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0084]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0085]    Extended Ping Results
       Queried for status of Interface name: ge-0/0/3.0   Status: Non Existent       
 
         [0088]    —10.10.10.2 ping statistics— 
         [0089]    1 packets transmitted, 1 packets received, ON packet loss 
         [0090]    In this second set of examples, ePing is used to determine the status of an unreachable interface of the target device by specifying an IP address “20.20.20.1” of the interface as defined within the address range for the network within which the unreachable interface is used (e.g., network  14 B of  FIG. 1 ). 
         [0091]    Query Using IP Address 
         [0092]    A. 20.20.20.1 is configured on disabled ifl 
         [0093]    root@R11_re0:˜# eping -I 20.20.20.1 10.10.10.2 
         [0094]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0095]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0096]    Extended Ping Results
       Queried for status of IP address: 20.20.20.1   Status: INACTIVE       
 
         [0099]    —10.10.10.2 ping statistics— 
         [0100]    1 packets transmitted, 1 packets received, ON packet loss 
         [0101]    B. 20.20.20.5 is not configured on the box 
         [0102]    root@R11_re0:˜# eping -I 20.20.20.5 10.10.10.2 
         [0103]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0104]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0105]    Extended Ping Results
       Queried for status of IP address: 20.20.20.5   Status: Non Existent       
 
         [0108]    —10.10.10.2 ping statistics— 
         [0109]    1 packets transmitted, 1 packets received, ON packet loss 
         [0110]    C. 10.10.10.2 is configured on an enabled ifl 
         [0111]    root@R11_re0:˜# eping -I 10.10.10.2 10.10.10.2 
         [0112]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0113]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0114]    Extended Ping Results
       Queried for status of IP address: 10.10.10.2   Status: ACTIVE       
 
         [0117]    —10.10.10.2 ping statistics— 
         [0118]    1 packets transmitted, 1 packets received, ON packet loss 
         [0119]    In this third set of examples, ePing is used to determine the status of an unreachable interface of the target device by specifying an IPv6 address “abcd::1 10.10.10.2” of the interface as defined within the address range for the network within which the unreachable interface is used (e.g., network  14 B of  FIG. 1 ). 
         [0120]    Query Using V6 Address: 
         [0121]    A. abcd::1 is configured on interface that is UP 
         [0122]    root@R11_re0:/var/tmp # ./eping -I abcd::1 10.10.10.2 
         [0123]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0124]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0125]    Extended Ping Results
       Queried for status of IP6 address abcd::1       
 
         [0127]    Interface name:
       Status: ACTIVE       
 
         [0129]    —10.10.10.2 ping statistics— 
         [0130]    1 packets transmitted, 1 packets received, ON packet loss 
         [0131]    B. 2001::1 is configured on an interface that is DOWN 
         [0132]    root@R11_re0:/var/tmp # ./eping -I 2001::1 10.10.10.2 
         [0133]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0134]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0135]    Extended Ping Results
       Queried for status of IP6 address 2001::1       
 
         [0137]    Interface name:
       Status: INACTIVE       
 
         [0139]    —10.10.10.2 ping statistics— 
         [0140]    1 packets transmitted, 1 packets received, ON packet loss 
         [0141]    C. 2001::2 is not configured on any interface 
         [0142]    root@R11_re0:/var/tmp # ./eping -I 2001::2 10.10.10.2 
         [0143]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0144]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0145]    Extended Ping Results
       Queried for status of IP6 address 2001::2       
 
         [0147]    Interface name:
       Status: Non Existent       
 
         [0149]    —10.10.10.2 ping statistics— 
         [0150]    1 packets transmitted, 1 packets received, ON packet loss 
         [0151]    In this fourth set of examples, ePing is used to determine the status of an unreachable interface of the target device by specifying an index of the interface as defined within the private configuration data for the target device: 
         [0152]    Query Using snmp Index: 
         [0153]    A. 542 belongs to an active 
         [0154]    root@R11_re0:˜# eping —I 542 10.10.10.2 
         [0155]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0156]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0157]    Extended Ping Results
       Queried for status of Interface index: 542   Status: ACTIVE       
 
         [0160]    B. 543 belongs to a disabled fl 
         [0161]    —10.10.10.2 ping statistics— 
         [0162]    1 packets transmitted, 1 packets received, ON packet loss 
         [0163]    root@R11_re0:˜# eping -I 543 10.10.10.2 
         [0164]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0165]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0166]    Extended Ping Results
       Queried for status of Interface index: 543   Status: INACTIVE       
 
         [0169]    C. 544 belongs to non existent fl 
         [0170]    —10.10.10.2 ping statistics— 
         [0171]    1 packets transmitted, 1 packets received, ON packet loss 
         [0172]    root@R11_re0:˜# eping -I 544 10.10.10.2 
         [0173]    PING 10.10.10.2 (10.10.10.2): 56 data bytes 
         [0174]    8 bytes from 10.10.10.2 via ge-0/0/0.0: icmp_seq=0 ttl=64 
         [0175]    Extended Ping Results
       Queried for status of Interface index: 544   Status: Non Existent       
 
         [0178]    —10.10.10.2 ping statistics— 
         [0179]    1 packets transmitted, 1 packets received, ON packet loss 
         [0180]      FIG. 5  is a flowchart illustrating exemplary operation of network environment  10  in testing status of unreachable network interfaces using an extended ping protocol. For exemplary purposes,  FIG. 5  is explained with reference to network device  12  and router  13  of  FIG. 1 . 
         [0181]    Initially, network device  12  receives commands entered by a user, such as administrator  16  ( 90 ) to invoke the extended ping protocol (eping). Administrator  16  may enter the commands, for example, via a command line interface, test script, GUI, management interface or the like. The commands may include an address for reaching router  13  as well as information for identifying an unreachable interface of router  13  to be tested as described herein. Alternatively, administrator  16  may utilize the extended ping protocol in a conventional manner. 
         [0182]    Network device  12  generates a request packet ( 94 ), such as packet  40  of  FIG. 3 . That is, the request packet may be an ICMP packet, such as an extended ping echo request packet that is extended to include additional fields as described herein. Network device  12  outputs the request packet to be forwarded to the destination interface address specified in the IP header of the packet and starts a timer ( 96 ). 
         [0183]    In the event network device  12  receives an echo reply packet from router  13  ( 98 ), the network device display results or statistics about the reply packet on the command line interface ( 100 ). In some cases, network device  12  may not receive a reply packet from router  13  before the timer expires ( 99 ). In this situation, network device  12  repeats the process of generating an echo request until either reply is received or a maximum number of iterations has been reached ( 99 ). In this case, network device  12  displays a failure message on the command line interface ( 100 ). 
         [0184]    In either case, after network device  12  has sent a request packet, router  13  may receive the request packet on the network interface assigned the IP address that is specified as a destination address within the packet&#39;s IP header ( 102 ). Upon receiving the request packet, router  13  examine interface identification object  54  ( FIG. 3 ) of the request packet to determine which interface of router  13 , if any, has been specifically designated for testing ( 104 ). As described herein, administrator  16  may have specified the interface in a variety of manners. 
         [0185]    If the interface is up (YES branch of  106 ), router  13  generate a reply packet ( 108 ). The reply packet may be an ICMP packet as shown in  FIG. 3 , such as an echo reply packet. When router  13  generates the echo reply packet, router  13  may swap the source and destination IP addresses in the IP header  42  and replace the “8” in the ICMP Type Field  44  with a “0” (for Echo Reply), add any optional data from variable user data field  50 , and recalculate all the checksums for field  48 . 
         [0186]    Router  13  then sends the echo reply packet to network device  12  ( 110 ). For example, router  13  may send the echo reply packet on the original interface on which the packet was received, i.e., interface  15 B, or any other interface from which the probing device (network device  12 ) is reachable. Provided intermediate connectivity exists, network device  12  receives the reply packet ( 98 ), and displays results about the reply packet ( 100 ). In the case where the probed interface is up but intermediate connectivity does not exist, network device  12  will not receive the reply packet before a time-out period expires ( 98 ), likely causing network device  12  to output a failure message ( 100 ). 
         [0187]    In the case where the specified unreachable destination interface (e.g., interface  15 C- 2  or  15 C- 3 ) is down (NO branch of  106 ), router  13  generates a reply packet with data indicating that the interface is down ( 114 ), and sends the reply packet out the original interface  15 B on which the echo request was received ( 116 ). Network device  12  receives the reply packet ( 98 ) and displays a failure message ( 100 ). 
         [0188]    Various embodiments of the invention have been described. These and other embodiments are within the scope of the following claims.