Now to configure the router to use the cache. I've shown an example using Cisco IOS. We point the router to the local rpki cache we make the server listen on port 3323 which is one of the common ports used and have the cache refreshed every 60 minutes this means the router will update its local validation table from the cache every 60 minutes this is what's recommended in RFC 8210 but you can make it more frequent if you want or less frequent if that if you prefer an example the screen shows the one-line configuration needed in Cisco IOS and iOS XE to configure the connection to the rpki cache once the routers rpki table is populated the router indicates validation state in the BGP table Cisco IOS does all this automatically for the operator without have various status commands and the screen shows the various status commands that can be used you can display the connection status to the rpki servers you can show the actual V RPS the VRP is a validated raw payload in other words it's the roars that has been downloaded from the cache and show IP BGP shows the BGP table but now includes a status indication next to the prefix you will recall the BGP table from earlier on in this series in their introduction to BGP we now have one extra character column indicating the validation status and if you want to pull these out you can use the search command an iOS command line looking for the V that appears in the BGP table for Juniper the configuration is somewhat different Cisco have tried to make it as easy as possible for the network operator and we'll have a look at some of the issues that this causes a bit later on juniper also makes it relatively easy for the user but nothing is automatic the first thing we have to do as shown on the slide is to configure the connection to the validation cache I have used the same parameters for the Juniper configuration shown as for the Cisco IOS example earlier once we have configured the connection to the validator we need to configure validation policies the screen shows how to setup the validation policies I've called the policy statement rpki validation and then we look for the case where the prefix validation is valid or invalid or unknown notice juniper calls not found state unknown first thing we have to do is check incoming on the BGP announcement if the prefix coming in is in the validation database if it's in the validation database we then mark the validation state as valid this goes into the BGP table so it compares with a validation database and puts the state in the BGP table we do the same for invalid and we do the same for unknown this policy will be part of other incoming BGP policies on the ebgp session once we have done this we then apply the policy to the ebgp session itself and so the slide shows step 3 which is applying the inbound policy rpki validation to this neighbor called ISP upstream we check the validation state first before we then do the other policy called upstream in and this will flag in the BGP table whether the prefix is valid invalid or not found the Juneau status commands are very similar to the Cisco IOS ones to find out the details of the connection to the rpki servers we do show validation session detail to show the VR pees we do show validation replication database to find out the BGP table sure route protocol BGP if you recall Cisco IOS simply indicates the v4 valid the i-4 invalid and the n4 not found Juniper actually displays in the BGP table for the prefix itself the fool word valid invalid or unknown and finally sure route protocol BGP validation state valid will show the status valid prefixes in the BGP table I won't have a look at some of the implementation nodes you need to be a little bit careful with the vendor defaults juniper has followed the RFC quite closely and has left all the policy to the end-user the operator has to configure what policy they need to do the connection to the rpki cache the validator is configured and that's all it does it simply downloads the validation table there is no automatic linkage of this validation table to the BGP table but in Cisco IOS cisco automates as much of this as it can in fact the RFC recommends not doing this but cisco seems to do it in any case another thing to notice that prefix originated locally into I BGP automatically marked as valid there's no check against the cached validation table the idea is that the operator can originate non signed address blocks or other entity address space inside the own IBGP for whatever reason they need to do this.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.