Hi list, After using bird for some time now, I've found few things that are annoying me, or simply break things that should work flawlessly ;) bird> show protocols all [some BGP protocol] Routes: 19186 imported, 2 exported, 84627 preferred My guess is that it has something to do with pipes. I have multiple pipes that do import filter { if proto="[some BGP protocol]" then accept; reject; }; Problem 2: bird's reality: ng6 up (index=35) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.35, scope univ) vlan3372 up (index=36) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.171, scope univ) ng7 up (index=37) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.17.123, scope univ) reality's reality: ng4: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.35 netmask 0xffffffff ng6: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.171 netmask 0xffffffff ng7: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.17.123 netmask 0xffffffff # ifconfig vlan3372 ifconfig: interface vlan3372 does not exist Above happened after I decided that I don't feel like wanting vlan3372 and changed it to something else. In the meantime some customer decided to open PPPoE session, not knowing this will spell his doom :> bird also happily ignores interface name changes, which hinders nice features such as interface "name*" etc. Thanks for reading. :)
On 16.01.2012 12:16, Pawel Tyll wrote:
Hi list,
After using bird for some time now, I've found few things that are annoying me, or simply break things that should work flawlessly ;)
bird> show protocols all [some BGP protocol] Routes: 19186 imported, 2 exported, 84627 preferred
My guess is that it has something to do with pipes.
I have multiple pipes that do import filter { if proto="[some BGP protocol]" then accept; reject; };
Can you send me output of 1) show protocol all [some BGP protocol] 2) show protocol all [some pipe protocol] 3) related parts of configuration file (BGP, pipe, tables, filters) with description?
Problem 2:
bird's reality: ng6 up (index=35) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.35, scope univ) vlan3372 up (index=36) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.171, scope univ) ng7 up (index=37) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.17.123, scope univ)
reality's reality: ng4: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.35 netmask 0xffffffff ng6: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.171 netmask 0xffffffff ng7: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.17.123 netmask 0xffffffff # ifconfig vlan3372 ifconfig: interface vlan3372 does not exist
Above happened after I decided that I don't feel like wanting vlan3372 and changed it to something else. In the meantime some customer decided to open PPPoE session, not knowing this will spell his doom :>
bird also happily ignores interface name changes, which hinders nice features such as interface "name*" etc.
Yes, there is a problem. I'll try to look at this in several days since I need this fixed, too.
Thanks for reading. :)
On Mon, Jan 16, 2012 at 09:16:25AM +0100, Pawel Tyll wrote:
Hi list,
After using bird for some time now, I've found few things that are annoying me, or simply break things that should work flawlessly ;)
bird> show protocols all [some BGP protocol] Routes: 19186 imported, 2 exported, 84627 preferred
My guess is that it has something to do with pipes.
This is OK. Imported shows just number of routes propagated to directly connected table, while preferred count shows cummulative number of routes originated by that protocol in all tables where these routes are preferred.
Problem 2:
bird's reality: ng6 up (index=35) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.35, scope univ) vlan3372 up (index=36) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.16.171, scope univ) ng7 up (index=37) PtP Multicast AdminUp LinkUp MTU=1492 local.ip/32 (Primary, opposite 192.168.17.123, scope univ)
reality's reality: ng4: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.35 netmask 0xffffffff ng6: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.16.171 netmask 0xffffffff ng7: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet local.ip --> 192.168.17.123 netmask 0xffffffff # ifconfig vlan3372 ifconfig: interface vlan3372 does not exist
Above happened after I decided that I don't feel like wanting vlan3372 and changed it to something else.
So you removed it? Or renamed?
In the meantime some customer decided to open PPPoE session, not knowing this will spell his doom :>
bird also happily ignores interface name changes, which hinders nice features such as interface "name*" etc.
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. -- 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."
This is OK. Imported shows just number of routes propagated to directly connected table, while preferred count shows cummulative number of routes originated by that protocol in all tables where these routes are preferred. Hm, personally I would prefer to receive information only about [some BGP protocol] when asking for information about [some BGP protocol] - this way I'll have 23857286917 preferred prefixes in no time, think about it yourself: how useful is that number? :)
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :>
On Tue, Jan 17, 2012 at 01:41:02PM +0100, Pawel Tyll wrote:
This is OK. Imported shows just number of routes propagated to directly connected table, while preferred count shows cummulative number of routes originated by that protocol in all tables where these routes are preferred. Hm, personally I would prefer to receive information only about [some BGP protocol] when asking for information about [some BGP protocol] - this way I'll have 23857286917 preferred prefixes in no time, think about it yourself: how useful is that number? :)
That makes sense for imported/exported counters as that are just properties of the protocol. But whether the route is preferred depends also in which routing table and we do not count it independently for each pair (proto, table). It would be possible to count that just for directly connected table, but the idea is that directly connected table is not any more special than any other table that receives the route (and sometimes, like in route server setting, where there is more or less one table per BGP neighbor, the number of preferred routes in the directly connected table is not really relevant). Not to mention it is also counterintuitive - if it would show '0 preferred', users would think it is not important and can be disabled for import, but it may have many preferred routes in many tables (just not in the directly connected). -- 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."
That makes sense for imported/exported counters as that are just properties of the protocol. But whether the route is preferred depends also in which routing table and we do not count it independently for each pair (proto, table). Maybe an option then, if counting per table is not feasible/wanted for some reason?
It would be possible to count that just for directly connected table, but the idea is that directly connected table is not any more special than any other table that receives the route (and sometimes, like in route server setting, where there is more or less one table per BGP neighbor, the number of preferred routes in the directly connected table is not really relevant). Not to mention it is also counterintuitive - if it would show '0 preferred', users would think it is not important and can be disabled for import, but it may have many preferred routes in many tables (just not in the directly connected). Well then, it would seem to me, like it needs to be shown per table, or for "show protocols all [some BGP protocol] table table" :)
Pawel Tyll wrote:
This is OK. Imported shows just number of routes propagated to directly connected table, while preferred count shows cummulative number of routes originated by that protocol in all tables where these routes are preferred. Hm, personally I would prefer to receive information only about [some BGP protocol] when asking for information about [some BGP protocol] - this way I'll have 23857286917 preferred prefixes in no time, think about it yourself: how useful is that number? :)
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :> Attached patch seems to work on FreeBSD. For OpenBSD rtsock events seems to be the same (and interface renaming is not supported there at all). I don't have any NetBSD instance to test on, unfortunately
Patch is not finished: interface renaming has to be handled in appropriate protocols. In OSPF, for example, it is a bit tricky due to the fact that interface can belong to several areas
On Thu, Jan 19, 2012 at 03:34:30PM +0400, Alexander V. Chernikov wrote:
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :> Attached patch seems to work on FreeBSD. For OpenBSD rtsock events seems to be the same (and interface renaming is not supported there at all). I don't have any NetBSD instance to test on, unfortunately
Patch is not finished: interface renaming has to be handled in appropriate protocols. In OSPF, for example, it is a bit tricky due to the fact that interface can belong to several areas
I guess that seamless renaming is not really important, so it could be handled just by IF_CHANGE_TOO_MUCH (i.e. virtual iface down and up), that would work for any protocol. (or, because ifaces in BIRD are generally keyed by name, just remove the old one before creating the new one) BTW, AFAIK Linux does not allow iface renaming unless the iface is down. struct_iface should not be freed when interface disappears. There are users for that (most recently link-local sticky neighbors, but AFAIK there are others i don't remember now). Perhaps these structures should be reference counted, but keeping them with IF_SHUTDOWN is OK. One thing that was a cause for a bug related to renaming is that shutdown ifaces kept their iface index and are returned by if_find_by_index(). Simple fix for that would probably make destroying and creating ifaces work. RTM_IFANNOUNCE seems useful. Am i understand that correctly that any iface changes are notified using RTM_IFINFO, just create and destroy of ifaces are notified using RTM_IFANNOUNCE? And also that when newly created iface is announced by RTM_IFANNOUNCE, there is almost none information in that announcement to really create the iface in BIRD? Perhaps it is supposed to request RTM_IFINFO about that iface by some sysctl? Or we could at least trigger early iface scan. Some other comments below.
+ /* Interface is renamed. */ + if (strcmp(iface->name, ifam->ifan_name)) + { + DBG("KRT: Interface %s renamed to %s\n", iface->name, ifam->ifan_name); + memcpy(&f, iface, sizeof(struct iface)); + /* Assume both strings are IFNAMSIZ length */ + memcpy(f.name, ifam->ifan_name, IFNAMSIZ); + if_update(&f); + }
This does not work well. Because if_update would match iface by name, this would create a new iface structure so there would be two, until the old one would be removed during another iface scan. As a consequence, if_what_changed() would never return IF_CHANGE_NAME.
@@ -588,6 +642,8 @@ krt_read_msg(struct proto *p, struct ks_msg *msg, int scan) case RTM_DELETE: krt_read_rt(msg, (struct krt_proto *)p, scan); break; + case RTM_IFANNOUNCE: + krt_read_ifannounce(msg); case RTM_IFINFO: krt_read_ifinfo(msg); break;
Missing break here? -- 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."
Ondrej Zajicek wrote:
On Thu, Jan 19, 2012 at 03:34:30PM +0400, Alexander V. Chernikov wrote:
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :> Attached patch seems to work on FreeBSD. For OpenBSD rtsock events seems to be the same (and interface renaming is not supported there at all). I don't have any NetBSD instance to test on, unfortunately
Patch is not finished: interface renaming has to be handled in appropriate protocols. In OSPF, for example, it is a bit tricky due to the fact that interface can belong to several areas
I guess that seamless renaming is not really important, so it could be handled just by IF_CHANGE_TOO_MUCH (i.e. virtual iface down and up), that would work for any protocol. (or, because ifaces in BIRD are generally keyed by name, just remove the old one before creating the new one) BTW, AFAIK Linux does not allow iface renaming unless the iface is down. I've already got some rename-handling code in OSPF but it is not fully tested.. Maybe it is really better not to bother about keeping interface UP.
struct_iface should not be freed when interface disappears. There are users for that (most recently link-local sticky neighbors, but AFAIK there are others i don't remember now). Perhaps these structures should So the right way is to change such users behavior ? We definitely know interface is destroyed by OS and we can't predict if it ever comes up again and name / iface index / addresses are the same. Moreover, imagine bird running on some kind of PPTP server with several thousand interface UP which are destroyed/created with different interface indexes, names and addreses with the rate of several interfaces per second. (and bird announce all such interfaces (which has public/32 aadresses via OSPF) - this is typical configuration for PPTP/PPPOE server farm). This is, of course, not very similar to RS usage pattern, but bird claims to be 'sully functional dynamic IP routing daemon', right? :)
For NEF_STICKY we can either set iface pointer to NULL (and teach neighbor-api consumers to check this, which is fair) or simply get some gloval static "DUMMY" interface structure and change interface pointer to it.
be reference counted, but keeping them with IF_SHUTDOWN is OK. One thing that was a cause for a bug related to renaming is that shutdown ifaces kept their iface index and are returned by if_find_by_index(). Simple fix for that would probably make destroying and creating ifaces work.
RTM_IFANNOUNCE seems useful. Am i understand that correctly that any iface changes are notified using RTM_IFINFO, just create and destroy of ifaces are notified using RTM_IFANNOUNCE? And also that when newly
Yes. This is stated in route(4): #define RTM_IFINFO 0xe /* iface going up/down etc. */ #define RTM_IFANNOUNCE 0x11 /* iface arrival/departure */ To be more precise: ifconfig vlan999 create inet 1.2.3.4/29 triggers the following: got message of size 24 on Sun Jan 22 17:11:43 2012 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: arrival got message of size 184 on Sun Jan 22 17:11:43 2012 RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> default default default got message of size 108 on Sun Jan 22 17:11:43 2012 RTM_DELADDR: address being removed from iface: len 108, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA,BRD> default vlan999:0.0.0.0.0.0 default default got message of size 116 on Sun Jan 22 17:11:43 2012 RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA,BRD> 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7 got message of size 232 on Sun Jan 22 17:11:45 2012 RTM_ADD: Add Route: len 232, pid: 0, seq 0, errno 0, flags:<UP> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 1.2.3.0 (255) ffff ffff f8ff ... (multicast. ipv6, ipv6 mcast) Destroying interface gives nearly the same: got message of size 232 on Sun Jan 22 17:21:16 2012 RTM_DELETE: Delete Route: len 232, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 1.2.3.0 (255) ffff ffff f8ff got message of size 116 on Sun Jan 22 17:21:16 2012 RTM_DELADDR: address being removed from iface: len 116, metric 0, flags:<UP,HOST> sockaddrs: <NETMASK,IFP,IFA,BRD> 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7 got message of size 168 on Sun Jan 22 17:21:16 2012 RTM_IFINFO: iface status change: len 168, if# 15, link: unknown, flags:<BROADCAST,MULTICAST> got message of size 192 on Sun Jan 22 17:21:16 2012 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> default 1.2.3.4 default got message of size 116 on Sun Jan 22 17:21:16 2012 RTM_DELADDR: address being removed from iface: len 116, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA,BRD> 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7 got message of size 272 on Sun Jan 22 17:21:16 2012 RTM_DELETE: Delete Route: len 272, pid: 0, seq 0, errno 0, flags:<HOST,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> fe80::beae:c5ff:fe2e:4d74%15 0.0.0.0.0.0 ffff:ffff:ffff:ffff:: got message of size 140 on Sun Jan 22 17:21:16 2012 RTM_DELADDR: address being removed from iface: len 140, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA> ffff:ffff:ffff:ffff:: vlan999:0.0.0.0.0.0 fe80::beae:c5ff:fe2e:4d74%15 got message of size 344 on Sun Jan 22 17:21:16 2012 RTM_DELETE: Delete Route: len 344, pid: 0, seq 0, errno 0, flags:<DONE> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA> fe80::%15 (255) ffff ffff ffff ffff ffff ffff ffff vlan999:0.0.0.0.0.0 fe80::beae:c5ff:fe2e:4d74%15 got message of size 24 on Sun Jan 22 17:21:16 2012 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: departure OpenBSD and NetBSD behaves the same way (ordering of IF_ANNOUNCE / IF_IFINFO / RTM_ADD / RTM_DEL is the same)
created iface is announced by RTM_IFANNOUNCE, there is almost none information in that announcement to really create the iface in BIRD? Perhaps it is supposed to request RTM_IFINFO about that iface by some sysctl? Or we could at least trigger early iface scan. Well, we can simply listen to the next routing socket messages (or really trigger iface scan as a quick fix)
Some other comments below.
+ /* Interface is renamed. */ + if (strcmp(iface->name, ifam->ifan_name)) + { + DBG("KRT: Interface %s renamed to %s\n", iface->name, ifam->ifan_name); + memcpy(&f, iface, sizeof(struct iface)); + /* Assume both strings are IFNAMSIZ length */ + memcpy(f.name, ifam->ifan_name, IFNAMSIZ); + if_update(&f); + }
This does not work well. Because if_update would match iface by name, this would create a new iface structure so there would be two, until the old one would be removed during another iface scan. As a consequence, if_what_changed() would never return IF_CHANGE_NAME. Already notices that, thanks.
@@ -588,6 +642,8 @@ krt_read_msg(struct proto *p, struct ks_msg *msg, int scan) case RTM_DELETE: krt_read_rt(msg, (struct krt_proto *)p, scan); break; + case RTM_IFANNOUNCE: + krt_read_ifannounce(msg); case RTM_IFINFO: krt_read_ifinfo(msg); break;
Missing break here? Yes.
On Sun, Jan 22, 2012 at 05:41:40PM +0400, Alexander V. Chernikov wrote:
Ondrej Zajicek wrote:
On Thu, Jan 19, 2012 at 03:34:30PM +0400, Alexander V. Chernikov wrote:
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :> Attached patch seems to work on FreeBSD. For OpenBSD rtsock events seems to be the same (and interface renaming is not supported there at all). I don't have any NetBSD instance to test on, unfortunately
Patch is not finished: interface renaming has to be handled in appropriate protocols. In OSPF, for example, it is a bit tricky due to the fact that interface can belong to several areas
I guess that seamless renaming is not really important, so it could be handled just by IF_CHANGE_TOO_MUCH (i.e. virtual iface down and up), that would work for any protocol. (or, because ifaces in BIRD are generally keyed by name, just remove the old one before creating the new one) BTW, AFAIK Linux does not allow iface renaming unless the iface is down. I've already got some rename-handling code in OSPF but it is not fully tested.. Maybe it is really better not to bother about keeping interface UP.
BTW, i already have some minor fixes in iface scanning code in GIT i discovered yesterday. I would merge your patch and my comments to fix these bugs.
struct_iface should not be freed when interface disappears. There are users for that (most recently link-local sticky neighbors, but AFAIK there are others i don't remember now). Perhaps these structures should So the right way is to change such users behavior ? We definitely know interface is destroyed by OS and we can't predict if it ever comes up again and name / iface index / addresses are the same.
This is just technical issue whether a struct iface has to be removed immediately (synchronously) when an iface disappears, or a bit later when it would be removed anyway. For example, OSPF would probably hold some references for these structures until next recalculation. I guess that it is much simpler and convenient to add reference counting to struct iface than to modify all these users. It is true that currently we just never free these structs, which is bad but not particularly problematic. But fixing this is a different issue. So we could probably fix renaming/creating/removing ifaces now and i will add these reference counting later.
Moreover, imagine bird running on some kind of PPTP server with several thousand interface UP which are destroyed/created with different interface indexes, names and addreses with the rate of several interfaces per second.
Well, BIRD would have probably a problem in such settings, because there are too many parts of the code that would run in O(n^2) time (where n is a number of ifaces).
For NEF_STICKY we can either set iface pointer to NULL (and teach neighbor-api consumers to check this, which is fair) or simply get some gloval static "DUMMY" interface structure and change interface pointer to it.
This is an issue for link-local sticky neighbors, which obviously needs a way to specify an interface. We could use explicit string, but that would make it two times more complicated. It is a kind of sticky iface entry.
be reference counted, but keeping them with IF_SHUTDOWN is OK. One thing that was a cause for a bug related to renaming is that shutdown ifaces kept their iface index and are returned by if_find_by_index(). Simple fix for that would probably make destroying and creating ifaces work.
RTM_IFANNOUNCE seems useful. Am i understand that correctly that any iface changes are notified using RTM_IFINFO, just create and destroy of ifaces are notified using RTM_IFANNOUNCE? And also that when newly
Yes. This is stated in route(4): #define RTM_IFINFO 0xe /* iface going up/down etc. */ #define RTM_IFANNOUNCE 0x11 /* iface arrival/departure */
To be more precise: ifconfig vlan999 create inet 1.2.3.4/29
Thanks BTW, i also noticed that 'ifconfig re0 down' on BSD would first trigger RTM_DELADDR (for an address of iface), then RTM_IFINFO (for iface down), but in the next scan, the address is still reported. That seems a bit inconsistent to me, but not a big issue (interfaces disappears in BIRD and then reappears, but as the iface is down, it is not propagated anywhere).
triggers the following:
got message of size 24 on Sun Jan 22 17:11:43 2012 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: arrival
got message of size 184 on Sun Jan 22 17:11:43 2012 RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> default default default
... -- 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."
Ondrej Zajicek wrote:
On Sun, Jan 22, 2012 at 05:41:40PM +0400, Alexander V. Chernikov wrote:
Ondrej Zajicek wrote:
On Thu, Jan 19, 2012 at 03:34:30PM +0400, Alexander V. Chernikov wrote:
So you removed it? Or renamed? I removed it, so another interface took it's interface id, but bird kept associating previous name (vlan's) with this id. - renaming fails in principally the same way: bird keeps previous name ;)
It is supposed to work (it is handled as removing and readding the interface), but probably not tested. Well, I was supposed to be awfully rich by now, but it wasn't tested, hence it didn't work :> Attached patch seems to work on FreeBSD. For OpenBSD rtsock events seems to be the same (and interface renaming is not supported there at all). I don't have any NetBSD instance to test on, unfortunately
Patch is not finished: interface renaming has to be handled in appropriate protocols. In OSPF, for example, it is a bit tricky due to the fact that interface can belong to several areas I guess that seamless renaming is not really important, so it could be handled just by IF_CHANGE_TOO_MUCH (i.e. virtual iface down and up), that would work for any protocol. (or, because ifaces in BIRD are generally keyed by name, just remove the old one before creating the new one) BTW, AFAIK Linux does not allow iface renaming unless the iface is down. I've already got some rename-handling code in OSPF but it is not fully tested.. Maybe it is really better not to bother about keeping interface UP.
BTW, i already have some minor fixes in iface scanning code in GIT i I saw, RSS is a useful thing :) discovered yesterday. I would merge your patch and my comments to fix these bugs. Okay, so you'll finish this and we skip refcount stuff for now?
struct_iface should not be freed when interface disappears. There are users for that (most recently link-local sticky neighbors, but AFAIK there are others i don't remember now). Perhaps these structures should So the right way is to change such users behavior ? We definitely know interface is destroyed by OS and we can't predict if it ever comes up again and name / iface index / addresses are the same.
This is just technical issue whether a struct iface has to be removed immediately (synchronously) when an iface disappears, or a bit later when it would be removed anyway. For example, OSPF would probably hold some references for these structures until next recalculation. I guess that it is much simpler and convenient to add reference counting to struct iface than to modify all these users. It is true that currently we just never free these structs, which is bad but not particularly problematic. But fixing this is a different issue. So we could probably fix renaming/creating/removing ifaces now and i will add these reference counting later.
Moreover, imagine bird running on some kind of PPTP server with several thousand interface UP which are destroyed/created with different interface indexes, names and addreses with the rate of several interfaces per second.
Well, BIRD would have probably a problem in such settings, because there are too many parts of the code that would run in O(n^2) time (where n is a number of ifaces). Another thing to fix / think of (at least for me)
For NEF_STICKY we can either set iface pointer to NULL (and teach neighbor-api consumers to check this, which is fair) or simply get some gloval static "DUMMY" interface structure and change interface pointer to it.
This is an issue for link-local sticky neighbors, which obviously needs a way to specify an interface. We could use explicit string, but that would make it two times more complicated. It is a kind of sticky iface entry.
be reference counted, but keeping them with IF_SHUTDOWN is OK. One thing that was a cause for a bug related to renaming is that shutdown ifaces kept their iface index and are returned by if_find_by_index(). Simple fix for that would probably make destroying and creating ifaces work. RTM_IFANNOUNCE seems useful. Am i understand that correctly that any iface changes are notified using RTM_IFINFO, just create and destroy of ifaces are notified using RTM_IFANNOUNCE? And also that when newly Yes. This is stated in route(4): #define RTM_IFINFO 0xe /* iface going up/down etc. */ #define RTM_IFANNOUNCE 0x11 /* iface arrival/departure */
To be more precise: ifconfig vlan999 create inet 1.2.3.4/29
Thanks
BTW, i also noticed that 'ifconfig re0 down' on BSD would first trigger RTM_DELADDR (for an address of iface), then RTM_IFINFO (for iface down), but in the next scan, the address is still reported. That seems a bit inconsistent to me, but not a big issue (interfaces disappears in BIRD and then reappears, but as the iface is down, it is not propagated anywhere).
This is interesting. The code that does this also sends such messages for IPv4 address family only which is inconsistent twice. Thanks for pointing.
triggers the following:
got message of size 24 on Sun Jan 22 17:11:43 2012 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: arrival
got message of size 184 on Sun Jan 22 17:11:43 2012 RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> default default default
...
On Sun, Jan 22, 2012 at 08:30:18PM +0400, Alexander V. Chernikov wrote:
BTW, i already have some minor fixes in iface scanning code in GIT i I saw, RSS is a useful thing :) discovered yesterday. I would merge your patch and my comments to fix these bugs. Okay, so you'll finish this and we skip refcount stuff for now?
Yes, finished. -- 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 (4)
-
Alexander V. Chernikov -
Alexander V. Chernikov -
Ondrej Zajicek -
Pawel Tyll