Supplemental 64: RPKI Deployment Guide: From ROA Creation to Validation

Author: Patrick Luan de Mattos
Category: network-l2
Level: Advanced
Generated: 2026-04-19T00:04:22.905Z

SUPPLEMENTAL CHAPTER 64: RPKI Deployment Guide: From ROA Creation to Validation

Authors: [Your Name/Affiliation]
Date: October 26, 2023

Abstract:
In an era of increasing BGP route hijacking and prefix hijacking incidents, the security and integrity of the global routing system have become paramount. Resource Public Key Infrastructure (RPKI) provides a cryptographically verifiable framework to secure BGP routing. This chapter offers an advanced, in-depth guide to RPKI deployment, focusing on practical implementation from the creation of Route Origin Authorizations (ROAs) in RIPE and ARIN regions to the deployment and configuration of RPKI validators like Routinator and OctoRPKI. We will delve into the intricacies of configuring Border Gateway Protocol (BGP) for Route Origin Validation (ROV), providing comprehensive security analysis and a detailed troubleshooting guide. This chapter is designed for advanced networking professionals seeking to understand and implement robust RPKI solutions to mitigate routing threats and enhance network security.

1. Introduction to RPKI and its Role in BGP Security

The Border Gateway Protocol (BGP) is the de facto routing protocol of the internet. Its decentralized nature, while enabling global connectivity, also presents inherent vulnerabilities. Route hijacking, where an unauthorized entity advertises a network prefix it does not own, or prefix hijacking, where a legitimate prefix is advertised with incorrect origin ASNs, can lead to significant disruptions, traffic redirection, and security breaches. Historically, these incidents have been difficult to detect and mitigate effectively.

Resource Public Key Infrastructure (RPKI) emerges as a critical solution to this problem. RPKI is a framework for securing Internet number resource (INR) allocations and the routing information associated with them. It uses a hierarchical trust model based on X.509 certificates to provide a verifiable basis for route origin information.

Key RPKI Concepts:

• Resource Public Key Infrastructure (RPKI): A set of technologies and policies for securing Internet number resources (IP address blocks and AS numbers) using public key cryptography.
• Route Origin Authorization (ROA): A digitally signed object that authorizes a specific Autonomous System (AS) to originate a specific IP address prefix. ROAs are the cornerstone of RPKI for BGP security.
• RPKI Repository: A distributed system of servers that host RPKI data, including certificates, Certificate Revocation Lists (CRLs), and Validated ROA Payloads (VRPs).
• RPKI Validator: Software that retrieves RPKI data from repositories, validates it cryptographically, and produces a local cache of VRPs. These VRPs are then used by routers to perform Route Origin Validation.
• Route Origin Validation (ROV): The process by which a BGP router uses RPKI data (VRPs) to validate the origin AS of incoming BGP announcements.

This chapter will guide you through the practical steps of deploying RPKI, from creating ROAs to implementing ROV on your network infrastructure. We will explore the nuances of ROA creation in different Regional Internet Registry (RIR) environments, the selection and deployment of validator software, and the critical BGP configuration aspects for effective ROV.

2. Creating Route Origin Authorizations (ROAs)

ROAs are the fundamental building blocks of RPKI for securing BGP announcements. They assert that a specific AS is authorized to originate a given IP prefix. The process of creating ROAs varies slightly depending on the RIR from which you obtained your IP address resources. We will focus on the procedures for RIPE NCC and ARIN.

2.1 ROA Creation in RIPE NCC:

RIPE NCC provides a web-based portal for managing RPKI objects, including ROAs.

Prerequisites:

• An active RIPE NCC account with appropriate access rights.
• Knowledge of your allocated IP address prefixes and their corresponding AS Number (ASN).

Steps:

