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
signature.asc
Description: Digital signature
