Accept a specific prefix from a peer if no route object exists (white_list_prefix)

[job]

job: is there a way to accept a specific prefix from one peer if no route object exists? job: like when we know the announcement is correct, but they can't figure out how to make a route object ... pierky: I can introduce a client-level "white_list_prefix" pierky: it should have highest priority pierky: if a prefix is in white_list_pref other checks will be skipped

[pierky]

I've added a couple of client-level settings, white_list_pref and white_list_asn, under the irrdb section:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-ONEONE"
          white_list_pref:
            - prefix: "203.0.113.0"
              length: 24
              le: 32
          white_list_asn:
            - 65534

Prefixes and ASNs that are added to these white lists are treated as if they are part of the client's AS-SET.

Do you think this could solve your problem? Would it be better to implement a sort of white_list_route built by touples of (prefix, ASN) that could be used with a priority higher than IRRdb info?

[job]

Yeah i think tuples is maybe easier :)

[job]

syntax proposal:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-ONEONE"
          white_list_prefixes:
            - "203.0.113.0/24AS65534"

[pierky]

So, I also added a third white list, the one that pheraps is better and easier to solve this kind of problems: white_list_route:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-AS11NETS"
          white_list_route:
            - prefix: "203.0.113.0"
              length: 24
              asn: 65534

The syntax is the same already used for other prefix-list entries, with the addition of an optional asn attribute, used to match the origin ASN.

From clients.yml:

The first one, 'white_list_route', allows routes to "escape" IRRdb-based filters and to be always accepted. Entries of this list are made up by prefixes and an optional ASN which, if present, is matched against the origin ASN. In this case, routes that pass the IRRdb filters are tagged with 'prefix_not_present_in_as_set' and 'origin_not_present_in_as_set' accordingly to the configured policy.

The last two, 'white_list_pref' and 'white_list_asn' are more "tricky". They allow to treat prefixes and ASNs as if they were part of the client's AS-SET. This implies that filters and features based on IRRdb data are also applied as if routes were validated against those data. For example, if tagging via BGP community was enabled, when a route is accepted because of one or both of these white lists then the appropriate 'prefix_present_in_as_set' or 'origin_present_in_as_set' communities are also added.

In any case, these white lists only apply to IRRdb-based filters; other filters (NEXT_HOP, prefix length, max AS_PATH length, transit-free/invalid ASN in AS_PATH and so on) are applied accordingly to the rest of the configuration.

Prefixes are always intended as being inclusive of more specifics unless the 'exact' attribute is set to True. The range of included sub-prefixes can be set using 'ge' and 'le' attributes; if they are missing, length-[32|128] is used.

@job: any feedback?

[job]

looks good to me