1. Login to the RIPEstat Portal: Navigate to https://stat.ripe.net/ and log in with your RIPE NCC credentials.
2. Access RPKI Management: Once logged in, find the "RPKI" or "Resource Management" section. The exact location might change, but it's typically within your account dashboard.
3. Navigate to ROA Creation: Look for an option like "Create ROA," "Manage ROAs," or "Resource Certificates and ROAs."
4. Select Resource(s): You will be presented with a list of your allocated IP address resources. Select the specific IP prefix (e.g., 192.0.2.0/24) for which you want to create a ROA.
5. Specify Origin ASN: Enter the AS Number that is authorized to originate this prefix. This is typically your own ASN.
6. Define Maximum Length (Optional but Recommended): This field specifies the longest valid prefix length that your ASN is authorized to originate for the selected prefix. For example, if you have 192.0.2.0/24 and you only want to announce /24s, you would set the maximum length to 24. If you also intend to announce /25s, you would set it to 25. Setting this correctly is crucial to prevent unauthorized more-specific announcements.
7. Review and Create: Carefully review the details of your ROA. Ensure the prefix, ASN, and maximum length are accurate. Once confirmed, click "Create ROA."
8. Confirmation: RIPE NCC will process your request. The ROA will be signed and published in the RIPE NCC RPKI repository. This process can take some time to propagate across the RPKI infrastructure.

Example RIPE NCC ROA Configuration (Conceptual):

2.2 ROA Creation in ARIN:

ARIN also provides a web-based interface for RPKI management.

Prerequisites:

• An active ARIN Online account with appropriate access rights.
• Knowledge of your allocated IP address prefixes and their corresponding AS Number (ASN).

Steps:

1. Login to ARIN Online: Navigate to https://www.arin.net/ and log in to your ARIN Online account.
2. Access RPKI Management: Locate the "RPKI" or "Resource Management" section within your account dashboard.
3. Navigate to ROA Creation: Look for options such as "Create ROA," "Manage ROAs," or "RPKI Management."
4. Select Resource(s): Choose the IP address block (e.g., 198.51.100.0/23) for which you wish to create a ROA.
5. Specify Origin ASN: Enter the authorized AS Number.
6. Define Maximum Length: Similar to RIPE, specify the longest acceptable prefix length for this block.
7. Review and Submit: Verify all details for accuracy. Submit the ROA creation request.
8. Confirmation: ARIN will process and publish the ROA in their repository.

Important Considerations for ROA Creation:

• Accuracy is Paramount: Incorrect ROAs can lead to legitimate routes being filtered by other networks. Double-check prefixes, ASNs, and maximum lengths.
• Cover All Authorized Origins: Ensure you create ROAs for all prefixes you legitimately announce and for all ASNs that are authorized to originate them.
• Maximum Length is Crucial: Properly setting the maximum length prevents unauthorized more-specific routes from being considered valid. For example, if you have a /24 and only want to announce the /24, set the max length to 24. If you also announce /25s derived from that /24, set the max length to 25.
• Regular Review: Periodically review your ROAs to ensure they align with your current routing policies and resource allocation.
• "Zerosday" Vulnerabilities and ROAs: While RPKI doesn't directly prevent zero-day exploits in BGP implementations, it significantly mitigates the impact of route hijacking. A successful hijack often relies on the ability to announce prefixes. ROAs, when widely adopted and enforced, make it harder for unauthorized prefixes to be accepted by the global routing system, even if a zero-day vulnerability in a BGP daemon is exploited for announcement.

3. Deploying RPKI Validators: Routinator and OctoRPKI

Once ROAs are created, they need to be fetched, validated, and made available to routers. This is the role of an RPKI validator. Validators download RPKI data from various repositories, perform cryptographic validation, and generate a list of Validated ROA Payloads (VRPs). These VRPs are then typically served to routers via the RPKI-to-Router (RTR) protocol.

We will explore two popular open-source RPKI validator implementations: Routinator and OctoRPKI.

3.1 Routinator:

Routinator is a robust and widely used RPKI validator written in Rust. It is known for its performance, reliability, and comprehensive feature set.

Installation and Configuration:

Routinator can be installed from source or via pre-compiled binaries. For production deployments, using a package manager or Docker is recommended.

Example Installation (Debian/Ubuntu using apt):

