On 04.01.2013 03:17, Robert Hass wrote:

...

Patch is available at http://static.ipfw.ru/patches/0001-Implement-general-aggregation-protocol-v6...

We run this protocol on a large route-reflector for a while without any issues, but YMMV.

Hi

I applied patch in my bird, but it look's it's not working. My configuration bird.conf:

log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; router id 10.0.0.3;

protocol device { scan time 60; }

protocol aggregator AG1 { import all; bgp id 10.0.0.2 as 100 { aggregate address 1.1.1.2/32; aggregate address 1.1.1.1/32 mandatory list { 10.44.0.0/24 }; }; } You still have to announce at least one route within aggregate-address block (so /32 setup won't work, at least /31 prefix).

E.g. configuration should look like aggregate address 1.1.1.1/30 mandatory list { 10.44.0.0/24 }; and you are required to have 1.1.1.1/32 AND 10.44.0.0/24 to be in your route table to make aggregation protocol announce given route. This is probably not obvious from examples/docs :(

protocol bgp CISCO { local as 300; source address 10.0.0.3; neighbor 10.0.0.4 as 400; import filter bgp_cust_in; export filter { if (net ~ [1.1.1.1/32] ) then { accept; } if (net ~ [1.1.1.2/32]) then { accept; } }; }

bird> show route 10.44.0.0/24 via 10.0.0.4 on em1 [CISCO 00:04] * (100) [AS400i] bird>

Any comments ?

Rob

On 05.01.2013 01:44, Robert Hass wrote:
> On Fri, Jan 4, 2013 at 12:34 AM, Alexander V. Chernikov
> <melifaro@ipfw.ru>  wrote:
>>>           bgp id 10.0.0.2 as 100 {
>
> I have question for what above IP (bgp id) and AS (bgp as) is needed ?
You can potentially aggregate routes from
1) bgp instances with different rId/Asns (since bird is different from 
C/J design here, no real "common" configuration part)
2) non-bgp routes

One of previous protocol versions had some auto-detect logic (e.g. saves 
id/as of "first" matching bgp route) but it was removed due to potential 
non-deterministic behavior.

>
>>>                   aggregate address 1.1.1.2/32;
>>>                   aggregate address 1.1.1.1/32 mandatory list {
>> You still have to announce at least one route within aggregate-address block
>> (so /32 setup won't work, at least /31 prefix).
>
> OK, very good remark.
>
>> E.g. configuration should look like
>>
>> aggregate address 1.1.1.1/30 mandatory list { 10.44.0.0/24 };
>>
>> and you are required to have
>> 1.1.1.1/32 AND 10.44.0.0/24 to be in your route table to make aggregation
>> protocol announce given route.
>
> Can I have 1.1.1.1/32 as static route, i.e.:
>
> protocol static {
>          route 1.1.1.1/32 reject;
> }
>
> or it have to be learned via BGP ? If it have be in BGP is bird checks
> it's origin as or something more ?
Any route, no checking. It is up to user to filter specific ones via 
outbound filter. (btw, you probably want to generate 0/0 based on some 
subset of full-view)
>
> PS. Yeah, doc's a little sucks for this patch and they're no so
> obvious. Even docs says that config should like:
>
> protocol agg {
>
> and  proper syntax is different e.g. (protocol agg wasn't work for me)
>
> protocol aggregator xxx {
Yup. Understood, I'll change this.
>
> Rob
>