[136306] in North American Network Operators' Group
Re: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Rubens Kuhl)
Wed Feb 2 09:15:10 2011
In-Reply-To: <FA100E21-3F2C-4543-B6C0-CADB41942AFC@gmail.com>
Date: Wed, 2 Feb 2011 12:15:05 -0200
From: Rubens Kuhl <rubensk@gmail.com>
To: Steve Danelli <the76posse@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
CTBC has capacity from GBLX, TIWS and SEABONE, although not all
prefixes are announced to all providers. TIWS usual path in the US is
thru Level 3, so steering the traffic to Level 3 might do the trick.
Rubens
On Wed, Feb 2, 2011 at 11:08 AM, Steve Danelli <the76posse@gmail.com> wrote=
:
> Thanks Vinny - how did you route around? =A0 There seems to be one path f=
rom the US to Brazil via GBLX and CTBC. =A0 =A0Are you leveraging leased co=
nnectivity? =A0 Thanks for the info!!
>
> SD
>
> Sent from my iPhone
>
> On Feb 2, 2011, at 1:21 AM, Vinny Abello <vinny@abellohome.net> wrote:
>
>> We saw similar issues with IKE through Global Crossing (as odd as that s=
ounds) out of the NYC market at the same time. We routed around them and pr=
oblem solved. Still scratching our heads on that one... In my experiences, =
GLBX has numerous odd issues to the point where it's become a bad joke anyt=
ime something breaks with connectivity... we blame them. It's kind of not f=
unny though because it's almost always true. Taking them out of the equatio=
n usually fixes the problem. One of our customers who is frequently affecte=
d by GBLX problems jumps to the (often correct) conclusion that they are ca=
using problems. :-/
>>
>> -Vinny
>>
>> On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote:
>>
>>> Thanks for the response.
>>>
>>> Ike had worked great up until Monday. =A0The provider did a local test =
and our box saw the Ike packets so it appears to lie somewhere upstream. =
=A0(GLBX may be a good guess)
>>>
>>> Also - the paths are stable and we are sourcing from the same ip - very=
strange behaivor. =A0 =A0Hope someone from GLBX or CTBC (or someone who ha=
d experienced an issue like this) can assist
>>>
>>>
>>> Thanks to all for their feedback so far.
>>>
>>> SD
>>>
>>> On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks@vt.edu wrote:
>>>
>>>> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said:
>>>>
>>>>> Some carrier, somewhere between us and the service provider is select=
ively
>>>>> dropping the IKE packets originating from our VPN gateway and destine=
d for
>>>>> our Brazil gateway. Other traffic is able to pass, as are the IKE pac=
kets coming
>>>>> back from Brazil to us. This is effectively preventing us from establ=
ishing
>>>>> the IPSEC tunnel between our gateways.
>>>>
>>>> Has IKE been known to work to that location before? Or is this somethi=
ng new?
>>>> My first guess is some chucklehead banana-eater at the service provide=
r either
>>>> fat-fingered the firewall config, or semi-intentionally blocked it bec=
ause it
>>>> was "traffic on a protocol/port number they didn't understand so it mu=
st be
>>>> evil".
>>>>
>>>>> Also something else is awry, for two given hosts on the same subnet (=
x.y.z.52
>>>>> and x.y.z.53), they take two wildly divergent paths:
>>>>
>>>>> Anyone have any insight on to what may be occurring?
>>>>
>>>> The paths appear to diverge at 67.16.142.238. =A0I wonder if that's ge=
ar trying
>>>> to do some load-balancing across 2 paths, and it's using the source IP=
as a
>>>> major part of the selector function ("route to round-robin interface s=
ource-IP
>>>> mod N" or similar?).
>>>>
>>>> The other possibility is your two traceroutes happened to catch a rout=
ing flap in
>>>> progress (obviously not the case if the two routes are remaining stabl=
e).
>>>>
>>>> Sorry I can't be more helpful than that...
>>>
>>
>
>