# Add Routinator repository
curl -fsSL https://packages.routinator.io/apt/$(lsb_release -cs)/routinator.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/routinator.gpg
echo "deb [arch=amd64] https://packages.routinator.io/apt/$(lsb_release -cs) stable main" | sudo tee /etc/apt/sources.list.d/routinator.list

# Update package list and install
sudo apt update
sudo apt install routinator

Basic Configuration (/etc/routinator/routinator.conf):

# The network interface and port to listen on for RTR connections.
# Example: "tcp://0.0.0.0:323"
rtr-listen = "tcp://0.0.0.0:323"

# The network interface and port to listen on for the API.
# Example: "tcp://127.0.0.1:8323"
api-listen = "tcp://127.0.0.1:8323"

# The directory where RPKI data will be cached.
# Example: "/var/lib/routinator/data"
data-dir = "/var/lib/routinator/data"

# List of RPKI repositories to fetch data from.
# These are the default RIR repositories and the global RPKI trust anchors.
repositories = [
    "https://rpki.ripe.net/validation/repository.xml",
    "https://rpki.arin.net/validation/repository.xml",
    "https://rpki.apnic.net/validation/repository.xml",
    "https://rpki.lacnic.net/validation/repository.xml",
    "https://rpki.afrinic.net/validation/repository.xml",
    "https://rrules.org/validation/repository.xml", # Global RPKI Trust Anchor
]

# Log level (e.g., debug, info, warn, error)
log-level = "info"

Starting and Enabling Routinator:

sudo systemctl start routinator
sudo systemctl enable routinator
sudo systemctl status routinator

3.2 OctoRPKI:

OctoRPKI is another capable RPKI validator, written in C++, known for its efficiency and memory footprint.

Installation and Configuration:

Similar to Routinator, OctoRPKI can be installed from source or through package managers.

Example Installation (Manual Compilation - simplified):

# Download source code
wget https://github.com/NLnetLabs/octokrpi/archive/refs/tags/v1.1.0.tar.gz
tar -xzf v1.1.0.tar.gz
cd octokrpi-1.1.0

# Build and install (requires build tools and libraries)
./configure --prefix=/usr/local
make
sudo make install

Basic Configuration (/usr/local/etc/octokrpi/octokrpi.conf):

# Listen address for RTR protocol
rtr-addr = "0.0.0.0:323"

# Listen address for API (optional)
api-addr = "127.0.0.1:8323"

# Data directory
data-dir = "/var/lib/octokrpi/data"

# Trust anchors and repositories
[trust-anchors]
ripe = "https://rpki.ripe.net/validation/repository.xml"
arin = "https://rpki.arin.net/validation/repository.xml"
apnic = "https://rpki.apnic.net/validation/repository.xml"
lacnic = "https://rpki.lacnic.net/validation/repository.xml"
afrinic = "https://rpki.afrinic.net/validation/repository.xml"
rrules = "https://rrules.org/validation/repository.xml" # Global RPKI Trust Anchor

# Log level
log-level = "info"

Starting and Enabling OctoRPKI:

You'll likely need to create a systemd service file for OctoRPKI.

# Example systemd service file (/etc/systemd/system/octokrpi.service)
[Unit]
Description=OctoRPKI RPKI Validator
After=network.target

[Service]
ExecStart=/usr/local/sbin/octokrpi -c /usr/local/etc/octokrpi/octokrpi.conf
Restart=on-failure
User=octokrpi # Create a dedicated user
Group=octokrpi

[Install]
WantedBy=multi-user.target

# Reload systemd, enable and start
sudo systemctl daemon-reload
sudo systemctl enable octokrpi
sudo systemctl start octokrpi
sudo systemctl status octokrpi

3.3 Choosing a Validator:

Both Routinator and OctoRPKI are excellent choices.

• Routinator: Generally considered more feature-rich and easier to set up via packages. It offers advanced features like ROC (RPKI Object Cache) and robust logging.
• OctoRPKI: Known for its low memory footprint and high performance, making it ideal for resource-constrained environments.

For most deployments, starting with Routinator via its package repository is recommended due to ease of installation and maintenance.

