On Mon, Nov 29, 2021 at 10:38:21PM +0100, Sebastian Benoit wrote:
> 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.

Or the other way is to alter localpref, as-path or metric of those routes
in some way that makes sure that both router-A and router-B announce a
"better" route.

You can do this in multiple ways. One way would be to use something like
this:
pass out on ibgp metric +1
or
pass in on ibgp metric -1
 
Long term it would be nice to reintroduce route metrics and use this
to sort nexthops in bgpd.

-- 
:wq Claudio

Reply via email to