Re: Re : Re: Improve routing functions
On 13-11-04 05:09 PM, Claudio Jeker wrote: On Mon, Nov 04, 2013 at 10:36:39AM -0600, Adam Thompson wrote: 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. Or, in bgpd.conf(8) note under fib-priority that Changes to fib-priority will only take effect when bgpd(8) is restarted. Yeah, not ideal, but better than nothing. 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. Yes, it's unfortunate that routed(8) got removed from base. RIPv2 is a perfectly workable routing protocol in many situations. Wow, I didn't realize it's been missing since 4.4-release! 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. I can do doc changes, but I think you really, *really* don't want me writing much C code... I can perhaps do some of the initial, trivial, legwork, at best. Now, if bgpd(8) were written in Bourne/Korn shell, I'd be the guy to do this! -- -Adam Thompson athom...@athompso.net
Re: Re : Re: Improve routing functions
On 13-11-05 10:12 AM, Adam Thompson wrote:
I can do doc changes, but I think you really, *really* don't want me
writing much C code... I can perhaps do some of the initial, trivial,
legwork, at best. Now, if bgpd(8) were written in Bourne/Korn shell,
I'd be the guy to do this!
I recall now that I've never used yacc... Here's what I *can*
contribute, which is not much.
I wonder about including it as a global, per-neighbour, and per-match,
but it seems to be consistent with what's already implemented.
It would be acceptable to have it only as an attribute;
It would be more reasonable to have it as a global config item and an
attribute;
And at that point it may as well be settable on a neighbour basis, too.
--
-Adam Thompson
athom...@athompso.net
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.129
diff -u -p -r1.129 bgpd.conf.5
--- bgpd.conf.5 19 Oct 2013 15:04:25 - 1.129
+++ bgpd.conf.5 5 Nov 2013 17:45:23 -
@@ -206,6 +206,14 @@ dump all out /tmp/all-out-%H%M 300
dump updates out /tmp/updates-out-%H%M 300
.Ed
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Xo
.Ic fib-update
.Pq Ic yes Ns | Ns Ic no
@@ -459,6 +467,14 @@ should be set to
.Ar rt
for best compatibility with other implementations.
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Xo
.Ic fib-update
.Pq Ic yes Ns | Ns Ic no
@@ -757,6 +773,14 @@ The default value for IBGP peers is
otherwise the default is
.Ic yes .
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Ic holdtime Ar seconds
Set the holdtime in seconds.
Inherited from the global configuration if not given.
@@ -1365,6 +1389,14 @@ bdc BGP Data Collection
.Pp
Not all type and subtype value pairs are allowed by IANA and the parser
will ensure that no invalid combination is created.
+.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
.Pp
.It Ic localpref Ar number
Set the
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.268
diff -u -p -r1.268 parse.y
--- parse.y 19 Oct 2013 15:04:25 - 1.268
+++ parse.y 5 Nov 2013 17:45:23 -
@@ -171,6 +171,7 @@ typedef struct {
%}
%token AS ROUTERID HOLDTIME YMIN LISTEN ON FIBUPDATE RTABLE
+%token FIBPRIORITY
%token RDOMAIN RD EXPORTTRGT IMPORTTRGT
%token RDE RIB EVALUATE IGNORE COMPARE
%token GROUP NEIGHBOR NETWORK
@@ -2139,6 +2140,7 @@ lookup(char *s)
{ evaluate, EVALUATE},
{ export-target, EXPORTTRGT},
{ ext-community, EXTCOMMUNITY},
+ { fib-priority, FIBPRIORITY},
{ fib-update, FIBUPDATE},
{ from, FROM},
{ group, GROUP},
Re: Re : Re: Improve routing functions
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.) 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)... 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. 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. -- -Adam Thompson athom...@athompso.net
Re: Re : Re: Improve routing functions
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
Re : Re: Improve routing functions
Hello, that's powerful but my improvement isn't for this use. It's only an improvement to route packets correctly, not dispatch charge. I'll give you a concrete example this evening. Loïc Blot, Ingénieur systèmes UNIX, Sécurité et Réseaux http://www.unix-experience.fr Stuart Henderson st...@openbsd.org a écrit : On 2013/11/01 19:57, sven falempin wrote: FreeBSD propose to have a specific routing table for a process, which is even more powerful. When the router has multiple gateway i guess when a source address is choose the route should be chosen given that. Nothing more. What use of this improvement do you imagine ?, of course you may want this traffic over this network(low latency) and the other one on another(high badnwith), put you may use pf for this, or specific route for the services. Writing about this make me think you want a route that select on the PORT instead of the IP. Is this madness ??? This is also known as policy based routing. I've being doing this with route-to in PF for ages, or alternatively you can use multiple route tables and rtable in PF to push certain traffic to using a certain table (either based on port number, or source address, or UID if it's a connection from the local machine, etc).
Re: Re : Re: Improve routing functions
Hi, then to explain my draft here is my own configuration, and why it could be useful to set custom priorities: OSPF Scheme: | - RT1 - | | - RT3 WAN | | OSPF AREA | | - RT2 - | | - RT4 RIP Scheme: | - RT1 - | WAN | | RIP AREA | - CISCO 45XX | - RT2 - | BGP Scheme: | - RT1 WAN | | - RT2 A first problem is my BGP default route, which was redistributed over OSPF, causes a looping route between RT1 and RT2 for outgoing packets (to WAN), because OSPF is prior on BGP. A second problem is routes obtained by RIP and redistributed over OSPF (by a custom patch which add redistribution of RIP routes to ospfd) has the same problem because OSPF is prior on RIP (i need to redistribute those RIP routes because the routes are distributed to remote networks over an GRE+IPSec link). 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...). -- Best regards, Loïc BLOT, UNIX systems, security and network engineer http://www.unix-experience.fr Le dimanche 03 novembre 2013 à 18:01 +0100, Loïc Blot a écrit : Hello, that's powerful but my improvement isn't for this use. It's only an improvement to route packets correctly, not dispatch charge. I'll give you a concrete example this evening. Loïc Blot, Ingénieur systèmes UNIX, Sécurité et Réseaux http://www.unix-experience.fr Stuart Henderson st...@openbsd.org a écrit : On 2013/11/01 19:57, sven falempin wrote: FreeBSD propose to have a specific routing table for a process, which is even more powerful. When the router has multiple gateway i guess when a source address is choose the route should be chosen given that. Nothing more. What use of this improvement do you imagine ?, of course you may want this traffic over this network(low latency) and the other one on another(high badnwith), put you may use pf for this, or specific route for the services. Writing about this make me think you want a route that select on the PORT instead of the IP. Is this madness ??? This is also known as policy based routing. I've being doing this with route-to in PF for ages, or alternatively you can use multiple route tables and rtable in PF to push certain traffic to using a certain table (either based on port number, or source address, or UID if it's a connection from the local machine, etc). signature.asc Description: This is a digitally signed message part
Re : Re: Improve routing functions
Can you explain me what's the problem with m'y configuration ? I don't see what is the problem. Loïc Blot, Ingénieur systèmes UNIX, Sécurité et Réseaux http://www.unix-experience.fr Chris Cappuccio ch...@nmedia.net a écrit : Lo?c BLOT [loic.b...@unix-experience.fr] wrote: Hello sven, it's not a routing table problem, it's only a modification on route priorities, it's not the same thing. The two of you are solving totally different problems. Here is my example at work: I have BGP on the WAN, OSPF for my LAN (+ over GRE tunnels) and RIP to my CISCO catalyst 45XX. The problem is simple. I have two routers in this configuration. OSPF is prior on RIP. routes obtained by RIP are redistributed on OSPF (because my remote sites must know them). But OSPF is prior than RIP and then the two border routers want to pass by the other instead of using the RIP route. I have the same problem with BGP. default route is prior on OSPF than BGP. Then BGP must be prior on OSPF to don't loop default route between the two routers. You don't need a new knob in the system to fix this. You need to fix your configuration.
