Configuration Examples and Vendor-Specific Considerations

Configuration Examples and Vendor-Specific Considerations

Routing security concepts are universal, but syntax, execution semantics, and memory structures vary significantly across routing operating systems. This chapter provides production-ready configuration stanzas across major commercial and open-source platforms.

Cisco IOS XR: ROV, Filtering and RTR Configuration

Cisco IOS XR manages RPKI caches using the RPKI-to-Router protocol under the global routing configuration, and applies policy using Routing Policy Language (RPL):

! Configure RTR connection to two redundant RPKI validators
router bgp 65001
 rpki server 192.0.2.10
  transport tcp port 3323
  refresh-time 1800
  response-time 60
 !
 rpki server 192.0.2.20
  transport tcp port 3323
  refresh-time 1800
  response-time 60
 !
! Define RPL policy to drop Invalids and prefer Valids
route-policy EBGP-INBOUND
  # Bogon filtering
  if destination in BOGON-PREFIXES then
    drop
  endif
  # Enforce RPKI Route Origin Validation
  if rpki origin state is invalid then
    drop
  elseif rpki origin state is valid then
    set local-preference 200
    pass
  else
    # NotFound / Unknown
    set local-preference 100
    pass
  endif
end-policy

Juniper Junos: ROV, Filtering and RPKI Integration

In Junos, RPKI validation sessions reside under routing-options validation, and policy is applied under policy-statement:

routing-options {
    validation {
        group RPKI-VALIDATORS {
            session 192.0.2.10 {
                port 3323;
                local-address 192.0.2.1;
            }
            session 192.0.2.20 {
                port 3323;
                local-address 192.0.2.1;
            }
        }
    }
}

policy-options {
    policy-statement RPKI-ROV-POLICY {
        term REJECT-INVALID {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
        term PREFER-VALID {
            from {
                protocol bgp;
                validation-database valid;
            }
            then {
                local-preference 200;
                accept;
            }
        }
        term ACCEPT-UNKNOWN {
            then {
                local-preference 100;
                accept;
            }
        }
    }
}

Nokia SR OS: Routing Security Configuration

In Nokia SR OS (Service Router Operating System), RPKI sessions are established under the global router context, and validation is integrated into routing policy:

/configure router
    origin-validation
        rpki-session 192.0.2.10
            port 3323
            admin-state enable
        exit
        rpki-session 192.0.2.20
            port 3323
            admin-state enable
        exit
    exit
    policy-options
        begin
        policy-statement "ROV-POLICY"
            entry 10
                from
                    protocol bgp
                    origin-validation-state invalid
                exit
                action drop
            exit
            entry 20
                from
                    protocol bgp
                    origin-validation-state valid
                exit
                action accept
                    local-preference 200
                exit
            exit
            default-action accept
                local-preference 100
            exit
        exit
        commit

Open Source and Research Platforms: FRR and BIRD

FRRouting (FRR)

FRR integrates RPKI using the rpki daemon (linking librtr):

! /etc/frr/frr.conf
rpki
 rpki cache 192.0.2.10 3323 preference 1
 rpki cache 192.0.2.20 3323 preference 2
 exit
!
route-map TRANSIT-IN deny 10
 match rpki invalid
!
route-map TRANSIT-IN permit 20
 match rpki valid
 set local-preference 200
!
route-map TRANSIT-IN permit 30
 match rpki notfound
 set local-preference 100
!
router bgp 65001
 neighbor 198.51.100.1 route-map TRANSIT-IN in

BIRD 2 (Internet Routing Daemon)

BIRD 2 provides native RPKI table evaluation and filter syntax:

# bird.conf
protocol rpki RPKI1 {
    rtr 192.0.2.10 port 3323;
    refresh 600;
    retry 300;
    expire 7200;
    roav4 { table r4; };
    roav6 { table r6; };
}

filter bgp_in {
    # Check ROV state against RPKI table
    if roa_check(r4, net, bgp_path.last) = ROA_INVALID then {
        print "Rejecting RPKI Invalid: ", net, " from AS", bgp_path.last;
        reject;
    }
    if roa_check(r4, net, bgp_path.last) = ROA_VALID then {
        bgp_local_pref = 200;
        accept;
    }
    bgp_local_pref = 100;
    accept;
}

Common Pitfalls Across Platforms

1. Failure to Commit: On modular systems (IOS XR and Junos), policy edits require explicit commit. Uncommitted RPKI changes remain inactive while misleading administrators.
2. Implicit Fall-Through Behavior: In some platforms (Cisco IOS XE), failing to specify an explicit permit term after an RPKI deny causes an implicit deny-all, blackholing all valid traffic!
3. Session Flap CPU Spikes: Configuring RTR refresh timers too aggressively (e.g., 10 seconds) forces continuous re-evaluation of full tables, spiking router CPU. Maintain default timers (1800 to 3600 seconds).