RE: Filter based on BGP protocol status ...
>I pretty sure that you already know that, and probably already heard that... >But you should not do business with companies like that one. Well, I wont say who, but I’m referring to a big DIA European provider (Really good providers besides this specific issue)… But yeah, I hate when they just ignore our prepending. If the attacking IP belongs to the specific provider AS number, the traffic will be delivered directly by the DIA we have. De: Douglas Fischer Enviado el: jueves, 24 de marzo de 2022 23:06 Para: Xavier Trilla CC: Alarig Le Lay ; BIRD Users Asunto: Re: Filter based on BGP protocol status ... I pretty sure that you already know that, and probably already heard that... But you should not do business with companies like that one. Em qui., 24 de mar. de 2022 11:09, Xavier Trilla mailto:xavier.tri...@clouding.io>> escreveu: >More simply, you can add a community on the non-ddos-protected provider to >make them lower the localpref to peer routes, and stop the prepend. We tried, but some providers basically ignore everything if you have a direct connection with them. They just forward you the traffic despite prepending or localpref. Thanks! Xavier. -Mensaje original- De: Bird-users mailto:bird-users-boun...@network.cz>> En nombre de Alarig Le Lay Enviado el: jueves, 24 de marzo de 2022 13:43 Para: bird-users@network.cz<mailto:bird-users@network.cz> Asunto: Re: Filter based on BGP protocol status ... On Thu 24 Mar 2022 07:43:03 GMT, Douglas Fischer wrote: > 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. More simply, you can add a community on the non-ddos-protected provider to make them lower the localpref to peer routes, and stop the prepend. > Em qua., 23 de mar. de 2022 12:10, Xavier Trilla > mailto:xavier.tri...@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 > > > > > >
RE: Filter based on BGP protocol status ...
>More simply, you can add a community on the non-ddos-protected provider to >make them lower the localpref to peer routes, and stop the prepend. We tried, but some providers basically ignore everything if you have a direct connection with them. They just forward you the traffic despite prepending or localpref. Thanks! Xavier. -Mensaje original- De: Bird-users En nombre de Alarig Le Lay Enviado el: jueves, 24 de marzo de 2022 13:43 Para: bird-users@network.cz Asunto: Re: Filter based on BGP protocol status ... On Thu 24 Mar 2022 07:43:03 GMT, Douglas Fischer wrote: > 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. More simply, you can add a community on the non-ddos-protected provider to make them lower the localpref to peer routes, and stop the prepend. > Em qua., 23 de mar. de 2022 12:10, Xavier Trilla > > 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 > > > > > >
RE: Filter based on BGP protocol status ...
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 Enviado el: jueves, 24 de marzo de 2022 13:35 Para: Xavier Trilla CC: Douglas Fischer ; BIRD Users 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 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 Enviado el: jueves, 24 > de marzo de 2022 11:43 > Para: Xavier Trilla > CC: BIRD Users > 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 > escreveu: > > Hi, > > > > I’m quite sure this cannot be done, but I also know there
RE: Filter based on BGP protocol status ...
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 Enviado el: jueves, 24 de marzo de 2022 11:43 Para: Xavier Trilla CC: BIRD Users 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 mailto:xavier.tri...@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
RE: Filter based on BGP protocol status ...
Hi Maria, > I'd suggest to depreference the B-route by AS path stuffing, like 3-5 times > or so, to effectively force usage of the other route while still exporting it. Yes, that's what we usually do, but we have found providers that if the client IPs are on their own AS -to which we are connected directly- will route directly to us discarting prepending. In this specific scenario, is a service that will be oriented to customers who suffer big DDOS attacks regularly. We have one provider which specializes on DDOS scrubbing services and the ranges for these specific clients will be only announced via that provider to ensure traffic is always filtered. But if the specific provider has an issue or a maintenance we'll have to publish the ranges on other providers and rely on owr DDOS local scrubbing system and blackhole communities for wosrt case scenarios. We already have in place scripts that inject routes on kernel tables when a specific subnet needs to be filtered -and prepended on non DDOS protected providers- so most probably we'll adapt what we already have. > No and it isn't in a short-term plan. The multithreaded version may get some > better API to do it, yet I won't promise anything specific. That would be great. I would also like to use the oportunity to tell you how much do we love Bird! It's been our main BGP system for more than a decade, and it's one of the most flexible and stable pieces of software we use. Congratulations to you and the rest of the team for the amazing work you do! Thanks! Xavier. -Mensaje original- De: Bird-users En nombre de Maria Matejka Enviado el: jueves, 24 de marzo de 2022 8:27 Para: bird-users@network.cz Asunto: Re: Filter based on BGP protocol status ... Hello! > Is there any way to filter a export route based on another BGP session > status? No and it isn't in a short-term plan. The multithreaded version may get some better API to do it, yet I won't promise anything specific. > 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.) I'd suggest to depreference the B-route by AS path stuffing, like 3-5 times or so, to effectively force usage of the other route while still exporting it. Maria
Filter based on BGP protocol status ...
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
Re: Check bgp_path.len without some AS
This is exactly what I've been trying to do, most probably I had something
wrong with the syntax and that's why it was not working, I'll test it this week.
Thanks!
Saludos Cordiales,
Xavier Trilla P.
Clouding.io<https://clouding.io/>
?Un Servidor Cloud con SSDs, redundado
y disponible en menos de 30 segundos?
?Pru?balo ahora en Clouding.io<https://clouding.io/>!
El 6 gen 2019, a les 1:30, Ondrej Zajicek
mailto:santi...@crfreenet.org>> va escriure:
On Thu, Jan 03, 2019 at 11:10:00PM +0000, Xavier Trilla wrote:
Hi,
For some route selection configurations I need to check the bgp_path.len
without some AS numbers.
I tried something like:
bgp_path.delete(AS_1);
bgp_path.delete(AS_2);
if bgp_path.len < N then ...
But doing this I modify permanently the AS path.
I've tried using a temp variable, but looks like bird doesn't allow to create
bgppath "variables".
Hi
Although approach suggested by Alexander Zubkov is applicable,
i would note that BIRD allows bgppath variables, see:
filter testfilter
bgppath pp;
{
pp = bgp_path;
pp = prepend(pp, 65500);
pp = prepend(pp, 65500);
print pp, " ", pp.len;
accept;
}
The only think that is strange is that operators like delete or prepend
cannot be used with 'dot-syntax' (i.e. pp.prepend(X)), but must be used
with 'function-syntax' (i.e. pp = prepend(pp, X)).
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email:
santi...@crfreenet.org<mailto:santi...@crfreenet.org>)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
wwwkeys.pgp.net<http://wwwkeys.pgp.net>)
"To err is human -- to blame it on a computer is even more so."
Re: Check bgp_path.len without some AS
Hi Alexander, That’s interesting I will play with this syntax, although I’m not 100% sure if I will be able to use it (I need to remove two As numbers per bgp_path) but maybe I can work something out. Thanks! Xavier El 4 gen 2019, a les 1:47, Alexander Zubkov va escriure: > Hi, > > Something like this worked for me: > > delete(bgp_path, ).len < N > > >> On Fri, Jan 4, 2019 at 12:19 AM Xavier Trilla >> wrote: >> >> Hi, >> >> >> >> For some route selection configurations I need to check the bgp_path.len >> without some AS numbers. >> >> >> >> I tried something like: >> >> >> >> bgp_path.delete(AS_1); >> >> bgp_path.delete(AS_2); >> >> >> >> if bgp_path.len < N then … >> >> >> >> But doing this I modify permanently the AS path. >> >> >> >> I’ve tried using a temp variable, but looks like bird doesn’t allow to >> create bgppath “variables”. >> >> >> >> Any ideas about how this could be achieved? >> >> >> >> Thanks! >> >> Xavier >> >>
Check bgp_path.len without some AS
Hi, For some route selection configurations I need to check the bgp_path.len without some AS numbers. I tried something like: bgp_path.delete(AS_1); bgp_path.delete(AS_2); if bgp_path.len < N then ... But doing this I modify permanently the AS path. I've tried using a temp variable, but looks like bird doesn't allow to create bgppath "variables". Any ideas about how this could be achieved? Thanks! Xavier
RE: Question about BIRD feature.
It uses the typical attributes, local_pref, preference, etc… Like any other BGP router. Saludos Cordiales, Xavier Trilla P. Clouding.io<https://clouding.io/> ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io<https://clouding.io/>! De: Bird-users En nombre de Marcio Enviado el: miércoles, 12 de septiembre de 2018 21:32 Para: bird-users@network.cz Asunto: Question about BIRD feature. Dear, Is it possible to know which criteria BIRD used to prefer one route rather than another directed to the same BGP prefix?
RE: Constant delete / add route after upgrade to 1.6.3
Hi Ondrej, Thanks for your reply, know I see why it's done this way. But Im wondering, could that lead to packed loss or the remove/add is fast enough? I mean, we just push to the kernel the best paths, so in this scenario a destination could be without a destination for a brief period of time, or the update is fast enough to not even affect a high traffic connection? The alternative I'm seeing is publishing all routes to kernel with weights, but that's something I would like to avoid (I don't want to publish several million routes to the kernel :/ ) Thanks! Saludos Cordiales, Xavier Trilla P. Clouding.io ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io! -Mensaje original- De: Ondrej Zajicek <santi...@crfreenet.org> Enviado el: miércoles, 9 de mayo de 2018 15:48 Para: Xavier Trilla <xavier.tri...@clouding.io> CC: Maria Jan Matějka <jan.mate...@nic.cz>; bird-users@network.cz Asunto: Re: Constant delete / add route after upgrade to 1.6.3 On Tue, May 08, 2018 at 08:29:06PM +0000, Xavier Trilla wrote: > Hi Maria, > > For what I'm seeing, looks like every time birds gets a route update via BGP > the route is replaced, I enabled debug in kernel protocol and I'm seeing this: > > 2018-05-08 22:20:32 icewall_01_BGP > added [best] > 80.84.147.0/24 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol > 80.84.147.0/24 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 kernel1 < replaced 80.84.147.0/24 via > 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 icewall_01_BGP > added [best] > 78.40.178.0/24 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol > 78.40.178.0/24 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 kernel1 < replaced 78.40.178.0/24 via > 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 icewall_01_BGP > added [best] > 64.17.246.0/23 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol > 64.17.246.0/23 via 172.17.0.1 on vlan10 > 2018-05-08 22:20:32 kernel1 < replaced 64.17.246.0/23 via > 172.17.0.1 on vlan10 > > > But does it make sense? I mean, deleting and reading the route to replace it > when a route update is received doesn't seem to make much sense considering > the gateway does not change. Hi It is true that we send a route to the kernel if there is any change in the route, even if the change is irrelevant for the kernel itself. They may be export filters in kernel that are dependent on any route attributes so it is hard to predict whether the change is relevant or not. > Also, I guess removing and adding the route again could lead to some packet > loss. We could use replace netlink operation instead of remove/add, but that has some other problems (like insufficient protection against overwriting alien routes). > Maybe bird needs to keep some information in the route in order to keep sync > and that's why it needs to replace it? Or there is anything I'm missing... We could keep that information but that essentialy means double memory footprint for simple setups. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
RE: Constant delete / add route after upgrade to 1.6.3
Hi Maria, For what I'm seeing, looks like every time birds gets a route update via BGP the route is replaced, I enabled debug in kernel protocol and I'm seeing this: 2018-05-08 22:20:32 icewall_01_BGP > added [best] 80.84.147.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol 80.84.147.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 kernel1 < replaced 80.84.147.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 icewall_01_BGP > added [best] 78.40.178.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol 78.40.178.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 kernel1 < replaced 78.40.178.0/24 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 icewall_01_BGP > added [best] 64.17.246.0/23 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 icewall_01_BGP < rejected by protocol 64.17.246.0/23 via 172.17.0.1 on vlan10 2018-05-08 22:20:32 kernel1 < replaced 64.17.246.0/23 via 172.17.0.1 on vlan10 But does it make sense? I mean, deleting and reading the route to replace it when a route update is received doesn't seem to make much sense considering the gateway does not change. Also, I guess removing and adding the route again could lead to some packet loss. Maybe bird needs to keep some information in the route in order to keep sync and that's why it needs to replace it? Or there is anything I'm missing... Cheers! Saludos Cordiales, Xavier Trilla P. Clouding.io ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io! -Mensaje original- De: Maria Jan Matějka <jan.mate...@nic.cz> Enviado el: martes, 8 de mayo de 2018 16:24 Para: bird-users@network.cz; Xavier Trilla <xavier.tri...@clouding.io>; bird-users@network.cz Asunto: RE: Constant delete / add route after upgrade to 1.6.3 On May 8, 2018 3:44:20 PM GMT+02:00, Xavier Trilla <xavier.tri...@clouding.io> wrote: > Hi, > > Some extra Info: I've changed the scan time from 20 to 60 on the > kernel and the CPU load on the machine has reduced, but I still see > too many route changes. > > Thanks! > > > Saludos Cordiales, > Xavier Trilla P. > Clouding.io<https://clouding.io/> > > ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 > segundos? > > ¡Pruébalo ahora en Clouding.io<https://clouding.io/>! > > De: Bird-users <bird-users-boun...@network.cz> En nombre de Xavier > Trilla Enviado el: martes, 8 de mayo de 2018 14:02 > Para: bird-users@network.cz > Asunto: Constant delete / add route after upgrade to 1.6.3 > > Hi, > > We've upgraded recently to 1.6.3 (We were using 1.2.5, which we had > running for like 8 years!) and after the upgraded we are seeing a > weird behavior. > > When running ip monitor route in the machine, looks like bird is > constantly removing and adding routes, which could be considered > normal, but the thing is that it deletes a route and then adds the > same route again (Those routes are received via BGP): > > Heres an example: > > 103.72.2.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted > 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird > 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted > 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird > 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted > 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird > 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted > 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird > 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted > 64.70.30.0/24 via 91.126.95.153 dev vlan111 proto bird > 64.70.30.0/24 via 212.80.191.185 dev vlan2 proto bird > > At the same time we are seeing the following messages on bird log: > > May 8 13:56:39 icewall-01 bird: Kernel dropped some netlink messages, > will resync on next scan. > May 8 13:57:02 icewall-01 bird: Kernel dropped some netlink messages, > will resync on next scan. > May 8 13:57:27 icewall-01 bird: Kernel dropped some netlink messages, > will resync on next scan. > May 8 13:57:32 icewall-01 bird: Kernel dropped some netlink messages, > will resync on next scan. > May 8 13:57:59 icewall-01 bird: Kernel dropped some netlink messages, > will resync on next scan. > > Any ideas why this might be happening? > > Thanks! > > Saludos Cordiales, > Xavier Trilla P. > Clouding.io<https://clouding.io/> > > ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 > segundos? > > ¡Pruébalo ahora en Clouding.io<https://clouding.io/>! Hello, have you tried to switch on BGP protocol tracing? Aren't the routes really sent in this way? Haven't y
RE: Constant delete / add route after upgrade to 1.6.3
Hi, Some extra Info: I've changed the scan time from 20 to 60 on the kernel and the CPU load on the machine has reduced, but I still see too many route changes. Thanks! Saludos Cordiales, Xavier Trilla P. Clouding.io<https://clouding.io/> ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io<https://clouding.io/>! De: Bird-users <bird-users-boun...@network.cz> En nombre de Xavier Trilla Enviado el: martes, 8 de mayo de 2018 14:02 Para: bird-users@network.cz Asunto: Constant delete / add route after upgrade to 1.6.3 Hi, We've upgraded recently to 1.6.3 (We were using 1.2.5, which we had running for like 8 years!) and after the upgraded we are seeing a weird behavior. When running ip monitor route in the machine, looks like bird is constantly removing and adding routes, which could be considered normal, but the thing is that it deletes a route and then adds the same route again (Those routes are received via BGP): Heres an example: 103.72.2.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 64.70.30.0/24 via 91.126.95.153 dev vlan111 proto bird 64.70.30.0/24 via 212.80.191.185 dev vlan2 proto bird At the same time we are seeing the following messages on bird log: May 8 13:56:39 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:02 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:27 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:32 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:59 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. Any ideas why this might be happening? Thanks! Saludos Cordiales, Xavier Trilla P. Clouding.io<https://clouding.io/> ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io<https://clouding.io/>!
Constant delete / add route after upgrade to 1.6.3
Hi, We've upgraded recently to 1.6.3 (We were using 1.2.5, which we had running for like 8 years!) and after the upgraded we are seeing a weird behavior. When running ip monitor route in the machine, looks like bird is constantly removing and adding routes, which could be considered normal, but the thing is that it deletes a route and then adds the same route again (Those routes are received via BGP): Heres an example: 103.72.2.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird 103.72.1.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird 177.75.72.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird 185.165.122.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird 196.46.242.0/24 via 91.126.95.153 dev vlan111 proto bird Deleted 64.70.30.0/24 via 91.126.95.153 dev vlan111 proto bird 64.70.30.0/24 via 212.80.191.185 dev vlan2 proto bird At the same time we are seeing the following messages on bird log: May 8 13:56:39 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:02 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:27 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:32 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. May 8 13:57:59 icewall-01 bird: Kernel dropped some netlink messages, will resync on next scan. Any ideas why this might be happening? Thanks! Saludos Cordiales, Xavier Trilla P. Clouding.io<https://clouding.io/> ¿Un Servidor Cloud con SSDs, redundado y disponible en menos de 30 segundos? ¡Pruébalo ahora en Clouding.io<https://clouding.io/>!
