# RPKI on IOS-XE (Enabling the feature)
Load **ios-xe.rpki.enable.init.cfg**
```
#IOS-XE (R1, R2, R3)
config replace flash:ios-xe.rpki.enable.init.cfg
```
BGP is already setup between R1-R2 and R2-R3.
Configure RPKI on R2 for both IPv4 and IPv6, but do not use the information for local policy yet. We only want R2 to connect to the RPKI server and we want to see that R2 is loading the ROAs correctly, but we don’t want R2 to act on this information yet and actually perform any validity checks.
The RPKI server is reachable at 10.100.100.1 on port 3323.
## Answer
```
#R2
router bgp 1245
bgp rpki server tcp 10.100.100.1 port 3323 refresh 600
!
add ipv4
bgp bestpath prefix-validate disable
add ipv6
bgp bestpath prefix-validate disable
```
## Explanation
BGP RPKI Route Origination Validation is a BGP security mechanism which reduces malicious and accidental route origination from the wrong AS. This prevents incidents such as the YouTube hijacking of 2008. During this incident, an AS attempted to null route YouTube’s prefix, but accidentally leaked Youtube’s prefix out to the internet, breaking YouTube’s traffic.
In RPKI Route Origination, each AS issues ROAs (Route Origination Authorizations) with the RIR. Typically the RIR hosts the signed ROAs, but each AS has the option to host their own CA and sign ROAs if they want. Each ROA object has three pieces of information:
* The prefix (i.e. 1.0.0.0/22)
* The max prefix length (i.e. /24)
* The originating AS (i.e. 14003)
The ROA is a certification that the prefix can be announced by the originating AS. Announcements from other originating ASs should not be trusted.
The RIR signs this ROA and adds it to the RPKI repository. A route validation server, such as Routinator in our lab, is needed to load all ROAs from all RIRs, and interface with the routers. The routers use the RtR (RPKI to Router) protocol to pull in the database of ROAs from Routinator. The routers then use this locally to determine whether a given prefix:
* Is valid (the prefix, prefix len, and originating AS match an ROA)
* Is invalid (the prefix and prefix len match an ROA, but the originating AS is different)
* Is not found (the prefix and prefix len do not match any ROA)
Note that this system does not validate the entire AS path. Only the originating AS (the first AS in the path) is validated using this system. This is “route origination validation” and not “path validation.”
### Enabling RPKI on IOS-XE
On IOS-XE, we can only use TCP to interface with the RPKI server. This command enables the TCP connection:
```
#R2
router bgp 1245
bgp rpki server tcp 10.100.100.1 port 3323 refresh 600
```
Upon establishing the connection, the router will automatically start downloading ROAs and using them for prefix validation. The router will reject any prefixes that are invalid (they have a matching ROA but the originating AS is not valid).
To prevent this, and simply establish the connection without “doing anything” with the RPKI information, we use the following command:
```
#R2
router bgp 1245
add ipv4
bgp bestpath prefix-validate disable
add ipv6
bgp bestpath prefix-validate disable
```
This is different from the similar command **bgp bestpath prefix-validate allow-invalid**, which allows invalid prefixes to still be accepted and used as a bestpath. However, with the **allow-invalid** command, prefix validation is still occuring, and a valid prefix will be preferred over an invalid prefix. IOS inserts this validity check before the local preference in the bestpath algorithm. So to fully disable this behavior, we use the **disable** keyword instead of **allow-invalid**.
## Verification
Notice that the BGP table has RPKI validation codes.
* **V** means the prefix has a matching ROA
* **I** means the prefix has an ROA but the originating AS is not valid
* **N** means the prefix does not have a matching ROA, so the validity cannot be verified
Because we have disabled prefix validation for IPv4/uni and IPv6/uni, we should not see these codes in our BGP tables:
However, we should be able to see status about the RPKI server and browse the RPKI table. We can see information about the TCP connection using the following command:
More importantly, we can browse the RPKI table for both IPv4 and IPv6:
The table is fairly self explanatory. The **maxlen** column works sort of like **le** in a prefix list. For example, look at 1.6.8.0/22. The maxlen is 24, so the prefixes 1.6.8.0/22, 1.6.8.0/23, 1.6.9.0/24, etc, will match this ROA.
In the next lab we will begin acting on this information.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bgp-rpki/rpki-on-ios-xe-enabling-the-feature.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.