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
