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: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."