[Euro-ix-rs-vwg] New release 1.2.0

[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.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20100127/1c64f2e0/attachment-0001.asc>