Issue with filter generation with aggregate

[anuragbhatia]

bgpq3 -Jl test AS54456 -A -E
policy-options {
 policy-statement test {
replace:
  from {
    route-filter 199.116.76.0/22 prefix-length-range /24-/24;
  }
 }
}

Shows wrong prefix length range. Should be /22 - /24. Same if I try to generate Cisco config:

bgpq3 -l test AS54456 -A
no ip prefix-list test
ip prefix-list test permit 199.116.76.0/22 ge 24 le 24

Should have been ge 22 le 24

[snar]

On Tue, Apr 04, 2017 at 01:43:34AM -0700, Anurag Bhatia wrote:

bgpq3 -Jl test AS54456 -A -E policy-options { policy-statement test { replace: from { route-filter 199.116.76.0/22 prefix-length-range /24-/24; } } }

Shows wrong prefix length range. Should be /22 - /24.

No, it shall not. Aggregation means "lets try to represent the set of prefixes in the most compact way", without set modification. i.e.,

• all perfixes from the original set MUST be matched by aggregated set.
• no prefixes that are not in the original set MUST NOT be matched by aggregate.

In this case threre are only four routes can be found in RADB for AS54456:

snar@chumadan:~>bgpq3 -F '%n/%l\n' AS54456 199.116.76.0/24 199.116.77.0/24 199.116.78.0/24 199.116.79.0/24

so bgpq3 creates filter that allows any one of these four, and nothing more.

Same if I try to generate Cisco config:

bgpq3 -l test AS54456 -A no ip prefix-list test ip prefix-list test permit 199.116.76.0/22 ge 24 le 24

Should have been ge 22 le 24

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[mahtin]

This is an interesting situation. The -A flag (or a request to aggregate) could be interpreted in two different ways.

1. There's aggregation in the form of how the originating network decides it wants to aggregate.
2. There's aggregation where it means "I (the operator of the filters) want to aggregate, independent of the originating network, in how I create filters.

Both of you are right. Presently the code and it's -A flag means the first item above. However, there's a case to be made for a second/different flag to implement the second case.

In fact there's even a case when aggregation should always be used; both for router optimization and for terseness of filter output. It took a while to find a good example of this; but I think this ASN could show a valid case (just ignore the /24 for now).

$ bgpq3 -JE -l foo AS201890
policy-options {
 policy-statement foo { 
replace:
  from {
    route-filter 188.123.112.0/22 exact;
    route-filter 188.123.112.0/23 exact;
    route-filter 188.123.113.0/24 exact;
    route-filter 188.123.114.0/23 exact;
  }
 }
}
$

wth the -A aggregate flag you get less output:

$ bgpq3 -JEA -l foo AS201890
policy-options {
 policy-statement foo { 
replace:
  from {
    route-filter 188.123.112.0/22 upto /23;
    route-filter 188.123.113.0/24 exact;
  }
 }
}
$

What I'm trying to show, with this ASN, is that because there's two /23's and one /22 one can always aggregate into one line (the upto /23 part).

Back to the question in hand.

I also believe there's a case (as shown by @anuragbhatia above) where a set of (lets say, his four /24's) could be aggregated by bgpq3 into a single /22 and accept any route within any of the /22 space. This is very much up to the operator of the filters vs. the originator of the routes. The automatic aggregation is very specific to the filter operator.

If this was implemented; I would vote for a different command line flag than the existing -A flag.

BTW: There's a good example of complex filtering based on mask length in the real world. The INEX Internet Exchange in Dublin Ireland has very strict filtering on it's route server. However many other Internet Exchanges are less strict and accept upto /24 automatically. Either way - the request above is more about filter optimization.

[snar]

On Wed, Apr 12, 2017 at 06:55:02PM -0700, Martin J. Levy wrote:

This is an interesting situation. The -A flag (or a request to aggregate) could be interpreted in two different ways.

1. There's aggregation in the form of how the originating network decides it wants to aggregate.
2. There's aggregation where it means "I (the operator of the filters) want to aggregate, independent of the originating network, in how I create filters.

Both of you are right. Presently the code and it's -A flag means the first item above. However, there's a case to be made for a second/different flag to implement the second case.

Actually there are flags to do that, -R and -r . -R intended to "generate" more-specific prefixes up to the specified masklen (use-case: allow more-specifics for registered route-objects):

snar@fri:~>bgpq3 -JEA -l foo -R 25 AS201890 policy-options { policy-statement foo { replace: from { route-filter 188.123.112.0/22 upto /25; } } }

as you see, all /24's and even all /25's are allowed now.

Use-case for -r is less obvious: sometimes you may want to allow only a limited subset of more-specifics, f.e., you may want to accept only /32's:

snar@fri:~>bgpq3 -JEA -l foo -r 32 AS201890 policy-options { policy-statement foo { replace: from { route-filter 188.123.112.0/22 prefix-length-range /32-/32; } } }

Of course you may mix these flags to allow more-specifics in a range you want, f.e., allow all /24../29:

snar@fri:~>bgpq3 -JEA -l foo -r 24 -R 29 AS201890 policy-options { policy-statement foo { replace: from { route-filter 188.123.112.0/22 prefix-length-range /24-/29; } } }

Well, there is a limitation with these flags: while they can generate more-specific prefixes to those registered, they can not (and should not) generate less-specific ones. For example there are no way to "create" /22 based on four /24's as in original question. Reason is simple: these /24's can belong to different originating ASNs and so can not be aggregated into single route.

Real-life example:

snar@fri:~>whois3 -T route -m 194.44.0.0/16 | egrep '^(route|origin):' route: 194.44.0.0/24 origin: AS12809 route: 194.44.1.0/24 origin: AS3255 [...]

do you really think that accepting 194.44.0.0/23 from whatever peer is good idea ?

In fact there's even a case when aggregation should always be used; both for router optimization and for terseness of filter output. It took a while to find a good example of this; but I think this ASN could show a valid case (just ignore the /24 for now).

For a demonstration purposes you can specify networks as bgpq3 arguments:

snar@fri:~>bgpq3 -JEA 127.0.0.0/22 127.0.0.0/23 127.0.2.0/23 127.0.0.0/24 127.0.1.0/24 127.0.2.0/24 127.0.3.0/24 policy-options { policy-statement NN { replace: from { route-filter 127.0.0.0/22 upto /24; } } }

$ bgpq3 -JE -l foo AS201890 policy-options { policy-statement foo { replace: from { route-filter 188.123.112.0/22 exact; route-filter 188.123.112.0/23 exact; route-filter 188.123.113.0/24 exact; route-filter 188.123.114.0/23 exact; } } } $

wth the -A aggregate flag you get less output:

$ bgpq3 -JEA -l foo AS201890 policy-options { policy-statement foo { replace: from { route-filter 188.123.112.0/22 upto /23; route-filter 188.123.113.0/24 exact; } } } $

What I'm trying to show, with this ASN, is that because there's two /23's and one /22 one can always aggregate into one line (the upto /23 part).

Back to the question in hand.

I also believe there's a case (as shown by @anuragbhatia above) where a set of (lets say, his four /24's) could be aggregated by bgpq3 into a single /22 and accept any route within any of the /22 space. This is very much up to the operator of the filters vs. the originator of the routes. The automatic aggregation is very specific to the filter operator.

If this was implemented; I would vote for a different command line flag than the existing -A flag.

BTW: There's a good example of complex filtering based on mask length in the real world. The INEX Internet Exchange in Dublin Ireland has very strict filtering on it's route server. However many other Internet Exchanges are less strict and accept upto /24 automatically. Either way - the request above is more about filter optimization.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.*

[snar]

close for inactivity