You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 9, 2024. It is now read-only.
Comparing the output from octorpki and routinator there is a difference in the number of valid entries that both tools create. Looking closer, It appears that anything with a prefix larger than /24 (25-32 for v4) is missing from the output octorpki output.
Nlnetalbs snippet... just a couple of examples to look at.
Octorpki has matches for the larger blocks from the same AS
prefix: 66.112.128.0/20
prefix: 188.93.240.0/21
We have customers who want to create more specific entries for policy routing on our AS (where more specifics are allowed) or use DDoS services etc. These more specific blocks are not getting marked as valid in the current code. Is there a configuration option or something similar to permit these more specific routes? We are using versions v1.5.10.
The text was updated successfully, but these errors were encountered:
I think that the filter flag should change this behaviour. In contrast to the documentation, this just filters by prefix length:
Filter=flag.Bool("filter", true, "Filter out non accessible prefixes and duplicates")
...ifs.Filter {
roalist.Data=FilterInvalidPrefixLen(FilterDuplicates(roalist.Data))
}
roalist.Data=filterDuplicates(roalist.Data)
Comparing the output from octorpki and routinator there is a difference in the number of valid entries that both tools create. Looking closer, It appears that anything with a prefix larger than /24 (25-32 for v4) is missing from the output octorpki output.
Nlnetalbs snippet... just a couple of examples to look at.
Octorpki has matches for the larger blocks from the same AS
We have customers who want to create more specific entries for policy routing on our AS (where more specifics are allowed) or use DDoS services etc. These more specific blocks are not getting marked as valid in the current code. Is there a configuration option or something similar to permit these more specific routes? We are using versions v1.5.10.
The text was updated successfully, but these errors were encountered: