[136312] in North American Network Operators' Group
RE: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Matt Disuko)
Wed Feb 2 09:29:47 2011
From: Matt Disuko <gourmetcisco@hotmail.com>
To: NANOG <nanog@nanog.org>, <the76posse@gmail.com>
Date: Wed, 2 Feb 2011 09:22:59 -0500
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Algar looking Glass:
http://lg.ctbc.com.br/lg/
I found the response from the GC engineer. It won't mean much cut&pasted v=
erbatim and out of context=2C so I'll just summarize.
Basically=2C I was seeing vastly different response times to given hosts in=
the same subnet on CTBC's network. My source ip was the same. Traceroute=
revealed to me the packets taking different paths=2C after hitting a parti=
cular GLBX router.
The GC engineer said CTBC is a customer that hangs off of this particular r=
outer=2C and that traffic was hitting an interface and hair-pinning back ou=
t to the customer's segment. He pointed to possible congestion on CTBCs sw=
itching fabric as the cause for the varied response times (conceivable) and=
different routes (um...ok maybe some kind of load-balancing at play).
I managed to call CTBC (Algar) and confirmed they were experiencing congest=
ion issues and they had a scheduled circuit capacity upgrade with GLBX in a=
few weeks.
As a network admin=2C i find it sometimes sadly humorous how we can poke an=
d prod at a problem=2C go through various carrier support channels and scra=
tch our heads for hours/days when all it would normally take is a RO userid=
on a couple routers in the path to figure things out. that's not too much=
to ask=2C right? =3B)
-matt
> CC: vinny@abellohome.net=3B nanog@nanog.org
> From: the76posse@gmail.com
> Subject: Re: Connectivity to Brazil
> Date: Wed=2C 2 Feb 2011 08:07:14 -0500
> To: gourmetcisco@hotmail.com
>=20
> That thread detail would be very interesting to me. Thanks for the heads=
up. =20
>=20
> Sent from my iPhone
>=20
> On Feb 2=2C 2011=2C at 7:14 AM=2C Matt Disuko <gourmetcisco@hotmail.com> =
wrote:
>=20
> > Very interesting. I have had similar issues with connectivity to my Br=
azil office=2C and oddly enough it involved GBLX and CTBC (now called Algar=
Telecom). I also vastly divergent paths to a couple hosts in the same sub=
net. I ended up communicating with GBLX via email (who were actually reall=
y great in corresponding with me)...the engineer pointed to some sort of l=
ink capacity issue...i'll dig up the thread...
> >=20
> > > 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 tha=
t sounds) out of the NYC market at the same time. We routed around them and=
problem solved. Still scratching our heads on that one... In my experience=
s=2C GLBX 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 eq=
uation usually fixes the problem. One of our customers who is frequently af=
fected by GBLX problems jumps to the (often correct) conclusion that they a=
re causing 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=
and 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 - =
very strange behaivor. Hope someone from GLBX or CTBC (or someone who had e=
xperienced 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 =
selectively
> > > >>> dropping the IKE packets originating from our VPN gateway and des=
tined for
> > > >>> our Brazil gateway. Other traffic is able to pass=2C as are the I=
KE packets coming
> > > >>> back from Brazil to us. This is effectively preventing us from es=
tablishing
> > > >>> the IPSEC tunnel between our gateways.
> > > >>=20
> > > >> Has IKE been known to work to that location before? Or is this som=
ething new?
> > > >> My first guess is some chucklehead banana-eater at the service pro=
vider either
> > > >> fat-fingered the firewall config=2C or semi-intentionally blocked =
it because it
> > > >> was "traffic on a protocol/port number they didn't understand so i=
t must be
> > > >> evil".
> > > >>=20
> > > >>> Also something else is awry=2C for two given hosts on the same su=
bnet (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 g=
ear trying
> > > >> to do some load-balancing across 2 paths=2C and it's using the sou=
rce IP as a
> > > >> major part of the selector function ("route to round-robin interfa=
ce source-IP
> > > >> mod N" or similar?).
> > > >>=20
> > > >> The other possibility is your two traceroutes happened to catch a =
routing flap in
> > > >> progress (obviously not the case if the two routes are remaining s=
table).
> > > >>=20
> > > >> Sorry I can't be more helpful than that...
> > > >=20
> > >=20
> > >=20
=
