On Mon, Nov 04, 2013 at 10:36:39AM -0600, Adam Thompson wrote:
> On 13-11-03 02:27 PM, Loïc BLOT wrote:
> >then to explain my draft here is my own configuration, and why it could
> >be useful to set custom priorities:
> >[...]
> >Without the possibility to change the priorities (and dynamically is
> >better than recompile the kernel and change constant values, it would be
> >a great function to everybody want), it's impossible to solve this
> >routing loop (i have patched ospfd to refuse adding some specific routes
> >from specific hosts but it's not a proper solution, whereas it
> >worked...).
> 
> FWIW, I agree with Loïc on this; a router administrator should be
> able to have fine-grained control over route preference.
> 
> I've run into this in the past, where in a strange topology I wound
> up with a router (not OpenBSD) learning the same route via EIGRP,
> OSPF and BGP - each with a different next-hop.  Only one of those
> used the preferred (low-latency, high-bandwidth) path, I don't
> recall which, but we did have to manually adjust the local
> preference of one of the protocols in order to make it "win".
> 
> Policy routing would not (could not) have solved the problem, since
> it was all dynamic routes.
> 
> I'm about to re-build something similar, actually, using BGP and
> OSPF (or possibly BGP and static routes), where I will need the
> ability to control which routing protocol takes precedence.  I'll
> have a route learned via BGP that I want used first, and a route
> learned by OSPF that I want used only if the BGP route vanishes.
> (It's a partial overlay network, with backup link over VPN to
> maintain control functions in the case of an outage on the main link
> which talks BGP to its peer.)
> 
> However... in reading route(8), I see the "-priority" flag exists.
> Delving a bit deeper into .../net/route.h, I see that the routing
> table *already has* exactly the support I need (and that I think
> Loïc needs) in "rt_priority" and the associated macros.
> 
> The change I think we're both asking for is that in
> .../usr/sbin/bgpd/kroute.c, on line 505 (5.4-RELEASE), where we see
> "kr->r.priority = RTP_BGP;",  we need a way to override that value
> in (presumably) bgpd.conf.  (Ditto for the IPv6 function.)

Yes, this is the way to go. One thing to consider in some way is what you
want to do if somebody changes the prio and the reloads the config.
I think bgpd would need to do something similar to:
bgpctl fib decouple
change prio
bgpctl fib couple
 
> Similarly, in .../usr/sbin/ospfd/kroute.c:257, where we have
> "kn->r.priority = RTP_OSPF;", and presumably the same sort of thing
> in routed(8), ripd(8), ospf6d(8), possibly even ldpd(8)...

ldpd is a special beast and does not need to be changed but the other
should be. (routed is dead, ripd ospfd and ospf6d all use a similar
kroute.c file that also is used by bgpd so once one is done the others
should be easier). ldpd does not insert new routes it only extends them
with the MPLS info.

> I believe all the support we need is already in the kernel, what we
> lack is a user-exposed knob to fiddle with those (for now) constant
> values.  I believe they should be default values, not constant
> values.

Yes, there is one annoying bug left in the kernel that I will fix in the
near future. You can assume the kernel has all the knowledge you need.
 
> I believe it is possible to work around this problem currently with
> "route change", but doing so is a very, very ugly idea (worse in
> Loïc's case than mine, I think).  You'd have to have a script/daemon
> of your own watching the output from "route monitor" and executing
> "route change" every time a route gets inserted with the wrong
> priority.  This leads to much duplication of routing logic, since
> the correct route is not always known a priori.

Please someone not as overworked as me should just add the knobs to the
routing deamons to allow setting a different prio. For example just a
simple:
        fib-priority 45
would work.

-- 
:wq Claudio

Reply via email to