BGP Prefix Validation Using RPKI-RTR Configuration
Configuration Hierarchy
The diagram illustrates the BGP prefix validation mechanism configuration hierarchy.
Configuration Syntax and Commands
The following sections describe the BGP RPKI prefix validation configuration syntax and commands.
Configure Validation Session with RPKI Local Cache
The following configuration commands are used to define validation session on an RBFS device. It specifies different session parameters such as cache IP address, update source, port, and preference.
In scenarios where multiple caches are available, the system employs a deterministic method for selecting the preferred cache. The cache preference method provides a way to determine which cache should be used based on configurable priorities.
Cache Preference:
-
When a preference is configured, the cache with the numerically lower preference value is selected.
-
If no preference is configured, or two caches have the same preference value, the selection follows these rules:
-
Among IPv4 caches, the cache with the higher IP address is preferred.
-
Among IPv6 caches, the cache with the higher IP address is preferred.
-
Between IPv4 and IPv6 caches, the IPv4 cache takes precedence over IPv6.
-
Syntax
set instance <instance-name> protocol validation session [IPv4|IPv6] <cache-address> <update-source>
| Attribute | Description |
|---|---|
cache-address |
Cache server IP address. |
update-source |
Source IP address. |
port |
Port number used fof the RPKI local cache. Range 1 - 65535 |
preference |
Enables RBFS to select the validated route record from the preferred cache. Range 1 - 255. A numerically lower preference value indicates the higher preference. |
Example: Validation session with the RPKI local cache
supervisor@rtbrick.net: cfg> show config instance vrf-blue protocol validation
{
"rtbrick-config:validation": {
"session": {
"ipv4": [
{
"cache-address": "192.168.5.50",
"update-source": "192.168.5.20",
"port": 3323,
"preference": 100
}
],
"ipv6": [
{
"cache-address": "192:168:5::50",
"update-source": "192:168:5::20",
"port": 3323,
"preference": 10
}
]
}
}
}
The preceding configuration sets up RPKI validation for both IPv4 and IPv6 routes in BGP. IPv4 session connects the router to an RPKI cache server with the RTR protocol, using the specified cache server IP address 192.168.5.50. The update-source, that is source IP address, is specified to 192.168.5.20 for the IPv4 session. The port number that is used for RTR communication is specified to '3323' for the session.
For the IPv6 session, the cache server IP address is specified to 192:168:5::50 and the source IP is specified 192:168:5::20. The port number is specified 3323 that is used for RTR communication.
The preference value for the IPv4 session is set to 100, while the preference value for the IPv6 session is set to 10. The preference value determines which session is prioritized when both sessions are available. A lower numerical preference value indicates a higher preference. In this scenario, the IPv6 session has a higher preference because it has a lower value, meaning that the IPv6 session will take priority over the IPv4 session.
Configure BGP Validation Instance
Syntax
set instance <instance-name> protocol bgp validation-instance <validation-instance>
| Attribute | Description |
|---|---|
<validation-instance> |
Validation instance name. |
Example: Validation Instance configuration
supervisor@rtbrick.net: cfg> show config instance default protocol bgp validation-instance
{
"rtbrick-config:validation-instance": "vrf-blue"
}
The configuration sets up 'vrf-blue' as the validation instance.
Configure BGP Validation Filter
Validation filter can be configured under a specific BGP peer group.
Syntax
set instance <instance-name> protocol bgp peer-group <pg-name> validation-filter [strict|loose|disable]
| Attribute | Description |
|---|---|
strict |
BGP accepts only the valid routes. |
loose |
BGP accepts both valid routes and unknown routes. But it rejects routes with invalid RPKI data. |
disable |
No route validation is performed. Routes are installed based on the BGP route selection process. |
Example: Validation filter configuration
supervisor@rtbrick.net: cfg> show config instance default protocol bgp peer-group P2 validation-filter
{
"rtbrick-config:validation-filter": "loose"
}
The configuration defines the validation filter. The validation filter is defined as 'loose' for the configuration that means BGP can accept both valid routes and unknown routes, but it rejects routes with invalid RPKI data.