4. Configuring BGP for Route Origin Validation (ROV)

The final and crucial step is to configure your BGP routers to perform Route Origin Validation (ROV) using the VRPs provided by your RPKI validator. This is typically achieved by establishing an RPKI-to-Router (RTR) session between the validator and the router.

4.1 Understanding ROV States:

When a router receives a BGP prefix announcement, it compares it against the VRPs from the validator. The announcement is then assigned one of the following states:

• Valid: The prefix announcement matches a VRP with the correct origin ASN and a prefix length less than or equal to the maximum length specified in the VRP.
• Invalid: The prefix announcement does not match any VRP, or it matches a VRP but the origin ASN is incorrect, or the prefix length is longer than the maximum allowed in the matching VRP.
• Unknown: No RPKI data is available for the prefix announcement (e.g., no ROA exists, or the RPKI data is not yet available or has expired).

4.2 ROV Policy Enforcement:

Routers can be configured to take specific actions based on these states:

• Accept Valid: Always accept valid routes.
• Reject Invalid: Drop invalid routes. This is the most critical action for security.
• Accept/Reject Unknown: This is a policy decision.
  • Accept Unknown: Allows routes for which RPKI validation is not available. This is the safest approach during RPKI adoption to avoid accidental blackholing.
  • Reject Unknown: Drops routes for which RPKI validation is not available. This provides maximum security but requires near-universal RPKI coverage.

4.3 Configuring BGP Routers (Cisco IOS XR Example):

The configuration for ROV varies significantly between router vendors and operating systems. Here, we provide an example for Cisco IOS XR, which is common in large networks.

Step 1: Configure the RPKI Validator Connection:

First, you need to configure your router to connect to your RPKI validator's RTR server.

router bgp <your_asn>
 address-family ipv4 unicast
  bgp rpki server <validator_ip_address> port 323
  bgp rpki server <validator_ip_address_2> port 323  # For redundancy
 !
 address-family ipv6 unicast
  bgp rpki server <validator_ip_address> port 323
  bgp rpki server <validator_ip_address_2> port 323
 !
!

Replace <your_asn> with your AS Number and <validator_ip_address> with the IP address of your Routinator or OctoRPKI validator.

Step 2: Define ROV Policy:

Next, you define a route policy that uses the RPKI validation state.

route-policy ROV_POLICY
  if rpki-state is invalid then
    # Optionally log invalid routes
    log rpki-state invalid
    # Drop invalid routes
    drop
  elseif rpki-state is unknown then
    # Decide how to handle unknown routes.
    # For initial deployment, accept them to avoid blackholing.
    # As RPKI coverage improves, you might consider rejecting them.
    set local-preference 100 # Example: Set a slightly lower preference
    pass # Accept the route
  else # rpki-state is valid
    # Optionally log valid routes
    log rpki-state valid
    # Accept valid routes
    pass
  endif
end-policy
!

Step 3: Apply the ROV Policy to BGP Neighbors:

Finally, apply this policy to your BGP neighbors. You'll typically apply it to the inbound direction of received routes.

router bgp <your_asn>
 neighbor <neighbor_ip_address>
  remote-as <neighbor_asn>
  address-family ipv4 unicast
   route-policy ROV_POLICY in
  !
  address-family ipv6 unicast
   route-policy ROV_POLICY in
  !
 !
!

4.4 Configuring BGP Routers (Juniper Junos Example):

routing-options {
    validation {
        group rpki-validators {
            session <validator_ip_address> {
                port 323;
            }
            session <validator_ip_address_2> {
                port 323;
            }
        }
    }
}

