In addition to that a lot of platforms, such as Catalyst switches perform packet forwarding in hardware by ASICs and linecards can make forwarding decisions, so pinging the switch/router/MLS might not be accurate at all due to special configs on the ingress/egress interface. Also, the CPU in the switch might not be as powerful as one in a server therefore it will exhibit more latency.
Also, to discuss something about the initial question, on Nexus 7000 switches, CoPP can be enabled in the initial setup and it's commonly used. However, one might forget about it and ping the N7k switch from another smaller switch with a high packet rate and find packet loss, although it is expected due to CoPP. Best regards, Andras On Wed, Aug 24, 2011 at 2:02 PM, Arie Vayner (avayner) <avay...@cisco.com> wrote: > Actually, if you are a customer, and want to measure your upstream > quality, pinging the router is not the right thing to do anyway... It > tests nothing except the direct next hop. > > You should most likely have an integrated monitoring scheme: > - Ping the upstream router > - Ping some other devices which are upstream > - Run a DNS probe to 2-3 DNS servers > - Run an HTTP probe to 10-15 common web services > > Then you can use the different metrics to see if something has changed > compared to the established baseline. > Without having a baseline, the absolute numbers mean nothing... > > Arie > > -----Original Message----- > From: cisco-nsp-boun...@puck.nether.net > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku Ytti > Sent: Wednesday, August 24, 2011 14:31 > To: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] reliability of ping to router physical-, sub- or > loopback interface > > On (2011-08-24 12:03 +0200), Benny Amorsen wrote: > >> So please, router vendors, make ICMP ECHO fast and reliable. > > I guess it could be nifty to offload this to NPU, and probably most > modern NPU like EZchip and trio could do it. > > However it is unclear to me what are the benefits, ICMP does not provide > one-way delay measurements, for this you'd need to have IP SLA and > timestamping in hardware, this is seems much more useful goal to me. > > If for NMS purpose you wish to measure customer experienced quality and > you don't care about one-way delay/jitter, you can already today 'loop' > packets in hardware via given destination router, by jumping between > VRF/VRF or VRF/global table. So NMS would send ping packet out, and > would receive it on another VLAN, router would hardware switch it > delivering realistic delay/jitter measurements. > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
