[130294] in North American Network Operators' Group
Re: BGP next-hop
daemon@ATHENA.MIT.EDU (Brett Watson)
Thu Sep 30 20:01:21 2010
From: Brett Watson <brett@the-watsons.org>
In-Reply-To: <m2bp7eyebj.wl%randy@psg.com>
Date: Thu, 30 Sep 2010 17:01:11 -0700
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 30, 2010, at 4:57 PM, Randy Bush wrote:
>>> 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
>>> ip route 147.28.0.0 255.255.0.0 42.666.77.11
>>> but i do not really understand in my heart why i needed to do this.
>>=20
>> Neither do I, Randy.
>=20
> a good friend at cisco says he will take the time to write up why in =
the
> next day or two.
Only thing I can guess from the Cisco doc that says:
"To prevent the creation of loops through oscillating routes, the =
multihop will not be established if the only route to the multihop peer =
is the default route (0.0.0.0)."
Is that they think they're saving you from shooting yourself in the =
foot, if you learn the route to 147.28.0.0/16 via BGP (which your =
multihop peer address falls in), yet you have a default route of =
0.0.0.0? But then you'd simply recursively look up the FIB route to the =
next hop in BGP... so I still don't get it.
-b=
