Protocols device and direct getting out of sync

[Tore Anderson]

* 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