Enable aggregation (-A) for Juniper prefix-lists

[sebastianw]

Currently it is not possible to aggregate prefixes when prefix-lists are used:

sebastianw@sol:~ $ bgpq3 -J3Al as-example AS-EXAMPLE
FATAL ERROR:Sorry, aggregation (-A) does not work in Juniper prefix-lists
You can try route-filters (-E) instead of prefix-lists (-P, default)
[Exit 255] 

This would be an useful option to have when prefix-lists are used (as in our case) with prefix-list-filter like this:

[edit policy-options policy-statement bgp-example-filter term default]
set from prefix-list-filter as-example orlonger
set then accept

This will accept the prefixes in the prefix-list or longer prefixes. Using -A in that case would make the prefix-list much smaller.

[snar]

On Thu, Jul 27, 2017 at 01:56:38PM +0000, Sebastian Wiesinger wrote:

Currently it is not possible to aggregate prefixes when prefix-lists are used:

swiesinger@sol:~ $ bgpq3 -J3Al as-example AS-EXAMPLE FATAL ERROR:Sorry, aggregation (-A) does not work in Juniper prefix-lists You can try route-filters (-E) instead of prefix-lists (-P, default) [Exit 255]

It will never be possible using aggregation with Juniper prefix-lists. Reason is simple: aggregation means an attempt to transform initial set of prefixes (simple prefix-list) to an equal set of rules, where: a) all prefixes in initial set are allowed by resulting set of rules b) no prefixes not included in initial set are NOT allowed by resulting set. And, as there are no 'rules' in prefix-lists (each line is an exact match for a single prefix), there is no way to transform prefix-list (unless changing output to route-filters which are more flexible).

This would be an useful option to have when prefix-lists are used (as in our case) with prefix-list-filter like this:

[edit policy-options policy-statement bgp-example-filter term default] set from prefix-list-filter as-example orlonger set then accept

You shall not use such configuration for routing polilcies, as it will allow unregistered routes enter DFZ (any more-specific is permitted here) :( Worse yet, imagine your peer registers 0.0.0.0/0 for his AS making this term being equivalent to 'permit any'.

This will accept the prefixes in the prefix-list or longer prefixes. Using -A in that case would make the prefix-list much smaller.

'permit any' or no prefix-list filtering at all is indeed smaller than most prefix-filters :)

[sebastianw]

Hmm I see what you mean. It might be a bit different in my case, for example we have a customer that has route-objects for his IP-Space which entails one /20 for all his space and some /24s for more specific allocations. Our route-filter (for most customers) says: allow the /20 and longer prefixes. We filter everything </24 beforehand. So the customer can announce everything in his space as long as it is >=/24. Then we only want the "umbrella" /20. But I can see why this might be difficult/misunderstood for automatic filter generation.

As for registering 0.0.0.0/0, isn't that a general problem of RADB as there are not really checks to see if someone is allowed to register address space? We don't have that problem with RIPE NCC address space as the database checks who is allowed to register route objects.

All in all feel free to close this, I can live with the way it is now.

[andersonlich]

this could be solve, if bgpq3 support for ouput route-filter-list.

route-filter-list test { 100.64.0.0/10 upto /24; }

[snar]

On Thu, Sep 07, 2017 at 01:31:41AM +0000, andersonlich wrote:

this could be solve, if bgpq3 support for ouput route-filter-list.

• route-filter-list test { • 100.64.0.0/10 upto /24; • }

Support for route-filter-lists (new flag -z) implemented and pushed to github. Thanks, missed this brand new (JunOS 16.2) feature.