Route object preference

IRRd supports a route object preference, where route(6) objects can be suppressed if they overlap with other route(6) objects from sources with a higher route object preference.

Note

This document only contains details specific to the filter, and is meant to complement the object suppression overview.

Configuring route object preference

You can enable route object preference by setting sources.{name}.route_object_preference on at least one source. This is a number, where higher numbers have higher preference. See the configuration documentation for the exact syntax.

You can exclude sources by not setting sources.{name}.route_object_preference. Objects from these sources are always seen as visible.

To disable this feature, set route_object_preference for all sources to the same preference to reset the state of all objects to visible. Once the periodic import has updated this, unset sources.{name}.route_object_preference for all sources to disable the update process.

Validation

  • In route object preference, each route(6) object is assigned a preference from its source’s sources.{name}.route_object_preference setting.

  • For the objects with a preference: if there is an overlapping route(6) object with a higher preference, the lower preference object is suppressed.

  • Overlap means that the prefixes of the objects are an exact match, more specific, or less specific.

  • If two overlapping objects have the same preference, both are visible (assuming there are no further overlaps).

  • Origin ASes are not considered.

  • Objects from sources without a preference setting are always visible and otherwise completely ignored in the validation process. They are also not included when considering suppression of other objects.

For example, let’s say the preferences are: TEST-H1 and TEST-H2 at priority 900, TEST-M at 200, TEST-L at 100, TEST-N with no preference, and the following objects exist:

  • A: TEST-H1 192.0.0.0/23 AS65530

  • B: TEST-H2 192.0.0.0/24 AS65530

  • C: TEST-L 192.0.0.0/23 AS65530

  • D: TEST-M 192.0.0.0/22 AS65530

  • E: TEST-M 192.0.1.0/24 AS65530

  • F: TEST-L 192.0.3.0/24 AS65530

  • G: TEST-N 192.0.0.0/22 AS65530

In this case objects C, D, E and F will be suppressed. C, D and E all overlap directly with A and/or B, and A and B have a higher preference than all others. A and B have an identical preference so their objects will both be visible. Object F overlaps with object D, and object D has a higher preference, therefore object F is also suppressed. Object G remains visible and is otherwise ignored, as it has no preference set, so it has no impact on the visibility of other objects.

Log messages and journal order

RPKI and scope filter status are determined per object, shortly after parsing. Route preference status is rather difference: it is determined for all affected prefixes just before committing. This has some practical consequences that may lead to initially confusing log messages or journal entries.

In RPKI and scope filter, the status of an object can be determined by evaluating only that object, and the IRRd configuration and/or ROA table. However, for route preference, an object’s status depends on which other objects exist in other sources. Also, uniquely, one object being added or deleted, may cause the state of an entirely different object to change, which was not part of the current change set.

When evaluating the status just before a transaction commit, IRRd will log a line like: route preference updated for a subset of 15 added/removed/changed routes: 2 regular objects made visible, 8 regular objects suppressed, 0 objects from excluded sources made visible. Important to note is that the 15 added/removed/changed routes do not have to be the same objects as the 2 objects made visible, and the 8 made suppressed. Similarly, processing NRTM changes from one source, may lead to journal entries for objects of an entirely different source.