export filter that checks for existance of another route?

Paul J R me at pjr.cc
Tue Sep 2 16:50:50 CEST 2014


I figured it would be the case, i can understand why that might not be 
possible from the perspective of performance if nothing else.

What actually would be nice to be able to do instead then (big "perhaps" 
here) is rather then getting the filter to look up the route table, be 
able to have a route filter create a globally accessable flag when a 
route is imported and have it clear automatically when it disappears.

i.e. some global type variable you can define that that into the normal 
data types definable elsewhere which can be manipulated from filters, 
but are attached to the routes that trigger them.

Or maybe a more bird-like way of doing things would be to have a filter 
type that's called when a route is being dropped? As far as i know, such 
a thing doesnt exist currently.

On 3/09/2014 12:32 am, Job Snijders wrote:
> On Tue, Sep 02, 2014 at 01:44:59PM +0200, Ondrej Zajicek wrote:
>> On Sat, Aug 30, 2014 at 12:13:30AM +1000, Paul J R wrote:
>>> Hi All,
>>>
>>> First time post, i've been playing with bird for some time, but there is one
>>> thing i cant figure out how to do and that is use the existence of a
>>> specific route as part of a filter.
>>>
>>> for example, if the filter is processing a route to 4.3.2.0/24, check if a
>>> route to 1.2.3.4/32 (exact) exists, if so then accept, otherwise reject. Is
>>> this something that is possible? or do route filters only have the ability
>>> to check against the information thats sent to the filter itself?
>> It is not possible, for several reasons filters could only check each
>> route independently.
> I think it would be a terrific feature that would have lots of
> interesting properties in the traffic engineering space or other area's
> such as routing security/RPKI.
>
> A small write up on one example is detailed in this thread:
>
>      http://mailman.nanog.org/pipermail/nanog/2014-August/069506.html
>
> The short version is that some operators feel that today's RPKI
> deployment options in terms of local policy are too black/white. It
> would be nice if I can reject invalid prefixes as long as there is a
> covering valid announcement, if the valid announcement disappears I'd
> want to accept invalid announcements if they are from the registered
> origin.
>
> Kind regards,
>
> Job
>





More information about the Bird-users mailing list