Hi list. Is there an easy way to list routes that do NOT match filter? I can do "show route filter f_myfilter" to list routes that would match filter. I'm hoping for something like "show route filter !f_myfilter" to list routes that would be rejected. I'd like to display routes rejected in a pipe protocol between two routing tables so I still have all routes that are rejected by filter in BIRD. Kind regards Matej Vadnjal Arnes
On Tue, Mar 20, 2012 at 10:50:33AM +0100, Matej Vadnjal wrote:
Hi list.
Is there an easy way to list routes that do NOT match filter?
Sorry, AFAIK it is not currently possible. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tuesday 20 of March 2012 23:31:04 Ondrej Zajicek wrote:
On Tue, Mar 20, 2012 at 10:50:33AM +0100, Matej Vadnjal wrote:
Is there an easy way to list routes that do NOT match filter?
Sorry, AFAIK it is not currently possible.
Thank you Ondrej. I'll just generate another set of filters for this then. Kind regards Matej Vadnjal Arnes
On Thu, Mar 22, 2012 at 09:08:15AM +0100, Matej Vadnjal wrote:
On Tuesday 20 of March 2012 23:31:04 Ondrej Zajicek wrote:
On Tue, Mar 20, 2012 at 10:50:33AM +0100, Matej Vadnjal wrote:
Is there an easy way to list routes that do NOT match filter?
Sorry, AFAIK it is not currently possible.
Thank you Ondrej. I'll just generate another set of filters for this then.
One possible way is to write filters as functions (returning true or false) and then use 'where' to create filters: 'import where xxx()', 'show route where ! xxx()'. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej, Le jeudi 22 mars 2012 à 11:45 +0100, Ondrej Zajicek a écrit :
One possible way is to write filters as functions (returning true or false) and then use 'where' to create filters: 'import where xxx()', 'show route where ! xxx()'.
This makes me think about why is there a difference between functions and filters in the first place? Yes, functions accept argument, but then? They return a value… a bit like filters return a decision. So, what's really the big difference? In my use of BIRD, I end up like you just suggested, transforming every filter into functions and using “import where …”. This make me return boolean values that are a bit less clear than accept/reject statements. I am definitely not pleased by the choice I have to make between fonction and filter. I am wondering: is there a way to unify both? Do you think it's a good idea? Do you have suggestions on how to do that? (i.e. we should do it in a backward compatible fashion) The way I see it, I would make filter into functions that return booleans, and change 'accept' and 'reject' into “aliases” to 'return true' and 'return false'. Concerning the message attached to them, I don't really know… Make these keywords a bit more specials and make them 'print xxx; return true/false;'? Thanks for any clue on this, -- Benjamin
On Thu, Mar 22, 2012 at 02:57:20PM +0100, Benjamin Cama wrote:
Hi Ondrej,
Le jeudi 22 mars 2012 ?? 11:45 +0100, Ondrej Zajicek a écrit :
One possible way is to write filters as functions (returning true or false) and then use 'where' to create filters: 'import where xxx()', 'show route where ! xxx()'.
This makes me think about why is there a difference between functions and filters in the first place? Yes, functions accept argument, but then? They return a value??? a bit like filters return a decision. So, what's really the big difference?
IMHO functions are more general that filters, i don't really see why there are explicit named filters here. One minor advantage is that named filters are displayed in 'show protocols all'.
I am wondering: is there a way to unify both? Do you think it's a good idea? Do you have suggestions on how to do that? (i.e. we should do it in a backward compatible fashion)
I think that the simplest way is just to not use named filters.
The way I see it, I would make filter into functions that return booleans, and change 'accept' and 'reject' into ???aliases??? to 'return true' and 'return false'. Concerning the message attached to them, I don't really know??? Make these keywords a bit more specials and make them 'print xxx; return true/false;'?
This is not a good idea - you could use accept/reject even in function (but it has different meaning - do not propagate return value and accept/reject immediately). You could have a boolean function whose return value has a different meaning than accept/reject, and the function could internally call accept or reject in some cases. So the suggested change definitely wouldn't be backward compatible. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello!
IMHO functions are more general that filters, i don't really see why there are explicit named filters here. One minor advantage is that named filters are displayed in 'show protocols all'.
One possible use is calling such filters from the CLI. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Noli tangere fila metalica, ne in solum incasa quidem.
On Mon, Mar 26, 2012 at 10:20:04PM +0200, Martin Mares wrote:
Hello!
IMHO functions are more general that filters, i don't really see why there are explicit named filters here. One minor advantage is that named filters are displayed in 'show protocols all'.
One possible use is calling such filters from the CLI.
That is not a big difference compared to functions: show route filter fi show route where fn() -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Benjamin Cama -
Martin Mares -
Matej Vadnjal -
Ondrej Zajicek