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