Announce prefix to BGP conditional

[Alexander V. Chernikov]

On 05.01.2013 01:44, Robert Hass wrote:
> On Fri, Jan 4, 2013 at 12:34 AM, Alexander V. Chernikov
> <melifaro at 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
>