On Thu, Mar 24, 2022 at 01:46:26PM +0000, Xavier Trilla wrote: > Hi Alexander, > > Ok, I'm trying to wrap my head around this, so the idea is to filter based on > route reachability, forcing recursive routes?
I agree with Alexander, that is a pretty elegant way to solve this issue. > >Add static protocol attached to table_a with your set of routes to announce, > >which have some IP from the signaling prefix used as a recursive gateway. > > Ok, here is where I get a bit lost. You mean to put our routes so the next > hope is recursive and can only be resolved with the route previously imported > from the provider? Yes, that is the idea. > >When the prefix is absent they'll have unreachable status. Export those > >routes from table_a to table main filtering out routes with unreachable > >status. > Ok, and we can then export these routes to other providers forcing the > next_hop to be us? Generally bgp_next_hop is rewritten automatically when propagating through EBGP to peers on other ifaces, but you can make it rewrite manually when propagating from table_a to table main. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
