[136158] in North American Network Operators' Group
Re: Connectivity to Brazil
daemon@ATHENA.MIT.EDU (Steve Danelli)
Tue Feb 1 15:58:27 2011
In-Reply-To: <33104.1296591593@localhost>
From: Steve Danelli <the76posse@gmail.com>
Date: Tue, 1 Feb 2011 15:57:10 -0500
To: "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Thanks for the response. =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)
Also - the paths are stable and we are sourcing from the same ip - very stra=
nge behaivor. Hope someone from GLBX or CTBC (or someone who had experien=
ced an issue like this) can assist
Thanks to all for their feedback so far. =20
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:
>=20
>> Some carrier, somewhere between us and the service provider is selectivel=
y
>> dropping the IKE packets originating from our VPN gateway and destined fo=
r
>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets=
coming
>> back from Brazil to us. This is effectively preventing us from establishi=
ng
>> the IPSEC tunnel between our gateways.
>=20
> Has IKE been known to work to that location before? Or is this something n=
ew?
> My first guess is some chucklehead banana-eater at the service provider ei=
ther
> fat-fingered the firewall config, or semi-intentionally blocked it because=
it
> was "traffic on a protocol/port number they didn't understand so it must b=
e
> 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 try=
ing
> 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 sourc=
e-IP
> mod N" or similar?).
>=20
> The other possibility is your two traceroutes happened to catch a routing f=
lap in
> progress (obviously not the case if the two routes are remaining stable).
>=20
> Sorry I can't be more helpful than that...
