[136300] in North American Network Operators' Group
Re: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Steve Danelli)
Wed Feb 2 08:12:41 2011
In-Reply-To: <C6A12CAB-EEAF-49E8-9983-74485D446078@abellohome.net>
From: Steve Danelli <the76posse@gmail.com>
Date: Wed, 2 Feb 2011 08:08:50 -0500
To: Vinny Abello <vinny@abellohome.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Thanks Vinny - how did you route around? There seems to be one path from t=
he US to Brazil via GBLX and CTBC. Are you leveraging leased connectivity=
? 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 sou=
nds) out of the NYC market at the same time. We routed around them and probl=
em 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 anytime s=
omething breaks with connectivity... we blame them. It's kind of not funny t=
hough because it's almost always true. Taking them out of the equation usual=
ly fixes the problem. One of our customers who is frequently affected by GBL=
X problems jumps to the (often correct) conclusion that they are causing pro=
blems. :-/
>=20
> -Vinny
>=20
> On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote:
>=20
>> Thanks for the response. =20
>>=20
>> Ike had worked great up until Monday. The provider did a local test and o=
ur box saw the Ike packets so it appears to lie somewhere upstream. (GLBX m=
ay be a good guess)
>>=20
>> Also - the paths are stable and we are sourcing from the same ip - very s=
trange behaivor. Hope someone from GLBX or CTBC (or someone who had exper=
ienced an issue like this) can assist
>>=20
>>=20
>> Thanks to all for their feedback so far. =20
>>=20
>> SD
>>=20
>> On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks@vt.edu wrote:
>>=20
>>> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said:
>>>=20
>>>> Some carrier, somewhere between us and the service provider is selectiv=
ely
>>>> dropping the IKE packets originating from our VPN gateway and destined f=
or
>>>> our Brazil gateway. Other traffic is able to pass, as are the IKE packe=
ts coming
>>>> back from Brazil to us. This is effectively preventing us from establis=
hing
>>>> the IPSEC tunnel between our gateways.
>>>=20
>>> Has IKE been known to work to that location before? Or is this something=
new?
>>> My first guess is some chucklehead banana-eater at the service provider e=
ither
>>> fat-fingered the firewall config, or semi-intentionally blocked it becau=
se it
>>> was "traffic on a protocol/port number they didn't understand so it must=
be
>>> evil".
>>>=20
>>>> 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:
>>>=20
>>>> Anyone have any insight on to what may be occurring?
>>>=20
>>> The paths appear to diverge at 67.16.142.238. I wonder if that's gear t=
rying
>>> to do some load-balancing across 2 paths, and it's using the source IP a=
s a
>>> major part of the selector function ("route to round-robin interface sou=
rce-IP
>>> mod N" or similar?).
>>>=20
>>> The other possibility is your two traceroutes happened to catch a routin=
g flap in
>>> progress (obviously not the case if the two routes are remaining stable)=
.
>>>=20
>>> Sorry I can't be more helpful than that...
>>=20
>=20
