Router Configuration

RPKI Configuration with JunOS
RPKI Configuration with Cisco IOS



RPKI Configuration With JunOS

Juniper provides official support for RPKI since release 12.2.
Juniper has detailed documentation available on configuring Origin Validation for BGP.

Step 1: Set Up Your JunOS 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.

routing-options {
autonomous-system 64511;
validation {

group rpki-validator {
session 10.1.1.6 {
refresh-time 120;
hold-time 180;
port 8282;
local-address 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.

policy-options { 
policy-statement validation {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
next policy;
}
}
term invalid {
from {
protocol bgp;
validation-database invalid;
}
then {
validation-state invalid;
community add origin-validation-state-invalid;
next policy;
}
}
term unknown {
from protocol bgp;
then {
validation-state unknown;
community add origin-validation-state-unknown;
next policy;
}
}
}
}

c) Configure the BGP neighbours and policies

The last step is to apply the import policy to the BGP neighbours: in this case, a single router at 10.1.1.2.

protocols {
bgp {
group mypeers {
import route-validation;
peer-as 200;
neighbor 10.1.1.2;
}
}
}

Step 2: Verify the connection to the RPKI Validator service

Now that everything is configured, test if the connection to the RPKI Validator service is working properly.

junos.rpki.example.net> show validation session detail       
Session 10.1.1.6, State: up, Session index: 2
Group: rpki-validator, Preference: 100
Local IPv4 address: 10.1.1.5, Port: 8282
Refresh time: 120s
Hold time: 180s
Record Life time: 3600s
Serial (Full Update): 441
Serial (Incremental Update): 441
Session flaps: 989
Session uptime: 00:10:08
Last PDU received: 00:00:08
IPv4 prefix count: 1183
IPv6 prefix count: 305
junos.rpki.example.net> show validation statistics
Total RV records: 1487
Total Replication RV records: 2946
Prefix entries: 1382
Origin-AS entries: 1487
Memory utilization: 440802 bytes
Policy origin-validation requests: 13065187
Valid: 35605
Invalid: 37896
Unknown: 12991686
BGP import policy reevaluation notifications: 27306
inet.0, 27306
inet6.0, 0
junos.rpki.example.net> show validation database
RV database for instance master

Prefix Origin-AS Session State Mismatch
24.232.0.0/16-32 10318 10.1.1.6 valid
31.3.8.0/21-21 5524 10.1.1.6 valid
31.7.8.0/21-21 8676 10.1.1.6 valid

2a03:b600::/32-32 41659 10.1.1.6 valid
2a03:cd80::/32-32 16354 10.1.1.6 valid
2a03:fa00::/32-32 28760 10.1.1.6 valid

IPv4 records: 1164
IPv6 records: 302

Step 3: Verify if your policy is applied correctly

Lastly, verify if your routing policy is correctly applied to your routes.

junos.rpki.example.net> show route protocol bgp validation-state valid

inet.0: 376619 destinations, 376620 routes (376617 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

24.232.0.0/16 *[BGP/170] 6d 08:43:35, localpref 110, from 10.1.1.2
AS path: 33926 3356 12956 12956 22927 10481 10318 I, validation-state: valid
> to 193.34.50.1 via em0.0
24.232.0.0/19 *[BGP/170] 6d 08:43:35, localpref 110, from 10.1.1.2
AS path: 33926 3356 12956 12956 22927 10481 10318 I, validation-state: valid
> to 193.34.50.1 via em0.0
junos.rpki.example.net> show route protocol bgp validation-state invalid

inet.0: 376613 destinations, 376614 routes (376611 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

31.24.224.0/21 *[BGP/170] 04:44:02, localpref 90, from 10.1.1.2
AS path: 33926 9009 13213 197820 I, validation-state: invalid
> to 193.34.50.1 via em0.0
31.25.151.0/24 *[BGP/170] 1w3d 19:30:36, localpref 90, from 10.1.1.2
AS path: 33926 3356 43646 48299 I, validation-state: invalid
> to 193.34.50.1 via em0.0
junos.rpki.example.net> show route protocol bgp validation-state unknown  

inet.0: 376618 destinations, 376619 routes (376616 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.25.0/24 *[BGP/170] 1w3d 19:31:04, localpref 100, from 10.1.1.2
AS path: 33926 3356 2516 2519 I, validation-state: unknown
> to 193.34.50.1 via em0.0
1.0.26.0/23 *[BGP/170] 1w3d 19:31:04, localpref 100, from 10.1.1.2
AS path: 33926 3356 2516 2519 I, validation-state: unknown
> to 193.34.50.1 via em0.0

 

Note: There is an additional state in JunOS 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:

junos.rpki.example.net> show route protocol bgp validation-state unverified

Try it Yourself in the Public Test Bed

There are public test beds available with RPKI-capable Juniper routers, which are connected to the RIPE NCC RPKI Validator. When you create a ROA in the RIPE NCC Resource Certification service, you can check the effects on your BGP announcements yourself.

Kaia Global Networks

Public RIPE NCC RPKI Validator
Juniper Routers: 193.34.50.25, 193.34.50.26
telnet username: rpki
password: testbed

Documentation

RPKI Configuration with Cisco IOS

RPKI is officially supported on the following Cisco platforms

High-end & mid-range routers running IOS-XR

Minimum release XR 4.2.1:

    • CRS-1, CRS-3, CRS-x
    • ASR9000
    • c12000

As of XR 5.1.1:

    • NCS6000 (optical router)
    • XRv (virtual router on x86)

 

Access/Enterprise routers running IOS-XE

Minimum release XE 3.5:

    • c7200, c7600, ASR1000
    • CSR1000v (Virtual Router on x86)
    • ASR901, ASR903, ASR907
    • ME3600, ME3800

ASR1000 & CSR1000v also support BGP route-server functions with RPKI


Cisco has detailed information available on the "match rpki" command in the BGP Command Reference and a BGP—Origin AS Validation document.

Step 1: Set up your IOS configuration

a) Set up communication with the RPKI Validator service

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

cisco-rpki-rtr#show running-config | begin bgp

router bgp 64500
bgp log-neighbor-changes
bgp rpki server tcp 10.1.1.6 port 8282 refresh 600

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.

!
route-map rpki-loc-pref permit 10
match rpki invalid
set local-preference 90
!
route-map rpki-loc-pref permit 20
match rpki not-found
set local-preference 100
!
route-map rpki-loc-pref permit 30
match rpki valid
set local-preference 110

c) Configure the BGP neighbours and policies

The last step is to apply the import policy to the BGP neighbours: in this case, a single router at 10.1.1.2.

cisco-rpki-rtr#show running-config | begin bgp

router bgp 64500
bgp log-neighbor-changes
bgp rpki server tcp 10.1.1.6 port 8282 refresh 5
network 192.0.2.0
neighbor 10.1.1.2 remote-as 64510
neighbor 10.1.1.2 route-map rpki-loc-pref in
!

Step 2: Verify the connection to the RPKI Validator service

Now that everything is configured, test if the connection to the RPKI Validator service is working properly.

cisco-rpki-rtr>show ip bgp rpki server
BGP SOVC neighbor is 10.1.1.6/8282 connected to port 8282
Flags 64, Refresh time is 300, Serial number is 4, Nonce is 9169
InQ has 0 messages, OutQ has 0 messages, formatted msg 4
Session IO flags 3, Session flags 4008
Neighbor Statistics:
Prefixes 1391
Connection attempts: 32
Connection failures: 0
Errors sent: 0
Errors received: 0
cisco-rpki-rtr>show ip bgp rpki table
1030 BGP sovc network entries using 90640 bytes of memory
1113 BGP sovc record entries using 22260 bytes of memory

Network Maxlen Origin-AS Source Neighbor
24.232.0.0/16 32 10318 0 10.1.1.6/8282
31.3.8.0/21 21 5524 0 10.1.1.6/8282
31.7.8.0/21 21 8676 0 10.1.1.6/8282

217.198.192.0/20 20 197077 0 10.1.1.6/8282
217.199.224.0/20 24 25299 0 10.1.1.6/8282
217.224.0.0/11 11 3320 0 10.1.1.6/8282

Step 3: Verify that your policy is applied correctly

Lastly, verify that your routing policy is correctly applied to your routes.

cisco-rpki-rtr>sh ip bgp 93.175.146.0/24
BGP routing table entry for 93.175.146.0/24, version 8995350
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
64510 3333 12654, (received & used)
10.1.1.5 from 10.1.1.2 (10.1.1.2)
Origin IGP, localpref 110, valid, external, best
path 51012284 RPKI State valid
cisco-rpki-rtr>sh ip bgp 93.175.147.0/24
BGP routing table entry for 93.175.147.0/24, version 8995351
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
64510 3333 12654, (received & used)
10.1.1.5 from 10.1.1.2 (10.1.1.2)
Origin IGP, localpref 90, valid, external
path 510122C8 RPKI State invalid
cisco-rpki-rtr>sh ip bgp 84.205.83.0/24
BGP routing table entry for 84.205.83.0/24, version 5427340
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
64510 3333 12654, (received & used)
10.1.1.5 from 10.1.1.2 (10.1.1.2)
Origin IGP, localpref 100, valid, external, best
path 2609454C RPKI State not found

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.

Try it Yourself in the Public Test Bed

The RIPE NCC offers a public test bed with an RPKI-capable Cisco router, which is connected to the RIPE NCC RPKI Validator. When you create a ROA in the RIPE NCC Resource Certification service, you can check the effects on your BGP announcements yourself.

 

Public RIPE NCC RPKI Validator
Cisco router: rpki-rtr.ripe.net
telnet username: ripe
no password