Modifying function called in filter does not take effect

[Eric Cables]

I'm hoping someone can tell me whether this behavior is expected or not.

I am using BIRD as a RR, and running into a behavior where modifying a
policy, within a function called by a filter, requires a hard BGP session
reset or stop/start of BIRD, rather than a 'configure soft.' Route Refresh
is supported by the RR client.

I am using a unique filter for each RR client; each filter calls a function
that is shared amongst all filters -- basically matching routes that all RR
clients should receive. This was first instantiated with a single BGP
community match in the function, and a 'configure soft' worked fine. I then
went back and added a second if statement to the function, expecting
'configure soft' to put the new policy into effect, but what I noticed is
that the only way for RR clients to receive the newly accepted routes was
to hard down/up the BGP session.

Anecdotally, a 'show route filter router1_out' (after 'configure soft') did
match the routes I was expecting the RR client to receive, but until the
BGP session was hard cleared to the RR client, they were not advertised by
BIRD.

Here is the relevant configuration (I've bolded the new configuration that
was added, which did not result in an advertisement to the RR client):

# RR client template
template bgp rr_client {
    description "Template for route reflector clients";
        local as 65412;
        hold time 180;
        source address 2.2.2.2 ;
        rr client;
        rr cluster id 1.1.1.1;
        import all;
        export none;
        add paths;
}

# Globally reflected routes function
function global_routes() {
   # Match 65000-65499,100-200
    if bgp_community ~ [(65000..65499,100..200)] then accept;
*   # Match 65000-65499,300-400*
*    if bgp_community ~ [(65000..65499,300..400)] then accept;*
}

# Outbound filter for router1
filter router1_out {
  global_routes();
  reject;
}

protocol bgp 'router1' from rr_client {
    neighbor 1.2.3.4 as 65412;
    import all;
    export filter router1_out;
}

As mentioned, the output of 'show route filter router1_out' (after a
'configure soft') did return the expected routes, but they were not
advertised to the 'router1' RR client until the session was hard cleared.

Is this expected behavior?

-- Eric Cables
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150321/d77d4785/attachment.html>