A better solution is to set up a perfsonar node for customers to ping and speed test against. http://psps.perfsonar.net/toolkit/
And then educate them on traceroute and other available tools. We severely rate limit ping and ttl expired to (not through) our core devices as do many major carriers. Some carriers are using private addressing on their backbone devices which effectively makes them invisible to traceroute and you get * * * for them. The solution is really education and dedicated tools not opening up ddos potential. I might add that some (who shall remain nameless) carriers prioritize icmp packets ahead of other traffic to hide congestion. Ie. regular traffic gets QOS 0 and icmp gets QOS 4. You can be losing substantial TCP packets but your ICMP trace and ping will be totally clean. Mack McBride | Network Architect | ViaWest, Inc. -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Rimestad, Steinar Sent: Thursday, August 07, 2014 8:14 AM To: [email protected] Subject: Re: [c-nsp] Prioritize PING traffic to control plane We had one of our customers complaining about a similar issue using pingplotter/mtr to check for congestion and we tried educating him regarding this issue as has been mentioned here. We are using mls rate-limiting for ttl-failures and saw that one of our 7600/PE routers had reached it rate-limiting and increased this from the default 100/10 to 1000/25 just to shut up the customer. from mls rate-limit all ttl-failure 100 10 to mls rate-limit all ttl-failure 1000 25 Assuming you are on a Cisco platform and if you have a similar configuration setup you might be able to increase this without actually prioritizing this traffic to the control-plane. Check if you are hitting any limits with: show mls rate-limit usage show ip icmp rate-limit // Steinar On 07/08/14 11:24, "Dumitru Ciobarcianu" <[email protected]> wrote: >On 07-Aug-14 11:23 AM, Roland Dobbins wrote: >> >> On Aug 7, 2014, at 3:15 PM, Dumitru Ciobarcianu <[email protected]> >>wrote: >> >>> Yes, I agree, I was just saying that I think I know his X [1] :) >> >> Sure - the best way to deal with this is to set up some anycasted >>ping target nodes numbered out of TEST-NET space around the network, >>and tell them to point whatever they're using at that. >> > >The customer is pointing the tool to a remote server they have, we >cannot just tell them to test a node they do not care about. The >problem is not the tool or where they test, the problem is the way the >customer is interpreting the data. > >I know someone who at some point filtered icmp entirely from the >customer's networks because of this and convinced the troublemakers >that "they are more secure that way". The customer was happy because he >was getting a consistent graph... > >Dumitru > >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
