Feature request - syslog equivalent for filter language

[Maria Matejka]

>>> Ideally I’d like to replace a statement like
>>> print "REJECTING: ",net.ip,"/",net.len," received from ",from," AS 
>>> ",bgp_path.first,": Prefix is a martian";
>>> with
>>> syslog LOG_WARNING, "REJECTING: ",net.ip,"/",net.len," received from 
>>> ",from," AS ",bgp_path.first,": Prefix is a martian”;
>>> Right now I’m just commenting out the print statements that get hit 
>>> too often to prevent spamming log files with ten thousands of rows, 
>>> and ideally I’d like to use the log command that Bird uses for it’s 
>>> own messages to set where these messages should go based on relevance.
>>
>> This seems feasible, based on the user point of view. What is worse, 
>> the print command itself is hacked into the filter language in quite a 
>> crude and insane way.
>>
>> If it is enough for you, there is currently a fundamental filter 
>> rewrite undergoing code review and testing before being merged into v2 
>> branch. After this is merged, it is possible to simplify the print 
>> command quite a lot and also to implement syslog. Is that enough for you?
>>
>> I don't like implementing this in v1.6.x – the legacy branch will 
>> never get the new interpreter.
>>
> That would be great - it’s not super urgent. I can see how it’s not 
> feasible to back port the new filtering to the 1.6 tree. Looking forward 
> to try the new fast filtering.

If you are brave, look at the "faster-filter-merged" branch. There are 
still some minor bugs, anyway it shall be stable in common cases.

> Would it however, for compatibility’s sake, be possible for the 1.6 code 
> to get an alias from syslog *, “foo”; to print “foo”; ?

No problem; that's quite simple.

> Background: I’ve been building Papageno ( 
> https://github.com/asteroidhq/papageno ) to create BGP configs that are 
> ‘default free zone safe’, and currently it produces equivalent configs 
> for Bird 1.6 and 2.0. While I can work around not having a syslog 
> statement for the 1.6 code this difference would create a massive 
> headache on my side.

Fine! The upcoming changes may make some of the filter features much 
faster than others. We have also done a »custom route attribute« option 
that is faster than commonly used pattern »set community on import, drop 
community on export«. If you wanted to consult your filters in person, 
feel free to reach me e.g. on IETF-104, Euro-IX 34 or RIPE 78.

Maria