policy-options {
    policy-statement ROV-POLICY {
        term INVALID {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
        term UNKNOWN {
            from {
                protocol bgp;
                validation-database unknown;
            }
            then accept; # Or reject, depending on policy
        }
        term VALID {
            from {
                protocol bgp;
                validation-database valid;
            }
            then accept;
        }
    }
}

protocols {
    bgp {
        group <your_bgp_group_name> {
            neighbor <neighbor_ip_address> {
                import ROV-POLICY;
                peer-as <neighbor_asn>;
            }
        }
    }
}

4.5 Configuring BGP Routers (FRRouting (FRR) Example):

! RPKI validator configuration
rpki server <validator_ip_address> port 323
rpki server <validator_ip_address_2> port 323

! ROV policy
route-map ROV_POLICY permit 10
 match rpki invalid
 ! Optionally log invalid routes
 ! log-rpki-state invalid
 !
 route-map ROV_POLICY permit 20
  match rpki unknown
  ! Decide how to handle unknown routes
  ! set local-preference 100
  !
 route-map ROV_POLICY permit 30
  match rpki valid
  ! Optionally log valid routes
  ! log-rpki-state valid

! Apply policy to BGP neighbors
router bgp <your_asn>
 neighbor <neighbor_ip_address> remote-as <neighbor_asn>
  route-map ROV_POLICY in
 !

4.6 Considerations for "zerosday" and ROV:

While ROV doesn't prevent the announcement of a route using a zero-day exploit, it significantly hinders the acceptance of that hijacked route by downstream networks. If a threat actor exploits a zero-day to announce a prefix they don't own, and a valid ROA exists for that prefix with a different origin ASN, networks enforcing ROV will reject the announcement. This makes the exploit much less effective. The widespread adoption of ROV is a critical defense against routing attacks, regardless of their origin.

5. Security Analysis and Best Practices

Implementing RPKI and ROV is a significant step towards securing your network's BGP routing. However, a comprehensive security strategy involves understanding potential attack vectors and adopting best practices.

5.1 Understanding RPKI Vulnerabilities (and their Mitigation):

• ROA Misconfigurations: Incorrectly configured ROAs (wrong ASN, too permissive max-length) can lead to legitimate routes being dropped or unauthorized routes being accepted.
  • Mitigation: Strict internal review processes for ROA creation, regular audits, and using tools that can analyze ROA coverage.
• RPKI Repository Compromise: While unlikely due to the distributed nature and cryptographic signing, a compromised RIR repository could theoretically lead to invalid data.
  • Mitigation: Validators typically use multiple trust anchors and repositories. The cryptographic signatures on RPKI objects are key. Routers should be configured to use multiple validators for redundancy and diversity.
• Validator Compromise: A compromised validator could serve falsified VRPs or stop serving valid VRPs.
  • Mitigation: Secure the validator server itself. Use redundant validators. Monitor validator status and logs. Configure routers to have multiple RTR sessions to different validators.
• RTR Protocol Weaknesses: The RTR protocol itself has been subject to analysis.
  • Mitigation: Ensure your validator and router implementations are up-to-date. Secure the network path between the validator and router (e.g., using private VLANs or firewalls).
• "Unknown" Route Handling: If routers reject "unknown" routes without sufficient RPKI coverage, it can lead to accidental blackholing.
  • Mitigation: Phased deployment. Start by accepting "unknown" routes and gradually transition to rejecting them as RPKI coverage increases globally. Monitor RPKI coverage statistics.

5.2 Best Practices for RPKI Deployment:

• Start Small, Iterate: Begin by creating ROAs for your most critical prefixes and implementing ROV on a subset of your BGP peers. Gradually expand coverage.
• Redundancy is Key: Deploy at least two RPKI validators, preferably in different physical locations. Configure your routers to establish RTR sessions with all deployed validators.
• Monitor RPKI Coverage: Use tools and dashboards to track the percentage of your prefixes that are covered by ROAs and the percentage of global routing table entries that are RPKI-enabled.
• Automate ROA Management: Explore tools or scripts that can help automate ROA creation and management, especially for large IP address allocations.
• Train Your Team: Ensure your network operations and engineering teams understand RPKI concepts, ROA creation, validator management, and ROV policy configuration.
• Document Everything: Maintain clear documentation of your ROAs, validator configurations, and ROV policies.
• Participate in Community Efforts: Engage with your RIR and the broader networking community to promote RPKI adoption.

5.3 "CVE-2026-XXXX" and RPKI:

While specific CVEs like cve-2026-34040, cve-2026-20963, cve-2026-5281, cve-2023-41974, cve-2025-43510, cve-2026-20963, cve-2026-3910, cve-2026-21510, cve-2023-46805, cve-2024-23113, cve-2017-6738, cve-2017-6744, cve-2017-8543, cve-2025-30400, cve-2026-27384, cve-2025-31277, cve-2026-5281 exploit, and cve-2026-5281 poc might represent vulnerabilities in various software or hardware components, RPKI's primary role is to secure BGP routing announcements. It is not a direct defense against all types of vulnerabilities.

However, if a CVE allows for unauthorized BGP announcement manipulation, RPKI and ROV become a crucial layer of defense. For example:

• If a vulnerability allows an attacker to inject BGP announcements from an unauthorized AS, ROV will filter these out if valid ROAs exist.
• If a vulnerability is related to DNS zone hijacking, and DNS infrastructure is announced via BGP, RPKI can help protect the integrity of those announcements.

The presence of specific CVEs often highlights the need for robust security practices, including RPKI. Vendor-issued patches for CVEs are essential for fixing underlying software flaws, and RPKI complements this by securing the routing infrastructure itself.

6. Troubleshooting RPKI and ROV

Implementing RPKI and ROV can sometimes lead to unexpected routing behavior. Here's a guide to troubleshooting common issues.

6.1 Validator Issues:

• Problem: No RTR session established between router and validator.
  • Troubleshooting:
    • Check firewall rules between the router and validator.
    • Verify the validator is running and listening on the correct port (default 323).
    • Check validator logs for connection errors.
    • Ensure IP addresses and ports are correctly configured on both sides.
    • Use tcpdump on the validator or router to see if packets are reaching the destination.
• Problem: Validator not fetching RPKI data or data is stale.
  • Troubleshooting:
    • Check validator logs for errors related to repository fetching.
    • Verify network connectivity from the validator to the RPKI repositories.
    • Ensure the repositories list in the validator configuration is correct and uses valid URLs.
    • Manually inspect the RPKI repository XML files for errors.
• Problem: Validator not serving VRPs.
  • Troubleshooting:
    • Check validator logs for any errors during VRP generation.
    • Verify the data-dir is accessible and has sufficient permissions.
    • Use the validator's API (if available) to query the status of VRP generation.

6.2 Router ROV Policy Issues:

• Problem: Legitimate routes are being dropped (marked as Invalid).
  • Troubleshooting:
    • Verify ROA: Check if a valid ROA exists for the prefix and origin ASN. Use RIR tools or RPKI lookup services.
    • Check Maximum Length: Ensure the ROA's maximum length is sufficient for the announced prefix.
    • Check Router's RPKI State: On the router, use commands to check the RPKI validation state of specific prefixes (e.g., show bgp rpki <prefix> on Cisco XR, show route validation <prefix> on Junos).
    • Examine Validator VRPs: Query your validator to see what VRPs it is serving for the affected prefix.
    • Check for "Unknown" Routes: If the route is marked as "Unknown," it means RPKI data is missing. This is not an invalid route but might be filtered by your policy.
• Problem: Unauthorized routes are being accepted.
  • Troubleshooting:
    • Verify ROA Existence: Confirm that a ROA should exist for the prefix with a different origin ASN. If no ROA exists, the route might be marked "Unknown."
    • Check ROV Policy: Ensure your ROV policy correctly drops "invalid" routes.
    • Review "Unknown" Handling: If you are accepting "unknown" routes, this is the likely cause. Gradually move towards rejecting "unknown" routes as RPKI coverage improves.
    • Check max-length: An attacker might be announcing a prefix that is shorter than what is authorized by a ROA, but still within the max-length. This is a valid announcement according to RPKI rules.

6.3 General Troubleshooting Steps:

• Systematic Approach: Troubleshoot in stages: ROA creation -> Validator operation -> Router RTR session -> Router ROV policy.
• Logging: Enable verbose logging on validators and routers. Analyze logs for error messages and warnings.
• Command-Line Tools: Utilize router-specific commands to inspect BGP state, RPKI validation status, and RTR sessions.
• Packet Capture: Use tcpdump or Wireshark to analyze traffic between the validator and router (RTR protocol) and BGP traffic.
• Online RPKI Tools: Leverage online tools like RIPEstat, ARIN WHOIS, and various RPKI lookup services to verify ROA status.

7. Exercises

These exercises are designed to reinforce the concepts covered in this chapter. They assume access to a lab environment with BGP-speaking routers and the ability to run RPKI validators.

Exercise 1: ROA Creation and Verification

1. Objective: Create a ROA for a test IP prefix and verify its existence.
2. Procedure:
   • Obtain a small, unused IP prefix (e.g., from a test allocation or a documentation block like 192.0.2.0/24).
   • Assume you have an AS number (e.g., AS65000).
   • Using the RIPE NCC or ARIN RPKI portal (or a simulated environment), create a ROA for 192.0.2.0/24 authorizing AS65000 to originate it, with a maximum length of 24.
   • Use an online RPKI lookup tool or RPKI cache query to verify that your ROA has been published and is retrievable.

Exercise 2: Setting up a Routinator Validator

1. Objective: Install and configure a basic Routinator instance.
2. Procedure:
   • Set up a virtual machine or container.
   • Install Routinator using its provided package repository.
   • Configure routinator.conf to listen on a specific IP address and port for RTR.
   • Start the Routinator service.
   • Verify that Routinator is running and has started fetching RPKI data (check logs).

Exercise 3: Connecting a Router to a Validator

1. Objective: Establish an RTR session between a BGP router and the configured Routinator instance.
2. Procedure:
   • Configure a BGP router (e.g., Cisco XR, Junos, FRR) to connect to your Routinator validator's IP address and port (e.g., 323).
   • On the router, check the status of the RPKI validator connection. It should show as established.
   • Use router commands to inspect the RPKI cache received from the validator.

Exercise 4: Testing ROV with Valid Routes

1. Objective: Observe how valid BGP announcements are handled with ROV.
2. Procedure:
   • Configure your BGP router to peer with another router that announces a prefix for which you have a valid ROA (created in Exercise 1).
   • Ensure the ROV policy on your router permits "valid" routes.
   • Observe the BGP table on your router. The route should be accepted and marked as valid.

Exercise 5: Testing ROV with Invalid Routes (Simulated)

1. Objective: Observe how invalid BGP announcements are handled with ROV.
2. Procedure:
   • Configure a second BGP router to announce the same prefix (192.0.2.0/24) but with an incorrect origin AS (e.g., AS65001 instead of AS65000).
   • Ensure your ROV policy on the receiving router drops "invalid" routes.
   • Observe the BGP table on the receiving router. The announcement from AS65001 should be dropped and marked as invalid.

Exercise 6: Testing ROV with More-Specific Routes

1. Objective: Test the impact of the max-length ROA parameter.
2. Procedure:
   • Modify your ROA (from Exercise 1) to have a max-length of 24.
   • Configure a BGP peer to announce 192.0.2.0/25 (a more-specific prefix) originating from AS65000.
   • With the ROV policy configured to drop "invalid" routes, observe if this /25 announcement is accepted or rejected. It should be rejected because the max-length is 24.
   • Now, change the ROA's max-length to 25. Re-test the /25 announcement. It should now be accepted.

Exercise 7: Handling "Unknown" Routes

1. Objective: Configure and test ROV policies that handle "unknown" routes.
2. Procedure:
   • Configure a BGP peer to announce a prefix for which no ROA exists.
   • Configure your ROV policy to:
     • Scenario A: Accept "unknown" routes. Observe that the route is accepted.
     • Scenario B: Reject "unknown" routes. Observe that the route is rejected.

Exercise 8: Redundant Validators

1. Objective: Configure routers to use multiple RPKI validators.
2. Procedure:
   • Set up a second RPKI validator (e.g., Octo

This chapter is part of the "From Zero to Network Doctor" open textbook series. All examples are educational and use safe, lab-only environments.