Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +0000:
> 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?
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.
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.
> 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.
