RPKI Configuration With Junos OS

Step 1: Set Up Your Junos OS Configuration

a) Set up communication with the RPKI Validator service

The first step for using origin validation data within your Juniper router is to set up communication with the RPKI Validator toolset. In this example, it is running at IP 10.1.1.6 and the router identifies itself as 10.1.1.5.

b) Assign a local-preference to the RPKI validity attribute of the prefix

The next step is to define your routing policy based upon the validation state. We will follow the advice in the IETF standards by preferring valid over unknown, and valid and unknown over invalid. In this example, we'll set the localpref as the determinator for the routing policy. It's up to you as an operator to decide if and how you want to use this information.

Note: There is an additional state in Junos OS called “unverified”, which indicates prefixes that haven't been policed. This means there may be a BGP neighbour session that doesn't have an import policy route-validation applied. You can verify this with the following command:

b) Assign a local-preference to the RPKI validity attribute of the prefix

The next step is to define your routing policy based upon the validation state. We will follow the advice in the IETF standards by preferring valid over unknown, and valid and unknown over invalid. In this example, we'll set the localpref as what determines the routing policy. It's up to you as an operator to decide if and how you want to use this information.

Use of the Validation State in BGP Best Path Determination

There are two ways you can modify the default BGP best path selection process when using RPKI validation states:

You can completely disable the validation of prefixes on the router. This is done by configuring the bgp bestpath prefix-validate disable command. You might want to do this for configuration testing. The router will still connect to the RPKI Validator and download the validation information but will not use the information.

You can allow an invalid prefix to be used as the BGP best path, even if valid prefixes are available. This is the default behaviour. The command to allow a BGP best path to be an invalid prefix, as determined by the BGP Origin AS Validation feature, is the bgp bestpath prefix-validate allow-invalid command. The prefix validation state will still be assigned to paths and will still be communicated to iBGP neighbours that have been configured to receive RPKI state information. You can use a route map to set a local preference, metric or other property based on the validation state.

During BGP best path selection, the default behaviour, if neither of the above options is configured, is that the system will prefer prefixes in the following order:

Those with a validation state of valid.

Those with a validation state of not found.

Those with a validation state of invalid (which, by default, will not be installed in the routing table).

These preferences override metric, local preference and other choices made during the bestpath computation. The standard bestpath decision tree applies only if the validation state of the two paths is the same.

If both commands are configured, the bgp bestpath prefix-validate disable command will prevent the validation state from being assigned to paths, so the bgp bestpath prefix-validate allow-invalid command will have no effect.

These configurations can be in either router configuration mode or in address family configuration mode for the IPv4 unicast or IPv6 unicast address families.

MD-CLI configuration:

b) Assign a local-preference to the RPKI validity attribute of the prefix

The next step is to define your routing policy based upon the validation state. We will follow the advice in the IETF standards by preferring valid over unknown, and valid and unknown over invalid. In this example, we'll set the local preference as the determinator for the routing policy. It's up to you as an operator to decide if and how you want to use this information.

c) Configure origin validation and the BGP neighbours

The last steps are to enable origin validation and to apply the import policy to the BGP neighbours: in this case, the group named “EBGP_PEERING”. Origin validation can also be configured directly under a neighbor.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.