UDP clamped on service provider links

Jon Lewis jlewis at lewis.org
Fri Jul 31 15:52:04 UTC 2015


On Fri, 31 Jul 2015, Christopher Morrow wrote:

> On Fri, Jul 31, 2015 at 8:07 AM, John Kristoff <jtk at cymru.com> wrote:
>> On Thu, 30 Jul 2015 21:18:10 -0500
>> Jason Baugher <jason at thebaughers.com> wrote:
>>
>>> In one case, when we were having an issue with a SIP trunk, we
>>> re-numbered our end to another IP in the same subnet. Same path from
>>> A to Z, but the packet loss mysteriously disappeared using the new
>>> IP. It sure seems like they are throttling somewhere.
>>
>> Not knowing how you evaluated the two paths, but if MPLS was not
>> considered, it may have perhaps been due in part to ECMP behavior.
>> While not ruling out UDP limits, it is plausible that the changed
>> source IP address resulted in a less congested path to be chosen.
>
> ding! this sounds like the most plausible answer... I wouldn't expect
> L3 to limit udp/5060/6061/SIP traffic, as a common carrier that also
> runs a SIP trunking service they:

Jason said it was the RTP traffic that was lossy over L3...so that's not 
UDP/5060, but [at least commonly] UDP/10000:20000.  i.e. to a network 
engineer trying to harden the network against DDoS attacks, just random 
UDP traffic.  Someone writing a stateless UDP filter/policer not thinking 
about RTP might easily implement a filter that doesn't allow all RTP 
packets to pass.


----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



More information about the NANOG mailing list