[130295] in North American Network Operators' Group
Re: BGP next-hop
daemon@ATHENA.MIT.EDU (Christian Martin)
Thu Sep 30 20:18:49 2010
In-Reply-To: <m239sqzzdk.wl%randy@psg.com>
From: Christian Martin <christian.martin@teliris.com>
Date: Thu, 30 Sep 2010 20:17:45 -0400
To: Randy Bush <randy@psg.com>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 30, 2010, at 5:37 PM, Randy Bush <randy@psg.com> wrote:
> i was recently bitten by a cousin of this
>=20
> research router getting an ebgp multi-hop full feed from 147.28.0.1
> (address is relevant)
>=20
> it is on a lan with a default gateway 42.666.77.11 (address not
> relevant), so it has
>=20
> ip route 0.0.0.0 0.0.0.0 42.666.77.11
>=20
> massive flapping results. =20
>=20
> it seems it gets the bgp route for 147.28.0.0/16 and then can not
> resolve the next hop. it would not recurse to the default exit.
>=20
> of course it was solved by
>=20
> ip route 147.28.0.0 255.255.0.0 42.666.77.11
>=20
> but i do not really understand in my heart why i needed to do this.
>=20
Looks like a classic race condition, in that 147.28/16, upon arrival, become=
s a better route for the recursed next-hop (which really is a recursed looku=
p on your default) So you get
147.28/16 -> 147.28.0.1, and then 147.28.0.1 looks best through the learned r=
oute.
Of course, this would appear to be a matter of how it is implemented. Becau=
se in fact, the 147 route isn't yet in the routing table, so your default sh=
ould apply. The static seems to force a recursion to the 666 nh. =20
I'll wait for your friend to send the implementation details, but from a gla=
nce, it looks like a defensive (lazy?) attempt to avoid a recursion loop dur=
ing the update receive process.
Btw, this will happen on a Juniper (or at least it used to). I'll have to c=
heck to confirm.
Chris
> randy
>=20
