Filter based on BGP protocol status ...

[Xavier Trilla]

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?

> Take some prefix that should be always announced by A (their own prefix for example).

ok, we could try to use one route of their AS (Although the next jump to them is not announced via BGP, is just set in our router manually) 

>Add separate route table in bird, ex. table_a

ok

>Then add a pipe protocol that exports from the main table to table_a only this prefix and only from this peer.

ok

>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?

>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?
I think I’m getting the idea, but I will have to test it a bit to better understand it and be sure it could work in our environment.
Thanks for the info!
Xavier.
-----Mensaje original-----
De: Alexander Zubkov <green at qrator.net> 
Enviado el: jueves, 24 de marzo de 2022 13:35
Para: Xavier Trilla <xavier.trilla at clouding.io>
CC: Douglas Fischer <fischerdouglas at gmail.com>; BIRD Users <bird-users at network.cz>
Asunto: Re: Filter based on BGP protocol status ...

Hi,

If you want to do it with Bird, and you have a static set of routes to conditionally announce, you can try to do some trick like that:
Take some prefix that should be always announced by A (their own prefix for example). Add separate route table in bird, ex. table_a.
Then add a pipe protocol that exports from the main table to table_a only this prefix and only from this peer. 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. 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.
Thus you'll have those routes in the main table conditionally depending on the availability of the signaling prefix from peer A.
Hope that works for you. And of course those routes could meddle with other routes in your routing table, but they should only be used for announcing them to bgp, so be careful.

On Thu, Mar 24, 2022 at 1:05 PM Xavier Trilla <xavier.trilla at clouding.io> wrote:
>
> Hi Douglas,
>
>
>
> Thanks for the tip, I did not know about ExaBGP, seems worth looking into it.
>
>
>
> We also use Zabbix for the monitoring of our platform, but usually some of these things we prefer to do them using regular shell scripting (And the end, something like a script running every N seconds that checks the status of a specific protocol should not be heavy on the system) because that way it does not depend on external systems. But yes, ExaBGP looks really interesting. We’ll check it out.
>
>
>
> > You can used also some BGP communities(if your upstream supports it) for no-export for some prefixes... Sometimes it helps.
>
>
>
> Well, we do that usually for DDOS traffic diversion to our scrubbing provider, but we have found some providers we have a direct connection to don’t respect prepending and for this specific case, we need to ensure all the traffic is filtered.
>
>
>
> Thanks!
>
> Xavier.
>
>
>
> De: Douglas Fischer <fischerdouglas at gmail.com> Enviado el: jueves, 24 
> de marzo de 2022 11:43
> Para: Xavier Trilla <xavier.trilla at clouding.io>
> CC: BIRD Users <bird-users at network.cz>
> Asunto: Re: Filter based on BGP protocol status ...
>
>
>
> I know that it is not the focus of your question, and also is not the focus on this mail list, but...
>
>
>
> To that kind of automation, the best BGP engine you will find is ExaBGP. It is not focuses in been in compliance with all the concepts of a routing system itself. It's focus is exactly automations using API.
>
>
>
> The scenario you described triggered-me something like a Zabbix looking to the status of BGP sessions of bird, and based on that doing API queries to a ExaBGP that is a iBGP peer of Bird.
>
>
>
> This model is used on many tools focused in anomaly detection for triggering DDoS mitigation.
>
>
>
>
>
> But, if your intention is a much simpler scenario, the suggestion Maria made is the most common!
>
> You can used also some BGP communities(if your upstream supports it) for no-export for some prefixes... Sometimes it helps.
>
>
>
> Em qua., 23 de mar. de 2022 12:10, Xavier Trilla <xavier.trilla at clouding.io> escreveu:
>
> Hi,
>
>
>
> I’m quite sure this cannot be done, but I also know there is a lot of BIRD I still don’t know, so here it goes:
>
>
>
> Is there any way to filter a export route based on another BGP session status?
>
>
>
> For the sake of simplicity let’s say we have just two providers A and B, and I only want to export some specific routes to B when A is down.
>
>
>
> I can do it externally with a quite simple script (For example: Check if the provider is down via CLI and if it’s down insert the routes I want to export to a kernel table and export that to provider B) but it would be nice if I could do it directly in Bird.
>
>
>
> I’ve been scratching my head around this, but unless there is 
> something like if proto.A == down on the filters I don’t really see 
> how to do it (Or maybe some way to raise a global flag based on if I’m 
> receiving routes via provider B, but I don’t think that can’t be done 
> either.)
>
>
>
> Thanks for your time!
>
> Xavier
>
>