I have a pair of -current routers running bgpd (let's call them rtr-a
and rtr-b) on a subnet which also has some vpn gateways and firewalls.
These routers provide a carp address which the vpn gateways are using
as default route. There are some networks behind the vpn gateways (a
/32 to accept incoming vpn connections and some other prefixes that vpn
clients are numbered from).
rtr-a and rtr-b have static routes to those networks, and they have
network statements in bgpd.conf to announce them to their ibgp peers
("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
from the rest of the network. (This is replacing an existing setup using
ospf, trying to remove routing protocols from machines that don't really
need them).
It is working but something seems a little odd - the paths are announced
from both routers briefly and show up on the rest of the network from
both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
paths from rtr-a, and then rtr-b stops announcing them itself. (they
stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
correctly identify the associated nexthops as connected/UP).
Is this expected/correct behaviour?
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).
If rtr-b stops seeing the prefixes from rtr-a (either by taking down
the ibgp session, or by filtering) I see the announcements from both
rtr-a and rtr-b again. So the obvious workaround is to filter, but
I thought I'd ask first in case it's something that is better handled
by code changes rather than config.
