[32908] in North American Network Operators' Group
RE: Pinging routers for network status
daemon@ATHENA.MIT.EDU (Matt Levine)
Mon Dec 18 04:15:14 2000
From: "Matt Levine" <mlevine@efront.com>
To: <nanog@merit.edu>
Date: Mon, 18 Dec 2000 01:12:17 -0800
Message-ID: <BEEPLMELPMPANJHCBHJEOEAMFGAA.mlevine@efront.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <g3puiqqho2.fsf@redpaul.mfnx.net>
Errors-To: owner-nanog-outgoing@merit.edu
Well, although there's no entirely fool-proof way, We've found a better way
of monitoring "real" outages/issues is to monitor the time required to setup
a tcp connection to some "trusted" machines. For example, in our VA
datacenter we monitor the time required to setup a connection with tier1
providers (UU,BBN,DIGEX for example) nameservers (on port 53).. We've found
it slightly more reliable than ICMP reqs, especially since when routers get
busy, it shows as degradation vs. outage.
Matt
--
Matt Levine, CTO <mlevine@efront.com>
eFront Media, Inc. - http://www.efront.com
Phone: +1 714 428 8500 ext. 504
Fax : +1 949 203 2156
ICQ : 17080004
-----Original Message-----
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
Paul Vixie
Sent: Monday, December 18, 2000 12:04 AM
To: nanog@merit.edu
Subject: Re: Pinging routers for network status
sean@donelan.com (Sean Donelan) writes:
> Most network providers ping their routers for network status. Several
> providers even track RTT to detect changes. But very few customers
> connect to routers. Comparing the performance you see with HP Openview
> or similar products with the performance customers see remains an
> interesting question. Sometimes C&W's or AT&T's traffic web site does
> show a problem. But there are also problems that don't show up in
> intra-network pings. In particular IGP/BGP routing issues can result
> in severe access network problems, but no problem with the internal
> provider network mesh used for pings.
Similarly, long or deviant ping times against a router can just indicate
that it was processing a routing update when it got your ICMP_ECHO request.
Therefore the RTT isn't nec'ily indicative of link latency. (SNMP is
worse.)
If you want to know how fast your network is, send a normal payload. Even
source routing will variously have to be "processor switched" or otherwise
escape the "fast path" on many modern routers. Ping and Traceroute are for
when you already know you're screwed, but you're trying to prove it to other
people or you're trying to draw finer distinctions. When the network isn't
failing, Ping and Traceroute tell you pretty much nothing.
Of course, using normal payloads to measure network health requires agents
on the far side, and thus, is a more difficult design and deployment
problem.
(If you don't think of this as a hard problem, you're not doing it right.)
