hints:rpki
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| hints:rpki [2022/12/05 11:05] – [NLnetLabs Routinator] philip | hints:rpki [2025/07/05 23:34] (current) – [Installing Go] philip | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| On this page I'm collecting how to do various RPKI bits and pieces. Usually because the supplied documentation is incomplete, or just plain useless. | On this page I'm collecting how to do various RPKI bits and pieces. Usually because the supplied documentation is incomplete, or just plain useless. | ||
| + | |||
| + | These are my build notes, and I keep them current in so far as I use them for the validators I maintain for the NSRC Global R&E Routing Table report and for RouteViews. YMMV. | ||
| + | |||
| + | **NB**: always use the most up to date/ | ||
| Here is the list (so far): | Here is the list (so far): | ||
| Line 8: | Line 12: | ||
| * [[rpki# | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| - | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| + | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| * [[rpki# | * [[rpki# | ||
| - | The tips and tricks for the validator builds discussed below all are for Ubuntu | + | The tips and tricks for the validator builds discussed below all are for Ubuntu |
| ===== AS0 TALs ===== | ===== AS0 TALs ===== | ||
| Line 25: | Line 29: | ||
| Generally, to use these TALs, place each in a separate file (eg place APNIC' | Generally, to use these TALs, place each in a separate file (eg place APNIC' | ||
| + | |||
| ===== NLnetLabs Routinator ===== | ===== NLnetLabs Routinator ===== | ||
| - | Nothing to say here, the instructions just work, the validator installs sweetly, and just runs. As long as the instructions are followed. | + | Nothing to say here, the instructions just work, the validator installs sweetly, and just runs. As long as the instructions are followed. The current version of Routinator is 0.14.2, at time of writing. |
| If using Debian/ | If using Debian/ | ||
| - | You could build from source if you really want to, but why bother. | + | If the link to the supplied package is added to your package manager, for example **apt** on Ubuntu, then create an entry in **/ |
| < | < | ||
| - | deb [arch=amd64] https:// | + | deb [arch=amd64] https:// |
| </ | </ | ||
| + | |||
| + | (Note: if you are trying this on Ubuntu 24.04, there is no package for '' | ||
| Then run: | Then run: | ||
| Line 52: | Line 59: | ||
| Easy! | Easy! | ||
| - | Just a note though: as from Routinator | + | The installer will set up the necessary **systemd** file so that Routinator |
| + | < | ||
| + | repository-dir = "/var/ | ||
| + | rtr-listen = ["x.x.x.x: | ||
| + | http-listen = [" | ||
| + | </ | ||
| - | ===== FORT ===== | + | As from Routinator 0.12.0, the 5 RIR TALs are distributed built-in to the validator, so there is no longer any need to read and agree to the ARIN RPA. |
| - | FORT is the validator developed by NIC Mexico. More about it is on the [[https://fortproject.net/en/validator|Project page]]. | + | At time of writing, though, if you want to use the AS0 TALs from LACNIC and APNIC (see above), the " |
| + | < | ||
| + | [Service] | ||
| + | ExecStart= | ||
| + | ExecStart=/ | ||
| + | </ | ||
| + | where the **/ | ||
| + | < | ||
| + | repository-dir = "/var/lib/routinator/rpki-cache" | ||
| + | extra-tals-dir = "/ | ||
| + | rtr-listen = [" | ||
| + | http-listen = ["x.x.x.x: | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | ===== FORT ===== | ||
| - | FORT is not quite so easy to install, but still relatively simple | + | FORT is the validator developed by NIC Mexico. More about it is on the [[https:// |
| - | The installation instructions are on [[https:// | + | FORT is available as part of Ubuntu 22.04 packaging, but it is an older version (1.5.3-1). Likewise for Ubuntu 24.04, the FORT shipped is version 1.6.1-1build3. For this reason we use the latest NIC Mexico produced package. |
| - | (Actually, Marco d'Itri has created a [[https://tracker.debian.org/pkg/fort-validator|Debian package]] which you can use to install from. But the FORT team note that it may be a release or two behind their own packaging.) | + | FORT is not quite so easy to install, but still relatively simple as long as you follow the instructions on their [[https://nicmx.github.io/FORT-validator/ |
| First step is to grab the **.deb** file from their archive: | First step is to grab the **.deb** file from their archive: | ||
| < | < | ||
| - | wget https:// | + | wget https:// |
| </ | </ | ||
| and then install it: | and then install it: | ||
| < | < | ||
| - | sudo apt install ./fort_1.5.3-1_amd64.deb | + | sudo apt install ./fort_1.6.6-1_amd64.deb |
| </ | </ | ||
| Line 123: | Line 151: | ||
| and it should run successfully. You should see something like this when you run **systemctl status fort**: | and it should run successfully. You should see something like this when you run **systemctl status fort**: | ||
| < | < | ||
| - | * fort.service - FORT RPKI validator | + | ● fort.service - FORT RPKI validator |
| - | | + | |
| - | Drop-In: / | + | |
| - | | + | |
| - | | + | |
| Docs: man:fort(8) | Docs: man:fort(8) | ||
| | | ||
| - | Main PID: 3100 (fort) | + | Main PID: 148150 |
| - | Tasks: | + | Tasks: |
| - | | + | |
| + | CPU: 27.801s | ||
| | | ||
| - | | + | |
| + | |||
| + | Oct 07 22:58:03 fort systemd[1]: Started fort.service - FORT RPKI validator. | ||
| </ | </ | ||
| You can check by using **ps ax** to get: | You can check by using **ps ax** to get: | ||
| Line 144: | Line 173: | ||
| tcp | tcp | ||
| </ | </ | ||
| + | The **systemd** that ships with FORT doesn' | ||
| + | |||
| + | Create a new **/ | ||
| + | < | ||
| + | [Service] | ||
| + | Restart= | ||
| + | Restart=on-failure | ||
| + | </ | ||
| + | |||
| + | (If you edit the **/ | ||
| + | |||
| + | And your new FORT installation is now ready for service! | ||
| ===== RPKI-client ===== | ===== RPKI-client ===== | ||
| - | **rpki-client** is just a validator - it does not have the functionality to accept connections from a router. We'll come to that later on (we'll need to use Cloudflare' | ||
| - | **rpki-client** | + | **rpki-client** |
| + | |||
| + | **rpki-client** has now been packaged and is available | ||
| + | |||
| + | So for this reason, and to stay up to date, at least on Ubuntu, we have to build it ourselves. A pity that the **rpki-client** maintainers don't build their own deb package, or pre-build packages like NLnetLabs do with Routinator. Oh well. | ||
| + | |||
| + | ==== Initial Preparation ==== | ||
| Before you attempt to download and build it, the **rpki-client** instructions note that you need a few other packages in place. These include **automake**, | Before you attempt to download and build it, the **rpki-client** instructions note that you need a few other packages in place. These include **automake**, | ||
| Line 156: | Line 202: | ||
| The other required package noted in the instructions is **tls** from LibreSSL. LibreSSL is a branch of OpenSSL and is used on OpenBSD - not found on Linux, but seems to be appearing in the latest Debian/ | The other required package noted in the instructions is **tls** from LibreSSL. LibreSSL is a branch of OpenSSL and is used on OpenBSD - not found on Linux, but seems to be appearing in the latest Debian/ | ||
| - | First we go to [[https:// | + | First we go to [[https:// |
| < | < | ||
| - | wget https:// | + | wget https:// |
| </ | </ | ||
| We then unpack it: | We then unpack it: | ||
| < | < | ||
| - | tar zxf libressl-3.6.1.tar.gz | + | tar zxf libressl-3.9.2.tar.gz |
| </ | </ | ||
| and then build it: | and then build it: | ||
| < | < | ||
| - | cd libressl-3.6.1 | + | cd libressl-3.9.2 |
| ./configure --enable-libtls-only | ./configure --enable-libtls-only | ||
| make | make | ||
| Line 173: | Line 219: | ||
| Note the option to only build **libtls** - we don't need the rest of LibreSSL and it could well interfere with OpenSSL which will already be on the system. Now that **libtls** is built, the **install** action will put the libraries in **/ | Note the option to only build **libtls** - we don't need the rest of LibreSSL and it could well interfere with OpenSSL which will already be on the system. Now that **libtls** is built, the **install** action will put the libraries in **/ | ||
| < | < | ||
| - | -rw-r--r-- | + | -rw-r--r-- 1 root root 18679208 Jul 14 10:11 libtls.a |
| - | -rw-r--r-- | + | -rw-r--r-- 1 root root 923 Jul 14 10:11 libtls.la |
| - | lrwxrwxrwx | + | lrwxrwxrwx 1 root root |
| - | lrwxrwxrwx | + | lrwxrwxrwx 1 root root |
| - | -rw-r--r-- | + | -rw-r--r-- 1 root root |
| </ | </ | ||
| Run **sudo ldconfig** so that the system knows about the new libraries. | Run **sudo ldconfig** so that the system knows about the new libraries. | ||
| - | Next we need to get some packages that **rpki-client** needs. These are **libssl-dev** | + | Next we need to get some packages that **rpki-client** needs. These are **libssl-dev**, **rsync** and **zlib1g-dev**. |
| < | < | ||
| - | sudo apt install libssl-dev rsync | + | sudo apt install libssl-dev rsync zlib1g-dev |
| </ | </ | ||
| And now we are ready to build **rpki-client**. | And now we are ready to build **rpki-client**. | ||
| + | |||
| + | ==== Building rpki-client ==== | ||
| Easiest is just to install **rpki-client** from the [[https:// | Easiest is just to install **rpki-client** from the [[https:// | ||
| Line 212: | Line 260: | ||
| sudo make install | sudo make install | ||
| </ | </ | ||
| - | which will install the client in **/ | + | which will install the client in **/ |
| - | < | + | |
| - | wget https://www.arin.net/resources/ | + | |
| - | sudo mv arin.tal /etc/rpki | + | |
| - | </ | + | |
| Now the client can be run. There is no daemon option, it simply runs at the command line, and when it has finished downloading all the VRPs (around 10-15 minutes depending on bandwidth) it exits. But that's okay. Try running the client: | Now the client can be run. There is no daemon option, it simply runs at the command line, and when it has finished downloading all the VRPs (around 10-15 minutes depending on bandwidth) it exits. But that's okay. Try running the client: | ||
| < | < | ||
| Line 234: | Line 279: | ||
| </ | </ | ||
| and that's it. Every hour, cron will run **rpki-client** which will produce JSON output of all the VRPs it has collected. As noted above, JSON output is what is used by StayRTR and GoRTR as their input sources. Make sure that the **/ | and that's it. Every hour, cron will run **rpki-client** which will produce JSON output of all the VRPs it has collected. As noted above, JSON output is what is used by StayRTR and GoRTR as their input sources. Make sure that the **/ | ||
| + | |||
| + | If you would like to include the [[https:// | ||
| + | < | ||
| + | / | ||
| + | </ | ||
| It's a good idea to check the log file in case **rpki-client** reports issues trying to write local files etc. But mostly what you'll see there are all the transactions with the various CAs, and the problems encountered (there will be lots, unfortunately). | It's a good idea to check the log file in case **rpki-client** reports issues trying to write local files etc. But mostly what you'll see there are all the transactions with the various CAs, and the problems encountered (there will be lots, unfortunately). | ||
| - | ===== GoRTR ===== | ||
| - | I've included | + | ===== StayRTR ===== |
| + | |||
| + | StayRTR is a hard fork of GoRTR (which | ||
| + | |||
| + | StayRTR has now been packaged and is available | ||
| + | So for this reason, and to stay up to date, at least on Ubuntu, we have to build it ourselves. A pity that the **StayRTR** maintainers don't build their own deb package, or pre-build packages like NLnetLabs do with Routinator. | ||
| + | |||
| ==== Installing Go ==== | ==== Installing Go ==== | ||
| First you will need a working Go environment. Full instructions are at [[https:// | First you will need a working Go environment. Full instructions are at [[https:// | ||
| - | First off, download the latest Go package (1.19.3 at time of writing): | + | First off, download the latest Go package (1.24.4 at time of writing): |
| < | < | ||
| - | wget https:// | + | wget https:// |
| </ | </ | ||
| If you have an existing Go environment, | If you have an existing Go environment, | ||
| Line 257: | Line 312: | ||
| cd /usr/local | cd /usr/local | ||
| sudo chmod 777 . | sudo chmod 777 . | ||
| - | tar xzf ~/go1.19.3.linux-amd64.tar.gz | + | tar xzf ~/go1.24.4.linux-amd64.tar.gz |
| sudo chmod 755 . | sudo chmod 755 . | ||
| </ | </ | ||
| Line 274: | Line 329: | ||
| If the version shows what you installed, you are set! | If the version shows what you installed, you are set! | ||
| - | ==== Installing GoRTR ==== | + | ==== Building |
| - | + | ||
| - | Easiest way to do this is to build from the [[https:// | + | |
| - | + | ||
| - | **Note1**: You could download and use the provided [[https:// | + | |
| - | + | ||
| - | **Note2**: You could even download the [[https:// | + | |
| - | + | ||
| - | But we will focus on building from the source. | + | |
| - | < | + | |
| - | git clone https:// | + | |
| - | cd gortr | + | |
| - | make build-gortr build-rtrmon build-rtrdump | + | |
| - | </ | + | |
| - | which builds **gortr** as well as **rtrmon** and **rtrdump** (the latter used for testing purposes). | + | |
| - | + | ||
| - | Copy the resulting binaries to **/ | + | |
| - | < | + | |
| - | cd dist | + | |
| - | sudo -s | + | |
| - | cp -p gortr-v0.14.7-1-g2125744-linux-x86_64 / | + | |
| - | cp -p rtrdump-v0.14.7-1-g2125744-linux-x86_64 / | + | |
| - | cp -p rtrmon-v0.14.7-1-g2125744-linux-x86_64 / | + | |
| - | </ | + | |
| - | + | ||
| - | GoRTR has lots of options, but the ones we need are these: | + | |
| - | < | + | |
| - | -bind string | + | |
| - | Bind address (default ": | + | |
| - | | + | |
| - | URL of the cached JSON data (default " | + | |
| - | | + | |
| - | Check if file is still valid (default true) | + | |
| - | | + | |
| - | Check signature using provided public key (disable by passing -verify=false) | + | |
| - | </ | + | |
| - | We don't need to use the Cloudflare JSON source, given we have our own from the newly created RPKI-client. RPKI-client doesn' | + | |
| - | + | ||
| - | We run GoRTR like this: | + | |
| - | < | + | |
| - | / | + | |
| - | </ | + | |
| - | which will at least let us test that it works. Run it and see what happens - you should see output at the command line looking like this: | + | |
| - | < | + | |
| - | INFO[0001] New update (304138 uniques, 304138 total prefixes). 0 bytes. Updating sha256 hash -> 0592ddc6e9a82666f8ddc5eda8cad76cb61f22640f17199b1bff06b5928b9718 | + | |
| - | INFO[0002] Updated added, new serial 0 | + | |
| - | INFO[0002] GoRTR Server started (sessionID: | + | |
| - | </ | + | |
| - | And if you check the ports that are listening (**ss -an**) you will see: | + | |
| - | < | + | |
| - | tcp LISTEN | + | |
| - | tcp LISTEN | + | |
| - | </ | + | |
| - | Port 3323 is the listening port for Router connections. And Port 8080 is the metrics port, for monitoring systems to connect to. | + | |
| - | + | ||
| - | But perhaps this isn't good for long term operations as you'd prefer to have this start running automatically when the system starts. And for that we'd need to set up a suitable **systemd** entry. | + | |
| - | + | ||
| - | First off, let's create a user for GoRTR (it does not have to run as root): | + | |
| - | < | + | |
| - | sudo groupadd _gortr | + | |
| - | sudo useradd –g _gortr –s / | + | |
| - | </ | + | |
| - | Next we create a file **/ | + | |
| - | < | + | |
| - | # Settings for GoRTR. Consult https:// | + | |
| - | # more discussion and other available options | + | |
| - | + | ||
| - | STAYRTR_ARGS=-bind :3323 -verify=false -cache / | + | |
| - | # | + | |
| - | </ | + | |
| - | Then we go to the **/ | + | |
| - | < | + | |
| - | [Unit] | + | |
| - | Description=GoRTR RPKI to Router Server | + | |
| - | Documentation=https:// | + | |
| - | After=network.target | + | |
| - | + | ||
| - | [Service] | + | |
| - | EnvironmentFile=/ | + | |
| - | ExecStart=/ | + | |
| - | Type=exec | + | |
| - | User=_gortr | + | |
| - | Group=_gortr | + | |
| - | AmbientCapabilities=CAP_NET_BIND_SERVICE | + | |
| - | CapabilityBoundingSet=CAP_NET_BIND_SERVICE | + | |
| - | + | ||
| - | [Install] | + | |
| - | WantedBy=multi-user.target | + | |
| - | </ | + | |
| - | We then need to enable it: | + | |
| - | < | + | |
| - | sudo systemctl enable gortr | + | |
| - | </ | + | |
| - | which then displays: | + | |
| - | < | + | |
| - | Created symlink / | + | |
| - | </ | + | |
| - | and then we can run GoRTR, like this: | + | |
| - | < | + | |
| - | sudo systemctl start gortr | + | |
| - | </ | + | |
| - | Once it is running, check that it is working by running: | + | |
| - | < | + | |
| - | sudo systemctl status gortr | + | |
| - | </ | + | |
| - | and you should see something like this: | + | |
| - | < | + | |
| - | * gortr.service - GoRTR RPKI to Router Server | + | |
| - | | + | |
| - | | + | |
| - | Docs: https:// | + | |
| - | Tasks: 11 (limit: 4915) | + | |
| - | | + | |
| - | | + | |
| - | Jan 28 15:52:27 gortr systemd[1]: Starting | + | |
| - | Jan 28 15:52:27 gortr systemd[1]: Started StayRTR RPKI to Router Server. | + | |
| - | Jan 28 15:52:27 gortr gortr[17490]: | + | |
| - | Jan 28 15:52:28 gortr gortr[17490]: | + | |
| - | Jan 28 15:52:29 gortr gortr[17490]: | + | |
| - | Jan 28 15:52:29 gortr gortr[17490]: | + | |
| - | </ | + | |
| - | and you can also run the more traditional **ps ax** to see something like: | + | |
| - | < | + | |
| - | 17490 ? Ssl 0:04 / | + | |
| - | </ | + | |
| - | + | ||
| - | And that's it. Enjoy your new GoRTR installation. | + | |
| - | + | ||
| - | ===== StayRTR ===== | + | |
| - | + | ||
| - | StayRTR is a hard fork of [[rpki# | + | |
| - | + | ||
| - | As of writing this, there are no packages you can just download and run. So we'll download the source and build from there. | + | |
| - | + | ||
| - | **Note**: there is an experimental [[https:// | + | |
| - | + | ||
| - | Given it's parentage in GoRTR, the install process is very similar. First off, make sure you have a working Go environment - consult the [[rpki# | + | |
| Easiest way to install StayRTR is build from the [[https:// | Easiest way to install StayRTR is build from the [[https:// | ||
| Line 420: | Line 339: | ||
| which builds **stayrtr** as well as **rtrmon** and **rtrdump** (the latter used for testing purposes). | which builds **stayrtr** as well as **rtrmon** and **rtrdump** (the latter used for testing purposes). | ||
| - | Copy the resulting binaries to **/ | + | Copy the resulting binaries to **/ |
| < | < | ||
| cd dist | cd dist | ||
| - | sudo cp -p stayrtr-0.1-119-gad3ed83-linux-x86_64 / | + | sudo cp -p stayrtr-v0.6.2-linux-x86_64 / |
| - | sudo cp -p rtrdump-0.1-119-gad3ed83-linux-x86_64 / | + | sudo cp -p rtrdump-v0.6.2-linux-x86_64 / |
| - | sudo cp -p rtrmon-0.1-119-gad3ed83-linux-x86_64 / | + | sudo cp -p rtrmon-v0.6.2-linux-x86_64 / |
| </ | </ | ||
| Line 507: | Line 426: | ||
| and you should see something like this: | and you should see something like this: | ||
| < | < | ||
| - | * stayrtr.service - StayRTR RPKI to Router Server | + | ● stayrtr.service - StayRTR RPKI to Router Server |
| - | | + | |
| - | | + | |
| - | Docs: https:// | + | Docs: https:// |
| - | Tasks: | + | Main PID: 44045 (stayrtr) |
| + | Tasks: | ||
| + | Memory: | ||
| + | CPU: 3.805s | ||
| | | ||
| - | | + | |
| - | Jan 28 15:50:27 stayrtr | + | |
| - | Jan 28 15:50:27 stayrtr | + | Aug 15 16:57:06 rpki systemd[1]: Starting |
| - | Jan 28 15:50:27 stayrtr | + | Aug 15 16:57:07 rpki systemd[1]: Started |
| - | Jan 28 15:50:28 stayrtr | + | Aug 15 16:57:10 rpki stayrtr[44045]: time="2024-08-15T16:57:10+06:00" level=info |
| - | Jan 28 15:50:29 stayrtr | + | Aug 15 16:57:11 rpki stayrtr[44045]: time="2024-08-15T16:57:11+06:00" level=info |
| - | Jan 28 15:50:29 stayrtr stayrtr[17390]: | + | Aug 15 16:57:11 rpki stayrtr[44045]: time="2024-08-15T16:57:11+06:00" level=info |
| </ | </ | ||
| and you can also run the more traditional **ps ax** to see something like: | and you can also run the more traditional **ps ax** to see something like: | ||
| < | < | ||
| - | 17390 ? Ssl 0:04 / | + | 44045 ? Ssl 0:03 / |
| </ | </ | ||
| And that's it. Enjoy your new StayRTR installation. | And that's it. Enjoy your new StayRTR installation. | ||
| + | |||
| ===== Cisco IOS-XE Hints ===== | ===== Cisco IOS-XE Hints ===== | ||
| - | This section shows the basic configuration needed to get route origin validation up and running on a Cisco IOS-XE | + | This section shows the basic configuration needed to get route origin validation up and running on Cisco IOS-XE |
| - | Most commentary is for IOS-XE 16.x onwards. IOS 15.5S (and IOS-XE equivalent) | + | Most commentary is for IOS-XE 16.x. Older versions |
| - | ==== Configuration with Validator ==== | + | ==== IOS-XE |
| - | Setting up a Cisco router to talk with a validator is simple: | + | Setting up a Cisco IOS-XE |
| < | < | ||
| router bgp <ASN> | router bgp <ASN> | ||
| Line 542: | Line 465: | ||
| </ | </ | ||
| where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | ||
| + | |||
| + | Doing this will download the VRPs from the specified validator(s), | ||
| To find out what is in the validation database (IPv4 and IPv6 commands shown): | To find out what is in the validation database (IPv4 and IPv6 commands shown): | ||
| Line 553: | Line 478: | ||
| </ | </ | ||
| - | ==== Caveats ==== | + | ==== Cisco IOS-XE |
| Cisco IOS-XE has many defaults which are non-standard and will be potentially frustrating for operators: | Cisco IOS-XE has many defaults which are non-standard and will be potentially frustrating for operators: | ||
| - | * Automatically activates route origin validation (cannot | + | |
| + | | ||
| * Automatically drops invalids (can be turned off!) | * Automatically drops invalids (can be turned off!) | ||
| * Locally originated prefixes are always marked as valid (cannot be turned off!) - fixed in most recent IOS-XE 17.x releases | * Locally originated prefixes are always marked as valid (cannot be turned off!) - fixed in most recent IOS-XE 17.x releases | ||
| - | * Automatically prefers Valid path over Invalid/ | + | * Automatically prefers Valid path over Invalid/ |
| - | * If validator disappears, router validation database is flushed within a few minutes - fixed in most recent IOS-XE 16.x releases | + | * If validator disappears, router validation database is flushed within a few minutes - fixed in most recent IOS-XE 16.6 releases |
| + | |||
| + | To turn off the checking of the RPKI validation database (**IOS-XE 15.5 onwards**): | ||
| + | < | ||
| + | router bgp < | ||
| + | | ||
| + | bgp bestpath prefix-validate disable | ||
| + | | ||
| + | bgp bestpath prefix-validate disable | ||
| + | </ | ||
| + | The ROAs are still listed in the RPKI table but the router will not use them. (This should be the default, as per RFC.) | ||
| To turn off the automatic dropping of invalids: | To turn off the automatic dropping of invalids: | ||
| < | < | ||
| router bgp <ASN> | router bgp <ASN> | ||
| - | bgp bestpath prefix-validate allow-invalid | + | |
| + | bgp bestpath prefix-validate allow-invalid | ||
| + | | ||
| + | bgp bestpath prefix-validate allow-invalid | ||
| </ | </ | ||
| + | A new set up of RPKI in a Cisco IOS-XE network should start with " | ||
| + | < | ||
| + | router bgp <ASN> | ||
| + | | ||
| + | bgp bestpath prefix-validate disable | ||
| + | bgp bestpath prefix-validate allow-invalid | ||
| + | | ||
| + | bgp bestpath prefix-validate disable | ||
| + | bgp bestpath prefix-validate allow-invalid | ||
| + | </ | ||
| + | |||
| + | Once they are ready to implement RPKI, first remove the '' | ||
| + | |||
| + | The major show-stopper for an IOS-XE based network is the insertion of validation check in the BGP path selection process, over-riding '' | ||
| + | |||
| To propagate the validation state in IBGP, both BGP speakers need: | To propagate the validation state in IBGP, both BGP speakers need: | ||
| < | < | ||
| Line 575: | Line 529: | ||
| **Summary: | **Summary: | ||
| - | ==== Implementing Route Origin Validation | + | ===== Cisco IOS-XR Hints ===== |
| - | The final step in Cisco IOS-XE is to implement Route Origin Validation. This is achieved simply by turning off the knob we noted above that automatically drops //invalid// prefixes. | + | This section shows the basic configuration needed to get route origin validation up and running on Cisco IOS-XR platforms. |
| + | |||
| + | Most commentary | ||
| + | |||
| + | ==== IOS-XR Configuration with Validator ==== | ||
| + | |||
| + | Setting up a Cisco IOS-XR router to talk with a validator is done like this: | ||
| < | < | ||
| router bgp <ASN> | router bgp <ASN> | ||
| - | no bgp bestpath | + | rpki server <ip address> |
| + | bind-source interface Loopback0 | ||
| + | transport tcp port < | ||
| + | refresh-time 3600 | ||
| + | response-time 600 | ||
| + | </ | ||
| + | where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | ||
| + | |||
| + | To find out what is in the validation database (IPv4 and IPv6 commands shown): | ||
| + | < | ||
| + | show ip bgp rpki table | ||
| + | show bgp ipv6 rpki table | ||
| + | </ | ||
| + | and to find out the status of the connection to the validator: | ||
| + | < | ||
| + | show ip bgp rpki server summary | ||
| + | </ | ||
| + | |||
| + | To turn on validation for prefixes on the router, we need to activate the functionality per address family (as per best practice - the operator needs to choose!). | ||
| + | < | ||
| + | router bgp < | ||
| + | | ||
| + | bgp origin-as validation enable | ||
| + | bgp bestpath origin-as use validity | ||
| + | bgp bestpath origin-as allow invalid | ||
| + | ! | ||
| + | | ||
| + | bgp origin-as validation enable | ||
| + | bgp bestpath origin-as use validity | ||
| + | bgp bestpath origin-as allow invalid | ||
| + | </ | ||
| + | The above enables origin validation, and still allows invalid prefixes in the BGP table. | ||
| + | |||
| + | Once you are ready to drop invalids, as per recommended best practices: | ||
| + | < | ||
| + | router bgp < | ||
| + | address-family ipv4 unicast | ||
| + | | ||
| + | address-family ipv6 unicast | ||
| + | no bgp bestpath origin-as allow invalid | ||
| + | </ | ||
| + | |||
| + | To display the validation state of prefixes, you can use the following command: | ||
| + | < | ||
| + | RP/ | ||
| + | invalid | ||
| + | not-found | ||
| + | standby | ||
| + | valid filter routes with valid origin-as | ||
| + | | Output Modifiers | ||
| + | <cr> | ||
| </ | </ | ||
| + | The sub-options will display all the prefixes fitting into each category. | ||
| ===== Juniper Hints ===== | ===== Juniper Hints ===== | ||
| Line 589: | Line 600: | ||
| ==== Configuration with Validator ==== | ==== Configuration with Validator ==== | ||
| - | The configuration needed for JunOS to talk with a validator is: | + | The configuration needed for JunOS to talk with two validators looks like this: |
| < | < | ||
| Line 595: | Line 606: | ||
| validation { | validation { | ||
| group ISP { | group ISP { | ||
| - | session <ip address>; | + | |
| - | port < | + | |
| - | refresh-time 600; | + | refresh-time 600; |
| - | hold-time 3600; | + | |
| + | preference 1; | ||
| + | | ||
| + | local-address <router loopback>; | ||
| + | | ||
| + | /* validatorB */ | ||
| + | session <ip address validatorB> | ||
| + | | ||
| + | hold-time 3600; | ||
| + | preference 2; | ||
| + | port < | ||
| + | local-address <router loopback>; | ||
| + | } | ||
| } | } | ||
| } | } | ||
| Line 604: | Line 627: | ||
| </ | </ | ||
| where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | ||
| + | |||
| + | Two validators are recommended - if you only have one, then edit the above to suit. | ||
| This simply creates a validation database on the router - it does not touch the BGP RIB. To find out what is in the validation database: | This simply creates a validation database on the router - it does not touch the BGP RIB. To find out what is in the validation database: | ||
| Line 677: | Line 702: | ||
| ==== Implementing Route Origin Validation ==== | ==== Implementing Route Origin Validation ==== | ||
| - | The final step in JunOS is to implement Route Origin Validation. This again needs a policy | + | The final step in JunOS is to implement Route Origin Validation. This is can be simply achieved by replacing the: |
| + | < | ||
| + | next policy | ||
| + | </code> | ||
| + | line in the INVALID term with: | ||
| + | < | ||
| + | reject | ||
| + | </code> | ||
| + | |||
| + | This will discard invalid prefixes as they arrive | ||
| < | < | ||
| - | to be done | + | show route protocol bgp validation invalid hidden |
| </ | </ | ||
| + | The discarded prefixes are still in Adj-RIB-In and can be seen with the **hidden** keyword option. | ||
| ===== BIRD Hints ===== | ===== BIRD Hints ===== | ||
| - | This section shows the basic configuration needed to get route origin validation up and running on a BIRD platform. This will be of most interest to IXPs, as BIRD is the mostly widely used Route Server implementation today. The configuration here is for BIRDv2 (2.0.8 at time of writing). | + | This section shows the basic configuration needed to get route origin validation up and running on a [[https:// |
| ==== Configuration with Validator ==== | ==== Configuration with Validator ==== | ||
| Line 697: | Line 732: | ||
| roa6 { table rpki6; }; | roa6 { table rpki6; }; | ||
| remote <ip address1> | remote <ip address1> | ||
| - | retry 300; | + | retry keep 600; |
| + | refresh keep 3600; | ||
| + | expire keep 7200; | ||
| } | } | ||
| Line 704: | Line 741: | ||
| roa6 { table rpki6; }; | roa6 { table rpki6; }; | ||
| remote <ip address2> | remote <ip address2> | ||
| - | retry 300; | + | retry keep 600; |
| + | refresh keep 3600; | ||
| + | expire keep 7200; | ||
| } | } | ||
hints/rpki.1670238342.txt.gz · Last modified: by philip