This lab investigates configuring RPKI support on the lab routers, to talk to the newly installed validator cache.
The diagram below is a reminder of the lab topology:
With the validator cache now operational on the SRV appliance in each group, we can now configure the routers to get the cached ROA (VRPs) from the cache.
Most network operators will simply configure the RPKI settings on their border routers1, the routers which connect to other Autonomous Systems. Most operators will make validation decisions right there and then, although some will choose to propagate the validation information across their network so that all routers can partake, if required.
We will set up the Peering Router, Border Router and Access Router to talk to the validator cache you set up in the previous lab. There is no need for the Core router to talk to the cache, as prefixes arriving on the Core should already have been validated by the others.
Cisco IOS has a one line configuration to do this:
router bgp X0
bgp rpki server tcp 100.68.X.30 port 3323 refresh 3600And that is it. This tells the router to connect by TCP to 100.68.X.30 (the SRV appliance) on port 3323, refreshing the cache every 3600 seconds (60 minutes), the recommendation made in RFC8210.
The instructors are also running a validator cache on rpki.ws.nsrc.org - its IP address is 10.10.0.241. Set this up as well, using the same command format as above.
We can now see if the router is talking to the cache, and the information it is receiving. For example, on the Border router:
bX# show ip bgp rpki ?
servers Display RPKI cache server information
table Display RPKI table entriesThe servers option will list the servers configured, and their status, and should look like this, an example taking from the Border Router in Group 1 in an earlier version of this workshop:
B1#show ip bgp rpki servers
BGP SOVC neighbor is 10.10.0.241/3323 connected to port 3323
Flags 64, Refresh time is 3600, Serial number is 0, Session ID is 50120
InQ has 0 messages, OutQ has 0 messages, formatted msg 1
Session IO flags 3, Session flags 4008
Neighbor Statistics:
Prefixes 99307
Connection attempts: 6
Connection failures: 5
Errors sent: 0
Errors received: 0
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 100.121.1.1, Local port: 34457
Foreign host: 10.10.0.241, Foreign port: 3323
Connection tableid (VRF): 0
...
BGP SOVC neighbor is 100.68.1.30/3323 connected to port 3323
Flags 64, Refresh time is 3600, Serial number is 0, Session ID is 50400
InQ has 0 messages, OutQ has 0 messages, formatted msg 1
Session IO flags 3, Session flags 4008
Neighbor Statistics:
Prefixes 99227
Connection attempts: 1
Connection failures: 0
Errors sent: 0
Errors received: 0
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 100.68.1.17, Local port: 13449
Foreign host: 100.68.1.30, Foreign port: 3323
Connection tableid (VRF): 0There is the IPv6 equivalent command, which looks like this:
bX# show bgp ipv6 unicast rpki serversIf you see that the connection to the validation server isn’t working, then you might have to restart the RPKI system on the router. To do this, the command is:
clear ip bgp rpki server 100.68.X.30 port 3323which will restart the connection. Note that the connection will often fail until the validator is up and running, and this can take a bit longer inside the virtual environment being used.
If you find that the connection still won’t restart (and this is due purely to the lab environment), deleting and re-entering the BGP RPKI configuration on the router is the only way forwards. It could well be that this is a Cisco bug, or a problem with the underlying infrastructure, as it hasn’t happened to the workshop author in day to day Internet operations.
The other command option available is the table option, which will display the current RPKI table. To get the IPv4 table, enter the command:
bX# show ip bgp rpki tableand you will see output looking like this:
B1#sh ip bgp rpki table
79297 BGP sovc network entries using 6978136 bytes of memory
84301 BGP sovc record entries using 1686020 bytes of memory
Network Maxlen Origin-AS Source Neighbor
1.0.0.0/24 24 13335 0 100.68.1.30/3323
1.0.0.0/24 24 13335 0 10.10.0.241/3323
1.1.1.0/24 24 13335 0 100.68.1.30/3323
1.1.1.0/24 24 13335 0 10.10.0.241/3323
1.9.0.0/16 24 4788 0 100.68.1.30/3323
1.9.0.0/16 24 4788 0 10.10.0.241/3323
...Note the double entry for each prefix - one entry from your Group's routinator, the other entry from the validator cache running on the instructor system.
To get the IPv6 table, enter the command:
bX# show bgp ipv6 unicast rpki tableand you will see output looking like this:
B1#sh bgp ipv6 uni rpki table
13861 BGP sovc network entries using 1552432 bytes of memory
15034 BGP sovc record entries using 300680 bytes of memory
Network Maxlen Origin-AS Source Neighbor
2001:200::/32 32 2500 0 100.68.1.30/3323
2001:200::/32 32 2500 0 10.10.0.241/3323
2001:200:136::/48 48 9367 0 100.68.1.30/3323
2001:200:136::/48 48 9367 0 10.10.0.241/3323
2001:200:900::/40 40 7660 0 100.68.1.30/3323
2001:200:900::/40 40 7660 0 10.10.0.241/3323
...Also, go back on to the SRV appliance, and check the connections using the netstat command. You should see something like this, taken from Group 5’s appliance in an earlier version of this workshop:
srv$ netstat -a | grep 3323
tcp 0 0 srv1.group5.ws.nsr:3323 *:* LISTEN
tcp 0 0 localhost:3323 *:* LISTEN
tcp 0 0 srv1.group5.ws.nsr:3323 100.68.5.17:57741 ESTABLISHED
tcp 0 0 srv1.group5.ws.nsr:3323 100.68.5.19:62131 ESTABLISHED
tcp6 0 0 srv1.group5.ws.nsr:3323 [::]:* LISTEN
tcp6 0 0 ip6-localhost:3323 [::]:* LISTENTo conclude the lab, explore the RPKI table as stored on the router. See if you can find your own organisation’s prefixes listed in there. If not, what do you think the issue is?
This lab has shown how to configure a router to connect to and troubleshoot the connectivity to the validation caches set up for the workshop network.
Basically all routers with EBGP sessions configured on them.↩