* Ondrej Zajicek
The main problem in your example is that primary address of the iface changed, which caused virtual restart of the iface, which caused the device to be down until the next scan and log messages about removal of addresses. The whole primary address selection is a relic of the past and will be removed in the future, currently you could fix your problem by explicitly declaring that 127.0.0.1 is the primary address on the loopback:
protocol device { primary "lo" 127.0.0.1; }
After that, any other manipulation of addresses on loopback should be seamless and immediate.
Thank you! This workaround works very well, now any added addresses on the lo interface shows up as active in the BIRD routing table immediately, and most importantly, gets advertised to the upstream RIP neighbour immediately. The only remaining problem for me now is to make address *removals* be treated equally instantaneous. As I mentioned on this list Feb 5th, BIRD doesn't appear to withdraw routes with triggered updates, and it doesn't seem like it is possible to use BFD in conjunction with RIP either. Relying on the upstream's router's route timeout timer kind of sucks, since the invalid route can linger for minutes, during which traffic will be blackholed. Any suggestions on how to improve this? Best regards, Tore Anderson