[c-nsp] Prioritize PING traffic to control plane

[Mack McBride]

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:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rimestad, Steinar
Sent: Thursday, August 07, 2014 8:14 AM
To: cisco-nsp at puck.nether.net
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" <cisco-nsp at lnx.ro> wrote:

>On 07-Aug-14 11:23 AM, Roland Dobbins wrote:
>> 
>> On Aug 7, 2014, at 3:15 PM, Dumitru Ciobarcianu <cisco-nsp at lnx.ro>
>>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  cisco-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/