RPKI Invalid Announcement from a New Transit
AS 65000's Nokia SR OS border router receives 198.51.100.0/24 from two eBGP peers. Peer A (AS 64500) sends AS_PATH 64500 64496. Peer B (AS 64501) sends AS_PATH 64501 64999. The RPKI validator has a ROA for 198.51.100.0/24 with origin AS 64496 and maxLength 24. Peer A is a long-standing transit provider; Peer B is a new cheap transit with a shorter IGP cost. The router currently has no RPKI policy and selects Peer B because its router-id is lower. The security team wants to drop RPKI-invalid announcements but keep valid ones and avoid a full outage if the validator is unreachable. The router has a cached validator state and a local prefix-list containing the two peers. The operations team is worried about dropping prefixes that are 'not found' because many customers use unregistered space.
1. Classify each path and explain why AS_PATH length does not determine the RPKI result.
Read the worked answer
The ROA covers 198.51.100.0/24 with origin 64496 and maxLength 24. Peer A's AS_PATH ends in 64496, so the origin matches and the prefix length is allowed: Valid. Peer B's AS_PATH ends in 64999, so the origin mismatches: Invalid. AS_PATH length and IGP cost do not matter for RPKI classification; RPKI validates origin and prefix length. The current best path is Peer B only because BGP has no RPKI policy and Peer B's router-id is lower. RPKI state is not a BGP attribute and does not affect best-path unless policy acts on it.
2. Design the policy actions for Valid, Invalid, and NotFound, including validator-unreachable behavior.
Read the worked answer
Create a route policy that matches the BGP origin-validation state. Reject Invalid for this prefix, or for all prefixes if policy agrees. Accept Valid. For NotFound, decide explicitly: the outage concern argues for accept with a community or lower local-preference rather than silent drop, but that still allows unregistered hijacks. Apply the policy inbound on both eBGP peers so evaluation occurs before best-path. If the validator is unreachable, use cached state; do not automatically convert all routes to Valid. Fail-open only for NotFound if operations accepts the risk, and never fail-open Invalid when the cache says Invalid.
3. Peer B later advertises 198.51.100.0/25 with origin 64999. What is the RPKI result and why is it dangerous if accepted?
Read the worked answer
The /25 is outside the ROA maxLength of 24 and has the wrong origin, so it is Invalid. If accepted, BGP would prefer the more specific /25 over the /24 and blackhole that quarter of the address space. The policy must cover all prefixes and both peers, not just the exact /24. Also check whether a Valid /25 could exist under a different ROA with maxLength 25; without such a ROA it is Invalid. Use show router bgp routes 198.51.100.0/24 detail and the validator state to confirm.