On Fri, 08 Mar 2013, Hans van Kranenburg wrote:
When converting the other router to bird, you can also configure it to just use the /24 ranges in the context of talking to the ebgp peer, and never let them come near the t_bgp or even master table, so you don't need the additional filters to keep them out again.
Borrowing your routing table scheme from your first reply: +--------+ | master | +--------+ ^ | | | p_bgp_to_master | v +--------+ ---> | t_bgp | <--- iBGP +--------+ ^ | | | p_wzyx_to_bgp | v +--------+ ---> | t_wzyx | <--- eBGP to wzyx +--------+ ^ | originate_to_wzyx | bgp routes we want to announce In the eBGP session I have an input filter that rejects routes matching my /24. What happens here is that despite the filter, those routes still end up being added to t_bgp because they were added to t_wzyx via originate_to_wzyx. Is that correct? If so, the solution is see is to change p_wzyx_to_bgp so that instead of 'import where proto = "eBGP"' a more complex filter is used, something like if proto = "eBGP" && ! (net ~ [a.b.0.0/24, a.b.1.0/24]) then { accept; } reject; Looks good?
Why would a route with target 'reject' not be added to the kernel table if you export the route to it?
Please ignore that, it was a brain malfunction. Thank you, Andre