In life things may not go according to plan – and BGP networking is no exception. As you start using your secure routing table and deploying RPKI in your network, customers may notice that in rare situations some networks or IP addresses they want to access have become unreachable.
This chapter discusses steps you can take to find out whether a reported problem is the result of your routing security implementation. Do not expect a full BGP troubleshooting tutorial, just some tips and tricks and a few pointers on where to find additional information that can come in handy.
A good starting point for troubleshooting BGP is the Juniper Networks TechLibrary: https://www.juniper.net/documentation/en_US/junos/topics/task/verification/bgp-configuration-process-summary.html.
Check If a Destination is Present In the Routing Table
Junos OS uses two databases (tables) for routing information:
Routing table: Contains all the routing information learned by all routing protocols [RIB].
Forwarding table: Contains the routes actually used to forward packets [FIB].
Junos OS installs all active routes from the routing table into the forwarding table. The active routes are routes that are used to forward packets to their destinations. The Junos operating system kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the component responsible for forwarding packets.
If a customer suggests that a certain prefix seems unreachable, you need to check the route(s) to that prefix. In order to make sure the route has been installed and the destination is reachable from your network, you should look in both the routing and forwarding table.
There are three ways to check the different tables:
show route <destination-prefix>: This will display the routing table entries.
show route forwarding-table destination <destination-prefix>: This will show the routing engine's version of the destination prefix in the forwarding table.
show pfe route ip prefix <destination-prefix>: This will show the forwarding table entry that is actually installed in each PFE.
In a perfect world the destination prefix will be visible in
all three scenarios and should show an RPKI
valid if it has a valid ROA and passed the RPKI validation.
Check RPKI Validation State of a Route
In order to check if a route is used, it is essential to be
able to display information about the route validation database when
RPKI route validation is configured. You can query all route validation
records that match a given prefix or
origin-autonomous-system. In addition, you can filter the output by a specific RPKI cache
user@R1> show route inet.0: 3 destinations, 3 routes (2 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 220.127.116.11/32 *[BGP/170] 01:06:58, localpref 110, from 18.104.22.168 AS path: 200 I, validation-state: valid > to 10.0.0.2 via lt-1/2/0.1 172.16.1.1/32 *[BGP/170] 00:40:52, localpref 90, from 22.214.171.124 AS path: 200 I, validation-state: invalid Unusable 192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 126.96.36.199 AS path: 200 I, validation-state: unknown > to 10.0.0.2 via lt-1/2/0.1 188.8.131.52/32
Validation states can be any of the states defined in RFC 6811:
But also, another state that means “validation was not run against this at all”:
Unverified is different from unknown; a route that is unverified might be any of valid, invalid, or unknown, if validation were attempted. Unverified basically means that Origin Validation (RPKI) simply isn’t enabled or isn’t running on your router.
For additional commands visit the Juniper TechLibrary: https://www.juniper.net/ documentation/en_US/junos/topics/reference/command-summary/show-validation-database.html
Check If the RPKI Validator is Reachable and the Database is Up-to-Date
show validation statistics
This command shows statistics about the validation database. Obviously if you have enabled RPKI and the connection with the validator is working, you should see entries in the database:
user@host> show validation statistics Total RV records: 453455 Total Replication RV records: 453455 Prefix entries: 35432 Origin-AS entries: 124400 Memory utilization: 16.31MB Policy origin-validation requests: 234995 BGP import policy reevaluation notifications: 460268 inet.0: 435345 inet6.0: 3454
show validation database
This command shows you the actual content of the database:
user@host> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 172.16.1.0/24-32 1 10.0.77.1 valid 172.16.2.0/24-32 2 10.0.77.1 valid 172.16.3.0/24-32 3 10.0.77.1 valid 172.16.4.0/24-32 4 10.0.77.1 valid 172.16.5.0/24-32 5 10.0.77.1 valid 172.16.6.0/24-32 6 10.0.77.1 valid 172.16.7.0/24-32 7 10.0.77.1 valid 172.16.8.0/24-32 8 10.0.77.1 valid 184.108.40.206/19-24 26234 192.168.1.100 valid * 220.127.116.11/19-24 3320 192.168.1.200 invalid * 10.0.0.0/8-32 0 internal valid IPv4 records: 14 IPv6 records: 0
show validation session
If your validation database is empty or you want to check to
see if your validators are still up and running, you can do so with
show validation session brief and
show validation session detail commands:
user@host> show validation session brief Session State Flaps Uptime #IPv4/IPv6 records 18.104.22.168 up 2 00:01:37 13/0 10.255.255.11 up 3 00:00:01 1/0 10.255.255.12 connect 2 64/68
Note that the third session in this output shows
connect instead of
is most likely the result of configuring all three sessions under
the same RPKI group; if you do so, only two sessions will come up
and any additional ones will stay down if you don’t change the
maximum number of validators per group.
show validation session detail
user@host> show validation session detail Session 10.0.77.1, State: up Group: test, Preference: 100 Local IPv4 address: 10.0.77.2, Port: 2222 Refresh time: 300s Session flaps: 14, Last Session flap: 5h13m18s ago Hold time: 900s Record Life time: 3600s Serial (Full Update): 0 Serial (Incremental Update): 0 Session flaps 2 Session uptime: 00:48:35 Last PDU received: 00:03:35 IPv4 prefix count: 71234 IPv6 prefix count: 345
Re-Run Validation, Optionally, Against Only Specified Routes
When BGP origin validation is configured and for some reason
the database gets corrupted, or you would like to refresh it, manually
request a route
validation policy to be
reevaluated. This command causes dependent route validation records
to be reevaluated. Dependent route validation records are exactly
matching and more specific records:
user@host> request validation policy Enqueued 1 IPv4 records Enqueued 0 IPv6 records