christian.martin at teliris.com
Thu Sep 30 19:17:45 CDT 2010
On Sep 30, 2010, at 5:37 PM, Randy Bush <randy at psg.com> wrote:
> i was recently bitten by a cousin of this
> research router getting an ebgp multi-hop full feed from 22.214.171.124
> (address is relevant)
> it is on a lan with a default gateway 42.666.77.11 (address not
> relevant), so it has
> ip route 0.0.0.0 0.0.0.0 42.666.77.11
> massive flapping results.
> it seems it gets the bgp route for 126.96.36.199/16 and then can not
> resolve the next hop. it would not recurse to the default exit.
> of course it was solved by
> ip route 188.8.131.52 255.255.0.0 42.666.77.11
> but i do not really understand in my heart why i needed to do this.
Looks like a classic race condition, in that 147.28/16, upon arrival, becomes a better route for the recursed next-hop (which really is a recursed lookup on your default) So you get
147.28/16 -> 184.108.40.206, and then 220.127.116.11 looks best through the learned route.
Of course, this would appear to be a matter of how it is implemented. Because in fact, the 147 route isn't yet in the routing table, so your default should apply. The static seems to force a recursion to the 666 nh.
I'll wait for your friend to send the implementation details, but from a glance, it looks like a defensive (lazy?) attempt to avoid a recursion loop during the update receive process.
Btw, this will happen on a Juniper (or at least it used to). I'll have to check to confirm.
More information about the NANOG