[136298] in North American Network Operators' Group
Re: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Steve Danelli)
Wed Feb 2 08:08:19 2011
In-Reply-To: <BLU156-w2273BACCD8C889DFE6511BC9E40@phx.gbl>
From: Steve Danelli <the76posse@gmail.com>
Date: Wed, 2 Feb 2011 08:07:14 -0500
To: Matt Disuko <gourmetcisco@hotmail.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
That thread detail would be very interesting to me. Thanks for the heads up=
. =20
Sent from my iPhone
On Feb 2, 2011, at 7:14 AM, Matt Disuko <gourmetcisco@hotmail.com> wrote:
> Very interesting. I have had similar issues with connectivity to my Brazi=
l office, and oddly enough it involved GBLX and CTBC (now called Algar Telec=
om). 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 great i=
n corresponding with me)...the engineer pointed to some sort of link capaci=
ty issue...i'll dig up the thread...
>=20
> > Date: Wed, 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 s=
ounds) 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, GL=
BX has numerous odd issues to the point where it's become a bad joke anytime=
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 equation usu=
ally fixes the problem. One of our customers who is frequently affected by G=
BLX problems jumps to the (often correct) conclusion that they are causing p=
roblems. :-/
> >=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 an=
d our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX=
may be a good guess)
> > >=20
> > > Also - the paths are stable and we are sourcing from the same ip - ver=
y strange 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 selec=
tively
> > >>> dropping the IKE packets originating from our VPN gateway and destin=
ed for
> > >>> our Brazil gateway. Other traffic is able to pass, as are the IKE pa=
ckets coming
> > >>> back from Brazil to us. This is effectively preventing us from estab=
lishing
> > >>> the IPSEC tunnel between our gateways.
> > >>=20
> > >> Has IKE been known to work to that location before? Or is this someth=
ing new?
> > >> My first guess is some chucklehead banana-eater at the service provid=
er either
> > >> fat-fingered the firewall config, or semi-intentionally blocked it be=
cause it
> > >> was "traffic on a protocol/port number they didn't understand so it m=
ust 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=
trying
> > >> to do some load-balancing across 2 paths, and it's using the source I=
P 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 rou=
ting flap in
> > >> progress (obviously not the case if the two routes are remaining stab=
le).
> > >>=20
> > >> Sorry I can't be more helpful than that...
> > >=20
> >=20
> >=20
