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