Can you explain what you mean? How should I change my scripts? I think it will be a good workaround when I simply use functions instead of filters, so I can bypass some parameters. *protocol bgp *'peer-neo' {

ipv4 { export where *filter_common_ipv4_out(* "peer-neo" *)*; }; } *function *filter_common_ipv4_out( string remote_peer_name ) { if remote_peer_name = 'peer-neo' then .....; }

It is stupid because i define the peer-name twice. But for now it will do the job relatively easily. I have over 40 peers, so I have to write the function / filter for common use. Am Mi., 8. Apr. 2020 um 19:39 Uhr schrieb Maria Matějka < maria.matejka@nic.cz>:

Hello!

Currently not supported. Is simple exact match enough for your purposes? This may be simply added to the filter language.

Maria

On April 8, 2020 6:47:49 PM GMT+02:00, Michael Rack <mail@michaelrack.de> wrote:

...

Hi Guys,

if i am in the EXPORT-Routine, how can i access the "protocol-name" of that instance that is currently using my function?

If I rely on "proto" I get the protocol-name where the route comes from. That is not what I want.

*protocol bgp *'peer-neo' {

...

ipv4 { export filter *filter_common_ipv4_out*; }; } *filter * filter_common_ipv4_out() { if proto = 'peer-neo' then .....; }

How can I match for 'peer-neo' ?

Thank you. Michael.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Aaahh now i see... Currently I do pattern matching... Sorry. function is_filtered_proto_in ( string p )

{ return false; } function is_filtered_proto_out ( string p ) { if p ~ "*2220" then { bgp_community.add((65000,11120)); print "Reached is_filtered_proto_out( ", p, " ): Adding Community 65000,11120"; } if p = "*2221" then { bgp_community.add((65000,11050)); print "Reached is_filtered_proto_out( ", p, " ): Adding Community 65000,11050"; } return false; }

Am Mi., 8. Apr. 2020 um 20:09 Uhr schrieb Maria Matějka < maria.matejka@nic.cz>:

I say that there is no support for such a thing yet but I may be able to provide you with a patch (we want to add it to the filter language).

Maria

On April 8, 2020 7:58:41 PM GMT+02:00, Michael Rack <mail@michaelrack.de> wrote:

...

Can you explain what you mean?

How should I change my scripts?

I think it will be a good workaround when I simply use functions instead of filters, so I can bypass some parameters.

*protocol bgp *'peer-neo' {

...

ipv4 { export where *filter_common_ipv4_out(* "peer-neo" *)*; }; } *function *filter_common_ipv4_out( string remote_peer_name ) { if remote_peer_name = 'peer-neo' then .....; }

It is stupid because i define the peer-name twice. But for now it will do the job relatively easily.

I have over 40 peers, so I have to write the function / filter for common use.

Am Mi., 8. Apr. 2020 um 19:39 Uhr schrieb Maria Matějka < maria.matejka@nic.cz>:

...

Hello!

Currently not supported. Is simple exact match enough for your purposes? This may be simply added to the filter language.

Maria

On April 8, 2020 6:47:49 PM GMT+02:00, Michael Rack <mail@michaelrack.de> wrote:

...

Hi Guys,

if i am in the EXPORT-Routine, how can i access the "protocol-name" of that instance that is currently using my function?

If I rely on "proto" I get the protocol-name where the route comes from. That is not what I want.

*protocol bgp *'peer-neo' {

...

ipv4 { export filter *filter_common_ipv4_out*; }; } *filter * filter_common_ipv4_out() { if proto = 'peer-neo' then .....; }

How can I match for 'peer-neo' ?

Thank you. Michael.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

If I may chime in, briefly, here ... This request relates to an "improvement suggestion" I made a few years back, but it was during the hot phase before 2.x was released, so I guess it was lost. Back then I was asking for "context variables/constants", i.e. the peer's AS number in the context of a filter/function called from a BGP proto, etc. One thing to solve with this approach would be, how to define these context-variables if you just wanted to manually execute a function/filter for testing, but that should be doable. Ah ... just found the old mail, dubbed "Making a wish ... errr ... *four* wishes! 😳" from January 24th 2018 - I'll attach a copy of it to this one, just for reference. In it I already made a few suggestions re: potential candidates for such "context-variables". Again, thanks for all the good work! Clemens PS: The whole thread, back then, had a number of suggestions you gave a 🤔-maybe rating to ... i.e., "ipset protocol" and others ... interesting to see all these again. 😉 ---- excerpt from previous mail exchange ----

