[146361] in North American Network Operators' Group
Re: Anyone seen this kind of problem? SIP traffic not getting to
daemon@ATHENA.MIT.EDU (Blake Hudson)
Wed Nov 9 17:45:25 2011
Date: Wed, 09 Nov 2011 16:45:15 -0600
From: Blake Hudson <blake@ispn.net>
CC: NANOG <nanog@nanog.org>
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Jay Nakamura wrote the following on 11/9/2011 12:47 PM:
> We ran into a strange situation yesterday that I am still trying to
> figure out. We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
>
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine. I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
>
> ...
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs? That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state? I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>
I've found tools like tcptraceroute (the name is deceiving, UDP is the
default) and hping to be invaluable in tracking down issues like these
that are obviously above the routing and into the transport layer.
I'm not sure how an IP transit provider (who should be providing
routing/switching) screws up transport layer connections - looks like
they are arbitrarily "managing" client data. Just my $0.02.
--Blake
