User Tools

Site Tools


hints:rpki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
hints:rpki [2022/05/22 15:21] – [Implementing Route Origin Validation] philiphints:rpki [2024/03/20 22:24] (current) – [StayRTR] 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/current versions of the validators - things are moving pretty quickly, and the older versions can often be quite buggy, if not unstable.
  
 Here is the list (so far): Here is the list (so far):
Line 8: Line 12:
   * [[rpki#fort|FORT]] validator from NIC Mexico   * [[rpki#fort|FORT]] validator from NIC Mexico
   * [[rpki#rpki-client|RPKI-client]] validator   * [[rpki#rpki-client|RPKI-client]] validator
-  * [[rpki#gortr|GoRTR]] from Cloudflare 
   * [[rpki#stayrtr|StayRTR]]   * [[rpki#stayrtr|StayRTR]]
   * [[rpki#cisco_ios-xe_hints|Cisco IOS-XE]]   * [[rpki#cisco_ios-xe_hints|Cisco IOS-XE]]
Line 15: Line 18:
   * [[rpki#frrouting_hints|FRR]]   * [[rpki#frrouting_hints|FRR]]
  
-The tips and tricks for the validator builds discussed below all are for Ubuntu 20.04. They should also work just fine on Ubuntu 18.04 (which is supported until April 2023) and I'll note if I experience otherwise. I've not tested anything on the Ubuntu interims since 20.04, although I plan to test 22.04 which has just been released.+The tips and tricks for the validator builds discussed below all are for Ubuntu 22.04. They should also work just fine on Ubuntu 18.04 (which is supported until April 2023) and on Ubuntu 20.04 (which is supported until April 2025).
  
 ===== AS0 TALs ===== ===== AS0 TALs =====
Line 25: Line 28:
  
 Generally, to use these TALs, place each in a separate file (eg place APNIC's one in **apnic-as0.tal**) in the usual place where you keep your TALs - it depends on your validator of course. Generally, to use these TALs, place each in a separate file (eg place APNIC's one in **apnic-as0.tal**) in the usual place where you keep your TALs - it depends on your validator of course.
 +
 ===== 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.13.2, at time of writing.
  
 If using Debian/Ubuntu as I do, then just use the supplied package and your favourite package manager. Described in NLnetLabs's [[https://github.com/NLnetLabs/routinator#quick-start-with-debian-and-ubuntu-packages| Github]] repo. If using Debian/Ubuntu as I do, then just use the supplied package and your favourite package manager. Described in NLnetLabs's [[https://github.com/NLnetLabs/routinator#quick-start-with-debian-and-ubuntu-packages| Github]] repo.
  
-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 **/etc/apt/sources.list.d** called **routinator.list** and put this in it (which is for Ubuntu 20.04):+If the link to the supplied package is added to your package manager, for example **apt** on Ubuntu, then create an entry in **/etc/apt/sources.list.d** called **nlnetlabs.list** and put this in it (which is for Ubuntu 22.04):
  
 <code> <code>
-deb [arch=amd64] https://packages.nlnetlabs.nl/linux/ubuntu/ focal main+deb [arch=amd64] https://packages.nlnetlabs.nl/linux/ubuntu/ jammy main 
 +</code> 
 + 
 +Then run: 
 + 
 +<code> 
 +wget -qO- https://packages.nlnetlabs.nl/aptkey.asc | sudo tee /etc/apt/trusted.gpg.d/nlnetlabs.asc 
 +</code> 
 + 
 +And then finally: 
 + 
 +<code> 
 +apt-get update 
 +apt install routinator
 </code> </code>
  
 Easy! Easy!
 +
 +The installer will set up the necessary **systemd** file so that Routinator starts automatically on boot. Remember to modify the **/etc/routinator/routinator.config** file so that Routinator listens on the IPv4 (and IPv6) ports of the system - and you can enable the default statistics pages which listen on port 8323. A working configuration file would look like this:
 +<code>
 +repository-dir = "/var/lib/routinator/rpki-cache"
 +rtr-listen = ["x.x.x.x:3323", "[x:x:x:x::x]:3323"]
 +http-listen = ["x.x.x.x:8323", "[x:x:x:x::x]:8323"]
 +</code>
 +
 +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. 
 +
 +At time of writing, though, if you want to use the AS0 TALs from LACNIC and APNIC (see above), the "extra-tals-dir" option mentioned in the configuration guide only works on the command line and not in the Routinator configuration file that ships as part of the package. This means creating an user modification to the systemd setup **/etc/systemd/system/routinator.service** like this:
 +<code>
 +[Service]
 +ExecStart=
 +ExecStart=/usr/bin/routinator --config=/etc/routinator/routinator.conf --extra-tals-dir="/var/lib/routinator/tals" --syslog server
 +</code>
 +where the **/var/lib/routinator/tals** folder contains the two AS0 TALs you want to use. The first blank **ExecStart** is needed to overwrite the one that is shipped in **/lib/system/system/routinator.service**. Once this bug is fixed you can remove this user defined systemd setting and put the **extra-tals-dir** definition in the configuration file, like this:
 +<code>
 +repository-dir = "/var/lib/routinator/rpki-cache"
 +extra-tals-dir = "/var/lib/routinator/tals"
 +rtr-listen = ["x.x.x.x:3323", "[x:x:x:x::x]:3323"]
 +http-listen = ["x.x.x.x:8323", "[x:x:x:x::x]:8323"]
 +</code>
 +
 +
  
 ===== FORT ===== ===== FORT =====
  
-FORT is not quite so easy to install, but still relatively simple as long as you follow the instructions closely.+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, version 1.6.1 has been released and fixes many issues present in previous versions.
  
-The installation instructions are on [[https://nicmx.github.io/FORT-validator/installation.html| Github]].+FORT is available as part of Ubuntu 22.04 packaging, but it is an older version (1.5.3-1), so for this reason we use the latest NIC Mexico produced package.
  
-(ActuallyMarco 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 installbut still relatively simple as long as you follow the instructions on their [[https://nicmx.github.io/FORT-validator/installation.htmlGithub]] repo closely.
  
 First step is to grab the **.deb** file from their archive: First step is to grab the **.deb** file from their archive:
  
 <code> <code>
-wget https://github.com/NICMx/FORT-validator/releases/download/1.5.3/fort_1.5.3-1_amd64.deb+wget https://github.com/NICMx/FORT-validator/releases/download/1.6.1/fort_1.6.1-1_amd64.deb
 </code> </code>
 and then install it: and then install it:
 <code> <code>
-sudo apt install ./fort_1.5.3-1_amd64.deb+sudo apt install ./fort_1.6.1-1_amd64.deb
 </code> </code>
  
Line 127: Line 169:
 tcp     LISTEN          128                     0.0.0.0:3323                0.0.0.0:* tcp     LISTEN          128                     0.0.0.0:3323                0.0.0.0:*
 </code> </code>
 +The **systemd** that ships with FORT doesn't have a "restart on failure" setting so it is a good idea that we do this so that if/when FORT crashes, it will automatically restart.
 +
 +Create a new **/etc/systemd/system/fort.service** (which is where to create user-defined extras for **systemd** go), and in it put:
 +<code>
 +[Service]
 +Restart=
 +Restart=on-failure
 +</code>
 +
 +(If you edit the **/lib/systemd/system/fort.service** it will be overwritten on the next upgrade of FORT, so it is best create the user entry instead.)
 +
 +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's [[rpki#gortr|GoRTR]] or its fork, [[rpki#stayrtr|StayRTR]]). 
  
-**rpki-client** has no packagealthough Marco d'Itri is working on one as you can find from the [[https://packages.debian.org/sid/rpki-client|Debian package tracker]].+**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 [[rpki#stayrtr|StayRTR]]which is a fork of Cloudflare's now unmaintained GoRTR). 
 + 
 +**rpki-client** has now been packaged and is available as part of the Ubuntu 22.04 distributionHowever, the packaged version is old (version 7.6). At the time of writing, the current release of **rpki-client** is version 8.7. 
 + 
 +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**, **autoconf**, **make**, **git** itself, **libtool** and **expat**. This is all quite easy using the Ubuntu package manager. 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**, **autoconf**, **make**, **git** itself, **libtool** and **expat**. This is all quite easy using the Ubuntu package manager.
Line 139: Line 198:
 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/Ubuntu beta builds. So we need to download the bits we need and install. The **rpki-client** instructions don't say anything about how to do that. 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/Ubuntu beta builds. So we need to download the bits we need and install. The **rpki-client** instructions don't say anything about how to do that.
  
-First we go to [[https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/|https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/]] and select the latest package, which is libressl-3.4.2.tar.gz at time of writing+First we go to [[https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/|https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/]] and select the latest package, which is libressl-3.8.3.tar.gz at time of writing (libressl-3.9.0 is also out now, but I'm staying away from .0 releases)
 <code> <code>
-wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.4.2.tar.gz+wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.8.3.tar.gz
 </code> </code>
 We then unpack it: We then unpack it:
 <code> <code>
-tar zxf libressl-3.4.2.tar.gz+tar zxf libressl-3.8.3.tar.gz
 </code> </code>
 and then build it: and then build it:
 <code> <code>
-cd libressl-3.4.2+cd libressl-3.8.3
 ./configure --enable-libtls-only ./configure --enable-libtls-only
 make make
Line 156: Line 215:
 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 **/usr/local/lib** like this: 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 **/usr/local/lib** like this:
 <code> <code>
--rw-r--r--  1 root root  27392794 Jan 20 15:17 libtls.a +-rw-r--r--  1 root root      923 Mar 20 00:02 libtls.la 
--rw-r--r--  1 root root       933 Jan 20 15:17 libtls.la +lrwxrwxrwx  1 root root       16 Mar 20 00:02 libtls.so -> libtls.so.28.0.0 
-lrwxrwxrwx  1 root root        16 Jan 20 15:17 libtls.so -> libtls.so.22.0.0 +lrwxrwxrwx  1 root root       16 Mar 20 00:02 libtls.so.28 -> libtls.so.28.0.0 
-lrwxrwxrwx  1 root root        16 Jan 20 15:17 libtls.so.22 -> libtls.so.22.0.0 +-rw-r--r--  1 root root  9108376 Mar 20 00:02 libtls.so.28.0.0
--rw-r--r--  1 root root  13146784 Jan 20 15:17 libtls.so.22.0.0+
 </code> </code>
 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** and **rsync**.+Next we need to get some packages that **rpki-client** needs. These are **libssl-dev****rsync** and **zlib1g-dev**.
 <code> <code>
-sudo apt install libssl-dev rsync+sudo apt install libssl-dev rsync zlib1g-dev
 </code> </code>
  
 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://github.com/rpki-client/rpki-client-portable| Github]] repository: Easiest is just to install **rpki-client** from the [[https://github.com/rpki-client/rpki-client-portable| Github]] repository:
Line 220: Line 280:
 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 GoRTR here though it is no longer maintained by Cloudflare as the maintainer has moved on to pastures newAll development work is now being carried out on [[rpki#stayrtr|StayRTR]] which is a hard fork of GoRTR.+===== StayRTR ===== 
 + 
 +StayRTR is a hard fork of GoRTR (which is no longer maintained by Cloudflare and is badly out of date). For this reason, I **strongly** recommend you use StayRTR rather than GoRTR. If you have an existing GoRTR install, simply replace it with StayRTR. 
 + 
 +StayRTR has now been packaged and is available as part of the Ubuntu 22.04 distribution. However, the packaged version is old (version 0.3.0). At the time of writing, the current release of StayRTR is version 0.5.1(47). I'm not going to upgrade production system to interim Ubuntu releases just to get a slightly newer (and still out of date) version of StayRTR.
  
 +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://go.dev/doc/install|https://go.dev/doc/install]], and I've reproduced the key pieces here to make it easy for installers. First you will need a working Go environment. Full instructions are at [[https://go.dev/doc/install|https://go.dev/doc/install]], and I've reproduced the key pieces here to make it easy for installers.
  
-First off, download the latest Go package (1.18.1 at time of writing):+First off, download the latest Go package (1.22.1 at time of writing):
 <code> <code>
-wget https://go.dev/dl/go1.18.1.linux-amd64.tar.gz+wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz
 </code> </code>
 If you have an existing Go environment, perhaps save it in case something goes wrong with the new version: If you have an existing Go environment, perhaps save it in case something goes wrong with the new version:
Line 240: Line 305:
 cd /usr/local cd /usr/local
 sudo chmod 777 . sudo chmod 777 .
-tar xzf ~/go1.18.1.linux-amd64.tar.gz+tar xzf ~/go1.22.1.linux-amd64.tar.gz
 sudo chmod 755 . sudo chmod 755 .
 </code> </code>
Line 257: Line 322:
 If the version shows what you installed, you are set! If the version shows what you installed, you are set!
  
-==== Installing GoRTR ==== +==== Building StayRTR ====
- +
-Easiest way to do this is to build from the [[https://github.com/cloudflare/gortr|Github repo]].  +
- +
-**Note1**: You could download and use the provided [[https://github.com/cloudflare/gortr/releases|binaries]] if you wish. +
- +
-**Note2**: You could even download the [[https://packages.debian.org/sid/amd64/gortr|Debian]] package if you wish, and install that. It needs the **adduser** package, and a **libc** from 2.4 onwards (most modern Ubuntu releases). Bonus with the .deb package is that it comes with a **systemd** configuration. +
- +
-But we will focus on building from the source. +
-<code> +
-git clone https://github.com/cloudflare/gortr.git +
-cd gortr +
-make build-gortr build-rtrmon build-rtrdump +
-</code> +
-which builds **gortr** as well as **rtrmon** and **rtrdump** (the latter used for testing purposes). +
- +
-Copy the resulting binaries to **/usr/local/bin**: +
-<code> +
-cd dist +
-sudo -s +
-cp -p gortr-v0.14.7-1-g2125744-linux-x86_64 /usr/local/bin/gortr +
-cp -p rtrdump-v0.14.7-1-g2125744-linux-x86_64 /usr/local/bin/rtrdump +
-cp -p rtrmon-v0.14.7-1-g2125744-linux-x86_64 /usr/local/bin/rtrmon +
-</code> +
- +
-GoRTR has lots of options, but the ones we need are these: +
-<code> +
- -bind string +
-    Bind address (default ":8282"+
- -cache string +
-    URL of the cached JSON data (default "https://rpki.cloudflare.com/rpki.json"+
- -checktime +
-    Check if file is still valid (default true) +
- -verify +
-        Check signature using provided public key (disable by passing -verify=false) +
-</code> +
-We don't need to use the Cloudflare JSON source, given we have our own from the newly created RPKI-client. RPKI-client doesn't insert a timestamp in the way that GoRTR wants, nor is there a signature on it, so we need to disable that too. +
- +
-We run GoRTR like this: +
-<code> +
-/usr/local/bin/gortr -bind :3323 -verify=false -cache /var/db/rpki-client/json -checktime=false +
-</code> +
-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: +
-<code> +
-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:33094, refresh:3600, retry:600, expire:7200) +
-</code> +
-And if you check the ports that are listening (**ss -an**) you will see: +
-<code> +
-tcp    LISTEN           128          *:3323              *:* +
-tcp    LISTEN           128          *:8080              *:* +
-</code> +
-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): +
-<code> +
-sudo groupadd _gortr +
-sudo useradd –g _gortr –s /sbin/nologin –d /nonexistent –c "GoRTR user" _gortr +
-</code> +
-Next we create a file **/etc/default/gortr** with the following contents: +
-<code> +
-# Settings for GoRTR. Consult https://github.com/cloudflare/gortr for +
-# more discussion and other available options +
- +
-STAYRTR_ARGS=-bind :3323 -verify=false -cache /var/db/rpki-client/json -checktime=false +
-+
-</code> +
-Then we go to the **/lib/systemd/system/** folder and create the **systemd** entry - call it **gortr.service**. Here is a simple one that should work: +
-<code> +
-[Unit] +
-Description=GoRTR RPKI to Router Server +
-Documentation=https://github.com/cloudflare/gortr +
-After=network.target +
- +
-[Service] +
-EnvironmentFile=/etc/default/gortr +
-ExecStart=/usr/local/bin/gortr $GORTR_ARGS +
-Type=exec +
-User=_gortr +
-Group=_gortr +
-AmbientCapabilities=CAP_NET_BIND_SERVICE +
-CapabilityBoundingSet=CAP_NET_BIND_SERVICE +
- +
-[Install] +
-WantedBy=multi-user.target +
-</code> +
-We then need to enable it: +
-<code> +
-sudo systemctl enable gortr +
-</code> +
-which then displays: +
-<code> +
-Created symlink /etc/systemd/system/multi-user.target.wants/gortr.service → /lib/systemd/system/gortr.service. +
-</code> +
-and then we can run GoRTR, like this: +
-<code> +
-sudo systemctl start gortr +
-</code> +
-Once it is running, check that it is working by running: +
-<code> +
-sudo systemctl status gortr +
-</code> +
-and you should see something like this: +
-<code> +
-* gortr.service - GoRTR RPKI to Router Server +
-     Loaded: loaded (/lib/systemd/system/gortr.service; enabled; vendor preset: e +
-     Active: active (running) since Fri 2022-01-28 15:52:17 AEST; 25s ago +
-       Docs: https://github.com/cloudflare/gortr   Main PID: 17490 (gortr) +
-      Tasks: 11 (limit: 4915)     Memory: 221.1M +
-     CGroup: /system.slice/gortr.service +
-             └─17490 /usr/local/bin/stayrtr -bind :3323 -verify=false -cache /var +
-Jan 28 15:52:27 gortr systemd[1]: Starting StayRTR RPKI to Router Server... +
-Jan 28 15:52:27 gortr systemd[1]: Started StayRTR RPKI to Router Server. +
-Jan 28 15:52:27 gortr gortr[17490]: time="2022-01-28T15:52:27+10:00" level=info m +
-Jan 28 15:52:28 gortr gortr[17490]: time="2022-01-28T15:52:28+10:00" level=info m +
-Jan 28 15:52:29 gortr gortr[17490]: time="2022-01-28T15:52:29+10:00" level=info m +
-Jan 28 15:52:29 gortr gortr[17490]: time="2022-01-28T15:52:29+10:00" level=info m +
-</code> +
-and you can also run the more traditional **ps ax** to see something like: +
-<code> +
-17490 ?        Ssl    0:04 /usr/local/bin/gortr -bind :3323 -verify=false -cache /var/db/rpki-client/json -checktime=false +
-</code> +
- +
-And that's it. Enjoy your new GoRTR installation. +
- +
-===== StayRTR ===== +
- +
-StayRTR is a hard fork of [[rpki#gortr|GoRTR]] which is no longer maintained by Cloudflare. For this reason, I recommend you use StayRTR rather than GoRTR. +
- +
-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://packages.debian.org/sid/stayrtr|.deb package]] by Marco d'Itri, but that needs at least Ubuntu 21.04 to support it, as it requires a libc which is 2.32 or newer (Ubuntu 20.04 uses libc version 2.31).  +
- +
-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#installing_go|instructions]] in the GoRTR section above.+
  
 Easiest way to install StayRTR is build from the [[https://github.com/bgp/stayrtr|Github repo]]. Easiest way to install StayRTR is build from the [[https://github.com/bgp/stayrtr|Github repo]].
Line 403: Line 332:
 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 **/usr/local/bin** (note if you have GoRTR installed too, as I do, you may want to rename its **rtrdump** and **rtrmon** binaries appropriately):+Copy the resulting binaries to **/usr/local/bin**:
 <code> <code>
 cd dist cd dist
-sudo cp -p stayrtr-0.1-91-gc4ac625-linux-x86_64 /usr/local/bin/stayrtr +sudo cp -p stayrtr-v0.5.1-47-gfebec67-linux-x86_64 /usr/local/bin/stayrtr 
-sudo cp -p rtrdump-0.1-91-gc4ac625-linux-x86_64 /usr/local/bin/rtrdump +sudo cp -p rtrdump-v0.5.1-47-gfebec67-linux-x86_64 /usr/local/bin/rtrdump 
-sudo cp -p rtrmon-0.1-91-gc4ac625-linux-x86_64 /usr/local/bin/rtrmon+sudo cp -p rtrmon-v0.5.1-47-gfebec67-linux-x86_64 /usr/local/bin/rtrmon
 </code> </code>
  
Line 510: Line 439:
  
 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 =====
Line 517: Line 447:
 Most commentary is for IOS-XE 16.x onwards. IOS 15.5S (and IOS-XE equivalent) will also likely work with the following examples, but their RPKI implementation is somewhat old and buggy. Most commentary is for IOS-XE 16.x onwards. IOS 15.5S (and IOS-XE equivalent) will also likely work with the following examples, but their RPKI implementation is somewhat old and buggy.
  
-==== Configuration ====+==== Configuration with Validator ====
  
 Setting up a Cisco router to talk with a validator is simple: Setting up a Cisco router to talk with a validator is simple:
Line 535: Line 465:
 show ip bgp rpki servers show ip bgp rpki servers
 </code> </code>
 +
 ==== Caveats ==== ==== Caveats ====
  
Line 546: Line 477:
 To turn off the automatic dropping of invalids: To turn off the automatic dropping of invalids:
 <code> <code>
-bgp bestpath prefix-validate allow-invalid+router bgp <ASN> 
 + bgp bestpath prefix-validate allow-invalid
 </code> </code>
- 
 To propagate the validation state in IBGP, both BGP speakers need: To propagate the validation state in IBGP, both BGP speakers need:
 <code> <code>
 neighbor x.x.x.x announce rpki state neighbor x.x.x.x announce rpki state
 </code> </code>
-Please do NOT do this, as there are too many operational consequences, especially if validators become unreachable.+Please do **NOT** do this, as there are operational consequences, especially if validators become unreachable (specifically that IOS-XE has added an undocumented feature in the path selection process whereby a prefix marked as //valid// from one IBGP neighbour is preferred over //invalid/////notfound// from another IBGP neighbour regardless of //local-preference// setting).
  
-**Summary:** Cisco has tried to make it easy to deploy ROV, but unfortunately this is counter to standards and best practices as the OS has taken control away from the operator about what they can and cannot do.+**Summary:** Cisco has tried to make it easy to deploy ROV, but unfortunately this "assistance" ignores standards and best practices. Any implementation must never take control away from the operator about what they can and cannot do, especially if there is no way of turning off mis-features.
  
 +==== Implementing Route Origin Validation ====
 +
 +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.
 +<code>
 +router bgp <ASN>
 + no bgp bestpath prefix-validate allow-invalid
 +</code>
  
 ===== Juniper Hints ===== ===== Juniper Hints =====
Line 564: Line 502:
 ==== 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:
  
 <code> <code>
Line 570: Line 508:
   validation {   validation {
     group ISP {     group ISP {
-      session <ip address>; +      /* validatorA */ 
-      port <port>; +      session <ip address validatorA
-      refresh-time 600; +        refresh-time 600
-      hold-time 3600;+        hold-time 3600; 
 +        preference 1; 
 +        port <port>; 
 +        local-address <router loopback>; 
 +      
 +      /* validatorB */ 
 +      session <ip address validatorB>
 +        refresh-time 600; 
 +        hold-time 3600; 
 +        preference 2; 
 +        port <port>; 
 +        local-address <router loopback>; 
 +      }
     }     }
   }   }
Line 579: Line 529:
 </code> </code>
 where <ip address> is the IP address (IPv4 or IPv6) of the validator, <port> is the TCP port the validator listens on, and 3600 is the RFC8210 recommended refresh interval (the period which the router will use to ask the validator if there is new/updated validation information available). where <ip address> is the IP address (IPv4 or IPv6) of the validator, <port> is the TCP port the validator listens on, and 3600 is the RFC8210 recommended refresh interval (the period which the router will use to ask the validator if there is new/updated validation information available).
 +
 +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 652: Line 604:
 ==== Implementing Route Origin Validation ==== ==== Implementing Route Origin Validation ====
  
-The final step in JunOS is to implement Route Origin Validation. This again needs a policy statement, to be applied as //outbound// policy on all BGP sessions (internal and external).+The final step in JunOS is to implement Route Origin Validation. This is can be simply achieved by replacing the:
 <code> <code>
-to be done+next policy
 </code> </code>
 +line in the INVALID term with:
 +<code>
 +reject
 +</code>
 +
 +This will discard invalid prefixes as they arrive on an EBGP speaking router. If you want to find out what has been dropped, you can run:
 +<code>
 +show route protocol bgp validation invalid hidden
 +</code>
 +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.+This section shows the basic configuration needed to get route origin validation up and running on a [[https://bird.network.cz/|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.14 at time of writing).
  
 ==== Configuration with Validator ==== ==== Configuration with Validator ====
Line 672: Line 634:
     roa6 { table rpki6; };     roa6 { table rpki6; };
     remote <ip address1> port <port1>;     remote <ip address1> port <port1>;
-    retry 300;+    retry keep 600; 
 +    refresh keep 3600; 
 +    expire keep 7200;
 } }
  
Line 679: Line 643:
     roa6 { table rpki6; };     roa6 { table rpki6; };
     remote <ip address2> port <port2>;     remote <ip address2> port <port2>;
-    retry 300;+    retry keep 600; 
 +    refresh keep 3600; 
 +    expire keep 7200;
 } }
  
Line 769: Line 735:
 ==== Implementing Route Origin Validation ==== ==== Implementing Route Origin Validation ====
  
-The final step in FRR is to implement Route Origin Validation. This needs a policy statement, to be applied as //outbound// policy on all BGP sessions (internal and external).+The final step in FRR is to implement Route Origin Validation. This needs a policy statement, to be applied as //outbound// policy on all BGP sessions (internal and external). The following example shows a route-map exporting IPv4 routes. Similar can be done for IPv6.
 <code> <code>
-to be done+route-map EXPORT deny 5 
 + description Don't send RPKI Invalids 
 + match rpki invalid 
 +exit 
 +
 +route-map EXPORT deny 15 
 + description Drop the IPv4 bogons 
 + match ip address prefix-list v4bogon 
 +exit 
 +
 +route-map EXPORT permit 20 
 + description Everything else is good 
 +exit 
 +!
 </code> </code>
  
hints/rpki.1653196907.txt.gz · Last modified: 2022/05/22 15:21 by philip