Closed job closed 7 years ago
I think I didn't explain properly how white lists work, I apologize for that.
white_list_pref
and white_list_asn
are thought to add prefixes/ASN to the result of the IRR-data gathering process, so prefixes/ASNs listed there are treated exactly as those that are actually listed in IRR records.
The other white list, white_list_route
, is the one I suggest to use to "manually" accept routes from peers. When a route should be rejected because it doesn't pass IRR-filters but it is actually accepted solely because it matches a white_list_route
entry, if the general filtering.irrdb.tag_as_set
option is set it is tagged with the prefix_not_present_in_as_set
and origin_not_present_in_as_set
.
So, if the route server is set with enforce_[origin|prefix]_in_as_set
and a route with a [origin|prefix]_not_present_in_as_set
community is seen it means that said route is accepted solely because of white_list_route
.
Hopefully with the herein referenced commit I should have made it clearer in the docs and within the configuration files comments.
With the addition of use_rpki_roas_as_route_objects
there are now two reasons for which a route can be accepted even if not authorised by AS-SETs, so I'm going to add a new community to mark those accepted solely because of a white list entry: route_validated_via_white_list
.
It would be good to tag announcements that were accepted solely becaues of
white_list_pref
with a special community, so we can easily find those announcements and see where we need to help our participants.Ideally the special tag is not present on
white_list_pref
announcements if they were accepted because a valid IRR object came into existence.