On 2021-11-29, Sebastian Benoit <benoit-li...@fb12.de> wrote: > > It is expected: once rtr-b receives the route from rtr-a, it will run the > route decision process on it. IF both routers are configured identically > except for the router-id, one of the routes will be prefered at either the > "oldest path" or the "lowest bgp id" criteria. > > As only one route is a best route, that one will be annouced to the > neighbors. However this is IBGP. In a set of IBGP connected routers, a > router will not announce a route to other IBGP peers that it received from > on a IBGP session. Thus, rtr-b will stop announcing that route.
Thanks, the explanation makes sense (though it doesn't feel quite like expected behaviour - it makes sense that it doesn't announce the route received over IBGP but seems a little strange that an explicitly configured local announcement from a static route depends on BGP from other routers). Anyway filtering the incoming prefixes is having the desired effect. > When rtr-a goes down, the session is shut down or the prefix is filtered, > bgpd wont see the "better" route anymore and announce its own instead. > >> I'd prefer to have them announced from both rtr-a and rtr-b, so there's >> no blackhole period if rtr-a is restarted while rtr-b figures out that >> it should start announcing them, etc. (No need for tracking carp state >> in this case, I'm not using stateful pf rules on the traffic involved). > > This is a place where ospf might give you faster failover, especiall y with > the redistribute ... depend on ... syntax. Reducing the number of machines running ospfd was the whole reason for changing this. And with the timers I'm having to run on OSPF to get something vaguely approaching stability I can't say that it will be any faster than BGP!