...

...

As one of my many uses for BIRD is in large wireless environments (i.e., IETF meetings) I am very interested in keeping the amount of multicast traffic as low as possible. The standards allow for a router to (immediately) respond with a unicast RA to an RS as an alternative to sending out a multicast RA „some (short, random) time“ after receiving an RS. Many others (Juniper, et.al.) have implemented this and I’d like to see this in BIRD too. The code changes are apparently very simple, so I almost did it myself, but then I didn’t want to interfere with ongoing 2.x developments. (lame excuse, I know …)

Seems simple and makes perfect sense. Will do.

Thank you. That was easy. (the next IETF meeting, where this could become be very useful, will be in mid-March … :-) :-) :-)

it didn’t make it into 2.0.2 and/or 1.6.4, though, right? (I’m sitting here in London still emitting lots of multicast RAs … 😩😩😩)

...

...

Context dependent (global) „variables“ for functions/filters

I (and probably others too) would really enjoy having more global variables defined for use inside filters & functions, depending on the context within which the respective filter/function is being called. The most obvious ones would be the peer’s (and our own) AS number (in the context of BGP protocols), the filtering direction, the protocol (type and name), the next hop’s address (where applicable), and so on.

Yes, I know, most of these could be explicitly given (at least to a function) when calling it as the import/export filter for a protocol with a „where“ clause, but that would defeat the purpose of using templates (which I really do like and use a lot).

The general concept of having „globals“ inside functions/filters is already there - just presently only in the context of the route that is being evaluated. I’d like to see this expanded into other contexts as described above.

That is an interesting idea and also seems simple, although there are some caveats, e.g. filters using such context-dependent-constants would probably work for 'show route filter'.

Yes, I had forgotten about this (very useful) feature. However, the syntax for this could be easily amended to allow the definition of such variables via the command line, i.e.,

show route filter foo(a=1, b="bla", ...)

...

It may be useful if you could make a list of suggested constants.

Well ... here is what comes to mind easily: (NB: these are not the "names" of the variables I propose; we should come up with a good naming scheme once we settled on an initial list of variables)

router id protocol name protocol type address family / channel-type local as remote as local interface name (outbound interface) local address (outbound interface) remote address external variables (see below)

Variables, of course, only have values inside "useful" contexts, i.e, AS number inside BGP, etc. and are otherwise "undefined".

I'l also like to propose the introduction of global variables (vs. existing constants), which can be set in the configuration file, via the command-line (i.e., "bird -D foo=42" and at runtime via birdc. Again, naming conventions have to be observed, etc. and the manual must emphasize on when exactly filters are evaluated and such.

But this would allow to build a config, whose behavior could be altered at runtime, i.e., start-up in "test-mode" and then later be switched over to "production-mode" through birdc (or any other tool using the API), among many other possibilities. It would also be nice, if variables could hold lists, most notably prefix-lists of all sorts and AS/community lists. In this case the birdc interface would require add, remove, list functions in addition to set and delete. (yeah, I know ... way more things to specify here, like uniqueness, order, etc. -- I'll hold back until you promise not to shoot down this idea completely ;-) Also: Can filters/functions set,add,remove,delete variables too ... oh, my /o\ ...) - would be nice, so one could easily implement one's own status counters ...

Anything I can do from my side to help this along? ;-) Aaaand, of course, here is another „thing“ I would like to see in future BIRD version: As the times where one would have proper link-state on circuits carrying up- or downstream BGP are clearly over these days, one would/should consider using BFD instead to determine reachability of one’s peer. However: Many ISPs („Carriers“) do not support thus due to lameness, stupidness or other means of inability. So: Can we have a very simple „ping“ functionality, which could fulfill BFD’s role in such cases? Like „ping every second, if three pings in a row went missing consider the link down!“. That would also be tremendously helpful for „simple“ (dumb) ISPs links who aren’t using any routing protocol at all („just point a default route at out router“) to „verify“ a static default route. If „ping“ gives you the creeps for one reason or another, can we use an „ARP state“ (for the peer’s address) instead? (at least for the „direct“ static routes) Thanks, Clemens (from the IETF-101 meeting in London)