InetDaemon.Com

This example is from a CISCO ROUTER. Let's suppose that we're troubleshooting a simplex connection directly attached to us over a satellite link. We want to verify just where the second half of the connection goes to see if the traffic is going back over the second satellite connection or over an outside network.

Key information and notes are in RED

router#ping     
Protocol [ip]:
Target IP address: 63.100.219.94
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 63.100.219.94, timeout is 2 seconds:
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (620 ms). Received packet has options
   Total option bytes= 40, padded length=40
   Record route:
   rtr01-01-fe3-0-0.provider.net (198.78.137.1)<< Packet starts on ISP#1's side
   (63.100.219.93)        << ISP#1's router, a /30 for customer connections
   (63.100.219.94)        << Customer's router with IP from ISP#1 receives packet
   (63.100.219.94)        << Customer router generates ICMP reply
   gw2.customer.net (63.100.218.202)     << Customer's router forwards packet
                                            to another interface or router on
                                            the customer's network.
   rtr18.otherisp.net (63.100.218.201)   << Router on second ISP's network.
   rtr07.otherisp.net (63.100.217.113)
   rtr21.otherisp.net (63.100.200.41) <*>
   (0.0.0.0)
 End of list

<< DUPLICATE RESPONSES FROM HERE ON >>

Because all additional packets beyond this point have
the same network path, there is only one active path
through this downstream network.

In this case, the customer lied and said that we were
their only network connection and was blaming us for
their outage. The reality was that our downlink to
them was working perfectly and their second provider
was having problems so the return traffic didn't
always make it back.

If the remaining requests below changed path in a
repeating pattern (exit 1, then exit2), it would
indicate that there is load balancing going on over
two or more paths.

If the change does not repeat predictably, and
appears random, then there are network problems in
the remote network.

<< InetDaemon >>


Reply to request 1 (620 ms). Received packet has options
   Total option bytes= 40, padded length=40
   Record route:
   rtr01-01-fe3-0-0.provider.net (198.78.137.1)
   (63.100.219.93)
   (63.100.219.94)
   (63.100.219.94)
   gw2.customer.net (63.100.218.202)
   rtr18.otherisp.net (63.100.218.201) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 2 (620 ms).  Received packet has options
   Total option bytes= 40, padded length=40
   Record route:
   rtr01-01-fe3-0-0.provider.net (198.78.137.1)
   (63.100.219.93)
   (63.100.219.94)
   (63.100.219.94)
   gw2.customer.net (63.100.218.202)
   rtr18.otherisp.net (63.100.218.201) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 3 (620 ms). Received packet has options
   Total option bytes= 40, padded length=40
   Record route:
   rtr01-01-fe3-0-0.provider.net (198.78.137.1)
   (63.100.219.93)
   (63.100.219.94)
   (63.100.219.94)
   gw2.customer.net (63.100.218.202)
   rtr18.otherisp.net (63.100.218.201) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 4 (620 ms). Received packet has options
   Total option bytes= 40, padded length=40
   Record route:
   rtr01-01-fe3-0-0.provider.net (198.78.137.1)
   (63.100.219.93)
   (63.100.219.94)
   (63.100.219.94)
   gw2.customer.net (63.100.218.202)
   rtr18.otherisp.net (63.100.218.201) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 620/620/620 ms