[130324] in North American Network Operators' Group
Re: BGP next-hop
daemon@ATHENA.MIT.EDU (Heath Jones)
Fri Oct 1 07:17:03 2010
In-Reply-To: <3E7810CF-BF6F-4D72-8313-88B84E5D19BD@acm.org>
Date: Fri, 1 Oct 2010 12:16:53 +0100
From: Heath Jones <hj1980@gmail.com>
To: "Smith W. Stacy" <stacy@acm.org>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> Section 9.1.2.1 of RFC 4271 seems to address this.
> A few points from that section:
> =A0- The BGP NEXT_HOP can not recursively resolve (directly or indirectly=
) through the BGP route.
> =A0- Only the longest matching route should be considered when resolving =
the BGP NEXT_HOP.
> =A0- Do not consider feasible routes that would become unresolvable if th=
ey were installed.
There are 2 ways of reading that.. Perhaps i'll go and look at the it
in more details.
I'm trying to think of a scenario where following this or something
similar would break it:
- Don't use BGP prefixes to resolve next-hop.
- You can use 0/0 or any route with a lower administrative distance to
resolve the next-top.
With that in mind, I wonder if it works with Juniper (ad =3D 170 vs 20
from memory)..
