router_id or source neighbor in import/export filter for dynamic BGP peers
Hi! I use dynamic BGP peers in my RR. It's very simple and comfortable. import/export filters are same for all dynamic neighbors. How to determine a neighbor? Using what variables? I will plan use filters likes that, but I can't find what I need send to function "getneighbortype"..... function getneighbortype(ip neighbor) -> int { case neighbor { 1.1.1.1 : return 1; # router with big RIR 1.1.1.2 : return 3; # router with small RIR else: return 0; # unknown router } } filter fromclientrr { int nt = getneighbortype(*router id / src neighbor*); if nt = 0 then reject; bgp_large_community.add((0,1,nt)); accept; } filter toclientrr { int nt = getneighbortype(*router id / src neighbor*); if net.len = 0 && nt ~ [0, 3] then accept; if nt ~ [1] then accept; reject; } -- Regards, Mikhail Mayorov
Hello, On Fri, Sep 27, 2024 at 02:48:07PM +0300, Mikhail Mayorov wrote:
I use dynamic BGP peers in my RR. It's very simple and comfortable. import/export filters are same for all dynamic neighbors. How to determine a neighbor? Using what variables?
I would expect that in common cases, the neighbor would be also in the `bgp_next_hop` attribute. Is that not this case? Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Hello Maria, Not exactly. bgp_next_hop is are route attribute. I want to know to which neighbor I am currently exporting or importing routes. In a static neighbor configuration, I know exactly which filter is currently running and with which neighbor. Accordingly, I decide which routes to send or accept, and which not to send or receive with this neighbor. How can I do this in a dynamic configuration? 27.09.2024 15:34, Maria Matejka пишет:
Hello,
On Fri, Sep 27, 2024 at 02:48:07PM +0300, Mikhail Mayorov wrote:
I use dynamic BGP peers in my RR. It’s very simple and comfortable. import/export filters are same for all dynamic neighbors. How to determine a neighbor? Using what variables?
I would expect that in common cases, the neighbor would be also in the |bgp_next_hop| attribute. Is that not this case?
Maria
– Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-- Regards, Mikhail Mayorov PG19, founder and inspirer B.Bulvarnaya 11, Taganrog, Russia, 347913 tel work: +7 8634 431431 (ext 101) tel mobile: +7 905 4309006 pg19.ru
On Fri, Sep 27, 2024 at 04:06:04PM +0300, Mikhail Mayorov wrote:
Hello Maria,
Not exactly. bgp_next_hop is are route attribute. I want to know to which neighbor I am currently exporting or importing routes. In a static neighbor configuration, I know exactly which filter is currently running and with which neighbor.
Hello I think you can use 'from' attribute for this purpose. That is not BGP route attribute, but BIRD internal route attribute. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hi all, It seems to me that Mikhail wants to know the protocol information, in context of which the filter is executed. And he also wants it in the export filter, to know protocol/peer/etc. Regards, Alexander On Fri, Sep 27, 2024, 17:23 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Sep 27, 2024 at 04:06:04PM +0300, Mikhail Mayorov wrote:
Hello Maria,
Not exactly. bgp_next_hop is are route attribute. I want to know to which neighbor I am currently exporting or importing routes. In a static neighbor configuration, I know exactly which filter is currently running and with which neighbor.
Hello
I think you can use 'from' attribute for this purpose. That is not BGP route attribute, but BIRD internal route attribute.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
On Fri, Sep 27, 2024 at 06:05:47PM +0200, Alexander Zubkov via Bird-users wrote:
It seems to me that Mikhail wants to know the protocol information, in context of which the filter is executed. And he also wants it in the export filter, to know protocol/peer/etc.
Yeah, it looks like this, and sadly, we don't have such information easily available for now. Implementing this is in our backlog and we are basically overwhelmed with other overdue tasks (like finalizing the multithreading, EVPN or TCP-AO). It is expectable to get this somewhere around BIRD 3.2 or 3.3 (take me with a grain of salt please). It is quite easy to expose _something_ by some hacks but it would mean polluting the filters and configuration by yet another inconsistent feature which we then would have to maintain for much longer than acceptable. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (4)
-
Alexander Zubkov -
Maria Matejka -
Mikhail Mayorov -
Ondrej Zajicek