Hello list, is there any best practise to advertise static routes when interface names change? I have many ppp uplinks running on a server (ppp0, ppp1, ppp2 etc.) with static routes on them which I configure like this:
protocol static { route 10.0.0.0/28 via 169.254.0.1; route 10.0.0.1/28 via 169.254.0.1; route 10.0.0.2/28 via 169.254.0.2; }
On startup, bird recognizes perfectly which interface they belong to but if ppp reconnects, the interface name may change and so does the routing information - so it has to be updated by bird, is that any possible? All I can do right now is "check link on" so routes will disappear at least when interfaces go down. There is no 'scan' option for static routes as far as I understand the documentation, or can this be done any differently? Thanks, Amadeus
On 8/2/2012 9:56 PM, Amadeus wrote:
Hello list,
is there any best practise to advertise static routes when interface names change? I have many ppp uplinks running on a server (ppp0, ppp1, ppp2 etc.) with static routes on them which I configure like this:
protocol static { route 10.0.0.0/28 via 169.254.0.1; route 10.0.0.1/28 via 169.254.0.1; route 10.0.0.2/28 via 169.254.0.2; }
On startup, bird recognizes perfectly which interface they belong to but if ppp reconnects, the interface name may change and so does the routing information - so it has to be updated by bird, is that any possible? All I can do right now is "check link on" so routes will disappear at least when interfaces go down. There is no 'scan' option for static routes as far as I understand the documentation, or can this be done any differently?
Thanks, Amadeus you can always make the ppp connection naming static or use canonical name for a specific link which is the same.
i have seen some potato like "tomato" code that was being used to LB dsl connection which this guy used static naming for ppp connections and there might be a hint with the way he did it. the source code and readme are here: https://github.com/wisq/potato Regards, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer <at> ngtech.co.il
On Thu, Aug 02, 2012 at 08:56:40PM +0200, Amadeus wrote:
Hello list,
is there any best practise to advertise static routes when interface names change? I have many ppp uplinks running on a server (ppp0, ppp1, ppp2 etc.) with static routes on them which I configure like this:
protocol static { route 10.0.0.0/28 via 169.254.0.1; route 10.0.0.1/28 via 169.254.0.1; route 10.0.0.2/28 via 169.254.0.2; }
On startup, bird recognizes perfectly which interface they belong to but if ppp reconnects, the interface name may change and so does the routing information - so it has to be updated by bird, is that any possible? All I can do right now is "check link on" so routes will disappear at least when interfaces go down. There is no 'scan' option for static routes as far as I understand the documentation, or can this be done any differently?
Hello Static routes depends on 'via' IP address, not on iface names. If there is interface which makes that IP available. I don't have experience with PPP uplink servers, but i guess that when the connection disappears, IP is removed, and when the client reconnects, appropriate IP get assigned to that ppp iface. If PPP works like that, you don't need anything more (even 'check link on' is unnecessary). If client with 10.0.0.0/28 disconnects, 169.254.0.1 would be unaccessible and static protocol removes 10.0.0.0/28 (and 10.0.0.1/28), if that client reconnects, 169.254.0.1 would become accessible and route should reappear (with possibly different iface). At least that should work in theory, unless there are some bugs. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello and thank you for this.
I don't have experience with PPP uplink servers, but i guess that when the connection disappears, IP is removed, and when the client reconnects, appropriate IP get assigned to that ppp iface.
That is correct, having nopersisent set on pppd even the whole interface disappears (otherwise it will be just set to down).
If client with 10.0.0.0/28 disconnects, 169.254.0.1 would be unaccessible and static protocol removes 10.0.0.0/28 (and 10.0.0.1/28),
Yes and yes, I can confirm that bird is removing routes.
if that client reconnects, 169.254.0.1 would become accessible and route should reappear (with possibly different iface).
Here comes the problem: bird is not adding any routes back, only if I restart it the static protocol sets all routes correctly again (to the new interface). I have log option 'all' but it is not saying anything helpful I guess - what do you suggest to debug this a little better? # bird --version BIRD version 1.3.8 Thanks, Amadeus On Tue, 7 Aug 2012 11:52:57 +0200, Ondrej Zajicek wrote:
On Thu, Aug 02, 2012 at 08:56:40PM +0200, Amadeus wrote:
Hello list,
is there any best practise to advertise static routes when interface names change? I have many ppp uplinks running on a server (ppp0, ppp1, ppp2 etc.) with static routes on them which I configure like this:
protocol static { route 10.0.0.0/28 via 169.254.0.1; route 10.0.0.1/28 via 169.254.0.1; route 10.0.0.2/28 via 169.254.0.2; }
On startup, bird recognizes perfectly which interface they belong to but if ppp reconnects, the interface name may change and so does the routing information - so it has to be updated by bird, is that any possible? All I can do right now is "check link on" so routes will disappear at least when interfaces go down. There is no 'scan' option for static routes as far as I understand the documentation, or can this be done any differently?
Hello
Static routes depends on 'via' IP address, not on iface names. If there is interface which makes that IP available.
I don't have experience with PPP uplink servers, but i guess that when the connection disappears, IP is removed, and when the client reconnects, appropriate IP get assigned to that ppp iface.
If PPP works like that, you don't need anything more (even 'check link on' is unnecessary). If client with 10.0.0.0/28 disconnects, 169.254.0.1 would be unaccessible and static protocol removes 10.0.0.0/28 (and 10.0.0.1/28), if that client reconnects, 169.254.0.1 would become accessible and route should reappear (with possibly different iface). At least that should work in theory, unless there are some bugs.
-- Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Wed, Aug 08, 2012 at 11:56:41PM +0200, Amadeus wrote:
if that client reconnects, 169.254.0.1 would become accessible and route should reappear (with possibly different iface).
Here comes the problem: bird is not adding any routes back, only if I restart it the static protocol sets all routes correctly again (to the new interface). I have log option 'all' but it is not saying anything helpful I guess - what do you suggest to debug this a little better?
Hello, i cannot reproduce that behavior, works for me. You could check (and send me) this: 1) State of the iface (show interfaces), whether the problem does not correct after the next iface scan (for more often iface scans put this: "protocol device { scan time 10; }" to the config file. 2) What is a state of static protocol (show static) whether the route is 'dormant' (as if the neighbor is not connected) or not. 3) 'debug protocols all' in config files and send me log region around route removal (during disconnect) and around expected route adding (during ppp reconnect). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej, this is what I see when the problem occurs: a) interface (ppp5) is up after it has been re-established by pppd after connection reset: # ip a s dev ppp5 923: ppp5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1446 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 169.254.0.1 peer 169.254.40.52/32 scope global ppp5 b) it is also present in birdc:
show interfaces ppp5 up (index=923) PtP Multicast AdminUp LinkUp MTU=1446 169.254.0.1/32 (Primary, opposite 169.254.40.52, scope univ)
c) the interface has been rescanned by bird as ppp5: 10-08-2012 11:17:30 <TRACE> static1 < interface ppp5 goes up d) routes are missing (table 100 = kffc): # ip r s table 100 dev ppp5 <no output> -- What happended before -- DOWN event: 10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.129.32/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.129.32/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.131.48/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.131.48/28 via 169.254.40.52 on ppp2 When I look at the timestamps it seems as if the old interface is not down before the new one comes up which means that bird won't be able to set the new routing information as it is still present on the old interface, does that make sense to you? Is there any trigger in bird to catch that or do I have to set scan device >>60s? Thanks, Amadeus Am Donnerstag, den 09.08.2012, 11:41 +0200 schrieb Ondrej Zajicek:
On Wed, Aug 08, 2012 at 11:56:41PM +0200, Amadeus wrote:
if that client reconnects, 169.254.0.1 would become accessible and route should reappear (with possibly different iface).
Here comes the problem: bird is not adding any routes back, only if I restart it the static protocol sets all routes correctly again (to the new interface). I have log option 'all' but it is not saying anything helpful I guess - what do you suggest to debug this a little better?
Hello, i cannot reproduce that behavior, works for me.
You could check (and send me) this:
1) State of the iface (show interfaces), whether the problem does not correct after the next iface scan (for more often iface scans put this: "protocol device { scan time 10; }" to the config file.
2) What is a state of static protocol (show static) whether the route is 'dormant' (as if the neighbor is not connected) or not.
3) 'debug protocols all' in config files and send me log region around route removal (during disconnect) and around expected route adding (during ppp reconnect).
On Fri, Aug 10, 2012 at 02:45:18PM +0200, Amadeus wrote:
b) it is also present in birdc:
show interfaces ppp5 up (index=923) PtP Multicast AdminUp LinkUp MTU=1446 169.254.0.1/32 (Primary, opposite 169.254.40.52, scope univ)
c) the interface has been rescanned by bird as ppp5: 10-08-2012 11:17:30 <TRACE> static1 < interface ppp5 goes up
d) routes are missing (table 100 = kffc): # ip r s table 100 dev ppp5 <no output>
Also could you check and send me what says 'show static' for that route in that situation?
-- What happended before -- DOWN event: 10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.129.32/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.129.32/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.131.48/28 via 169.254.40.52 on ppp2 10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.131.48/28 via 169.254.40.52 on ppp2
When I look at the timestamps it seems as if the old interface is not down before the new one comes up which means that bird won't be able to set the new routing information as it is still present on the old interface, does that make sense to you? Is there any trigger in bird to catch that or do I have to set scan device >>60s?
Generally, if the new iface with the same address prefix appears before the 'old' prefix that definitely could cause the problem - when the 'old' prefix is removed, ther route is also removed ignoring that the prefix is already on another iface. I thought about this possibility before but it seemed strange that it would happen on ppp connections, i guess that the reconnect would need some time between disconnect and new connect, so the 'old' prefix would be removed before the 'new one' would be added. The scan device interval shouldn't matter much - interface and prefix changes are announced immediately and the scanning is here only for verification and catching missed notifications. So the question is whether the appearance of 'new' prefix before removing of 'old' prefix is just on BIRD level (e.g. if announcements were missed for some reason and both changes were catched by scan) or also on OS level (e.g. if old PPP session was not properly terminated so new PPP session was established before the old one timeouted). Could you also send me more complete part of logfile, i.e. containing everything related to the reconnect, both interfaces down and up and prefixes removal and adding? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Aug 10, 2012 at 02:45:18PM +0200, Amadeus wrote:
When I look at the timestamps it seems as if the old interface is not down before the new one comes up which means that bird won't be able to set the new routing information as it is still present on the old interface, does that make sense to you?
Hello Try this patch, it fixes an issue with more overlapping prefixes, it may fix your problem. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Amadeus -
Eliezer Croitoru -
Ondrej Zajicek