[111968] in North American Network Operators' Group
Re: anyone else seeing very long AS paths?
daemon@ATHENA.MIT.EDU (German Martinez)
Tue Feb 17 17:24:14 2009
Date: Tue, 17 Feb 2009 17:31:49 -0500
From: German Martinez <gmartine@ajax.opentransit.net>
To: Rodney Dunn <rodunn@cisco.com>
In-Reply-To: <20090217201157.GP17200@rtp-cse-489.cisco.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue Feb 17, 2009, Rodney Dunn wrote:
Hello Rodney,
It will be great if you can share with us your findings. It seems
like we are hitting different bugs in different platforms.
Thanks
German
> Ivan,
>=20
> It is confusing but from what I have tested you have it correct.
>=20
> The confusing part comes from multiple issues.
>=20
> a) The documentation about the default maxas limit being 75 appears to be
> incorrect. I'll get that fixed.
>=20
> b) Prior to CSCee30718 there was a hard limit of 255. After that fix
> AS sets of more than 255 should work.
>=20
> c) CSCeh13489 implemented the maxas command to mark it as invalid and
> not send.
>=20
>=20
> There does appear to be an issue when you cross the 255 boundary
> and the next hop router sends a notification back.
>=20
> I've got it recreated in the lab and we are working to clearly understand
> why that is. I'll post an update once we have more.
>=20
> The way to prevent it is the upstream device that crosses the 255 boundary
> on sending needs to use the maxas limit command to keep it less than 255.
>=20
> It doesn't work on the device that receives the update with the AS path
> larger than 255.
>=20
> Rodney
>=20
> On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote:
> > > We were dropping ALL prefixes and the eBGP session was still=20
> > > resetting.=20
> >=20
> > Upstream or downstream?
> >=20
> > > 1) "bgp maxas-limit 75" had no effect mitigating this problem=20
> > > on the IOS we were using. That is: it was previously verified=20
> > > to be working just fine to drop paths longer than 75, but=20
> > > once we started receiving paths >
> > > 255 then BGP started resetting.
> >=20
> > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC.=
The
> > paths were generated by Quagga BGP daemon.
> >=20
> > 12.2SRC causes the downstream session to break when the installed AS-pa=
th
> > length is close to 255 and you use downstream AS-path prepending.
> >=20
> > In your case, I'm assuming you were hit with an older bug (probably at =
the
> > 128 AS-path length boundary). It would be very hard to generate just the
> > right AS-path length to unintentionally break your upstream EBGP sessio=
n (as
> > I said before, it's a nice targeted attack if you know your downstream
> > topology).
> >=20
> > If your IOS is vulnerable to the older bugs that break inbound processi=
ng of
> > AS paths longer than 128, there's nothing you can do on your end. The
> > internal BGP checks reject the inbound update before the inbound filter=
s (or
> > bgp maxas-limit) can touch it and reset the upstream BGP session.
> >=20
> > Hope this helps
> > Ivan
> >=20
> > Disclaimer: as I don't have internal access to Cisco, all of the above =
is a
> > result of lab tests.
> >=20
--OgqxwSJOaUobr8KG
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmbOtUACgkQg3JAVb2nAOPkIgCdGZ1Gbjo9JD+S2PjL3FRQSla7
sIgAn2/sjvHnFYWzLFU38gskVI3yc8D+
=7n3V
-----END PGP SIGNATURE-----
--OgqxwSJOaUobr8KG--
