On Fri, Jul 05, 2002 at 05:26:12PM -0700, Robert O'Hara wrote:
> Hi Richard - I've encountered this question before, and as I recall, if
> you set local preference at the group and neighbor level, it will only
> work with IBGP routes (group type or neighbor type 'internal') as EBGP
> routes do not carry a local-pref attribute (it's a non-transitive
> attribute). So, it is not true that the group or neighbor statement
> isn't working properly, i.e. not a bug.
So in other words, you are saying that this command only sets the value
for outbound routes to IBGP, and there is no command for setting the
local-pref on routes learned from EBGP to anything other than the default
of 100?
I'd call this a design flaw myself. There are many reasons you would want
to set the default localpref on routes received from EBGP peers, for
example based on the type of peer (private peer, public peer, transit,
backup transit, depref'd peer, etc), all of which make far more sense to
set at the neighbor and/or group level than to make a policy statement
with a bunch of "from neighbor" terms.
On the other hand, I can't think of a single good reason you would want to
set the localpref on outgoing routes to IBGP peers from anything other
than a policy-statement, and only rarely at that. The neighbor
local-preference statement doesn't even give you the add/subtract
functionality of the policy-statement, basically making it completely
useless in an IBGP role.
> I recognize it's cumbersome to assign local pref on a per neighbor
> basis, but you should be able to set it within a group type internal,
> define all of your internal neighbors within that group, and the route
> should be set with the desired local-pref. Can you give that a try?
Most networks set a consistant policy of localprefs once, based on the
type of connection as I indicated above. Then when those routes get
propogated to the rest of the network, there is almost no reason to change
the routes based on which IBGP peer they go over, and the few reasons
which do exist would want the do additive or subtractive, not absolute
values with no matching control.
What you are suggesting would only make sense if you had a dedicated
border router for every type of peer (ex: one for peers, one for
transits, etc), and then set the values on their way out to the rest of
the network.
Whoever came up with this feature got it backwards. :)
-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:36 EDT