[136292] in North American Network Operators' Group
RE: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Matt Disuko)
Wed Feb 2 07:14:36 2011
From: Matt Disuko <gourmetcisco@hotmail.com>
To: <vinny@abellohome.net>, <the76posse@gmail.com>
Date: Wed, 2 Feb 2011 07:14:30 -0500
In-Reply-To: <C6A12CAB-EEAF-49E8-9983-74485D446078@abellohome.net>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Very interesting. I have had similar issues with connectivity to my Brazil=
office=2C and oddly enough it involved GBLX and CTBC (now called Algar Tel=
ecom). I also vastly divergent paths to a couple hosts in the same subnet.=
I ended up communicating with GBLX via email (who were actually really gr=
eat in corresponding with me)...the engineer pointed to some sort of link =
capacity issue...i'll dig up the thread...
> Date: Wed=2C 2 Feb 2011 01:21:09 -0500
> From: vinny@abellohome.net
> Subject: Re: Connectivity to Brazil
> To: the76posse@gmail.com
> CC: nanog@nanog.org
>=20
> We saw similar issues with IKE through Global Crossing (as odd as that so=
unds) out of the NYC market at the same time. We routed around them and pro=
blem solved. Still scratching our heads on that one... In my experiences=2C=
GLBX has numerous odd issues to the point where it's become a bad joke any=
time something breaks with connectivity... we blame them. It's kind of not =
funny though because it's almost always true. Taking them out of the equati=
on usually fixes the problem. One of our customers who is frequently affect=
ed by GBLX problems jumps to the (often correct) conclusion that they are c=
ausing problems. :-/
>=20
> -Vinny
>=20
> On Feb 1=2C 2011=2C at 3:57 PM=2C Steve Danelli wrote:
>=20
> > Thanks for the response. =20
> >=20
> > Ike had worked great up until Monday. The provider did a local test an=
d our box saw the Ike packets so it appears to lie somewhere upstream. (GL=
BX may be a good guess)
> >=20
> > Also - the paths are stable and we are sourcing from the same ip - very=
strange behaivor. Hope someone from GLBX or CTBC (or someone who had ex=
perienced an issue like this) can assist
> >=20
> >=20
> > Thanks to all for their feedback so far. =20
> >=20
> > SD
> >=20
> > On Feb 1=2C 2011=2C at 3:19 PM=2C Valdis.Kletnieks@vt.edu wrote:
> >=20
> >> On Tue=2C 01 Feb 2011 08:54:47 EST=2C Steve Danelli said:
> >>=20
> >>> Some carrier=2C somewhere between us and the service provider is sele=
ctively
> >>> dropping the IKE packets originating from our VPN gateway and destine=
d for
> >>> our Brazil gateway. Other traffic is able to pass=2C as are the IKE p=
ackets coming
> >>> back from Brazil to us. This is effectively preventing us from establ=
ishing
> >>> the IPSEC tunnel between our gateways.
> >>=20
> >> 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=2C or semi-intentionally blocked it b=
ecause it
> >> was "traffic on a protocol/port number they didn't understand so it mu=
st be
> >> evil".
> >>=20
> >>> Also something else is awry=2C for two given hosts on the same subnet=
(x.y.z.52
> >>> and x.y.z.53)=2C 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=
trying
> >> to do some load-balancing across 2 paths=2C 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?).
> >>=20
> >> 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).
> >>=20
> >> Sorry I can't be more helpful than that...
> >=20
>=20
>=20
=
