Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tag white_list_pref with informational community #18

Closed
job opened this issue Oct 26, 2017 · 2 comments
Closed

tag white_list_pref with informational community #18

job opened this issue Oct 26, 2017 · 2 comments

Comments

@job
Copy link
Contributor

job commented Oct 26, 2017

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.

pierky added a commit that referenced this issue Oct 27, 2017
... and how they interact with tag_as_set and
[prefix|origin]_not_present_in_as_set communities.

closes #18
@pierky
Copy link
Owner

pierky commented Oct 27, 2017

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.

@pierky pierky closed this as completed Oct 27, 2017
@pierky
Copy link
Owner

pierky commented Oct 30, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants