Ondrej Zajicek пишет:
On Mon, Jan 25, 2010 at 07:12:50PM +0300, Mikhail A. Grishin wrote:
Ondrej Zajicek ?????:
On Mon, Jan 25, 2010 at 03:15:14PM +0300, Mikhail A. Grishin wrote:
Yes, we had some filters on pipes for every client. Upon your explanation, we transfered filters from pipes to the "protocol bgp" section of the config.
Now "show protocols all" output shows all needed information. Just a note that moving filters from pipes to bgp protocols have several other consequences, some positive, some negative:
1) You see just what is accepted and you cannot directly see rejected routes (but they can be seen in log, if enabled). Yes, we planned for that case temporary transfer filters back to pipes for some peer... But if it could be done by logs, may be you can show an example?
You can use 'debug { filters }' in a bgp protocol section and it will log all routes in filters of that bgp protocol.
Very valuable info for us! In general, we want to minimize causes of restarting BGP sessions with our clients. Is this task (new behavior of 'configure' command) have a good priority for developers?
Other IXes that use BIRD use (AFAIK) 'configure soft' and 'reload' approach, so it was not a big demand for this change yet. But it should not be hard to do that change and i would like to have this change soon.
One more question, about routes with "no-export" community == ((65535,65281))
We need to transparently advertise such routes through RS to RS clients.
We try to transparently advertise, these routes seen in 'show routes all', and in 'show routes all table Tanother_peer', but peer 'another_peer' doesn't receive routes with community (65535,65281).
Handling of no-export community is hardcoded in BIRD, so such routes are not exported to the external neighbors, as it is expected. I can send you a patch that causes BIRD to ignore well-known communities (and leaves such behavior to configured filters) and we will make this behavior configurable in the next version.
Yes, it would be nice, please send me a patch. We expected that we could choose, which well-known communities must go through RS, which is not. Right now we only interested in transparency for "no-export". -- Mikhail A. Grishin E-mail: magr@ripn.net