hints:rpki
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
hints:rpki [2022/05/22 14:58] – [Configuration with Validator] philip | hints:rpki [2024/03/20 22:24] – [RPKI-client] 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# | ||
Line 15: | Line 18: | ||
* [[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 28: | ||
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.13.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:// |
+ | </ | ||
+ | |||
+ | Then run: | ||
+ | |||
+ | < | ||
+ | wget -qO- https:// | ||
+ | </ | ||
+ | |||
+ | And then finally: | ||
+ | |||
+ | < | ||
+ | apt-get update | ||
+ | apt install routinator | ||
</ | </ | ||
Easy! | Easy! | ||
+ | |||
+ | The installer will set up the necessary **systemd** file so that Routinator starts automatically on boot. Remember to modify the **/ | ||
+ | < | ||
+ | repository-dir = "/ | ||
+ | rtr-listen = [" | ||
+ | http-listen = [" | ||
+ | </ | ||
+ | |||
+ | 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 " | ||
+ | < | ||
+ | [Service] | ||
+ | ExecStart= | ||
+ | ExecStart=/ | ||
+ | </ | ||
+ | where the **/ | ||
+ | < | ||
+ | repository-dir = "/ | ||
+ | extra-tals-dir = "/ | ||
+ | rtr-listen = [" | ||
+ | http-listen = [" | ||
+ | </ | ||
+ | |||
+ | |||
===== FORT ===== | ===== FORT ===== | ||
- | FORT is not quite so easy to install, but still relatively simple as long as you follow | + | 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), so 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.1-1_amd64.deb |
</ | </ | ||
Line 127: | Line 169: | ||
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 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/ | 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.4.2.tar.gz | + | tar zxf libressl-3.8.3.tar.gz |
</ | </ | ||
and then build it: | and then build it: | ||
< | < | ||
- | 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 **/ | 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-- |
- | -rw-r--r-- | + | lrwxrwxrwx |
- | lrwxrwxrwx | + | lrwxrwxrwx |
- | lrwxrwxrwx | + | -rw-r--r-- |
- | -rw-r--r-- | + | |
</ | </ | ||
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 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 | + | ===== StayRTR ===== |
+ | |||
+ | StayRTR is a hard fork of [[rpki# | ||
+ | |||
+ | 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.18.1 at time of writing): | + | First off, download the latest Go package (1.22.1 at time of writing): |
< | < | ||
- | wget https:// | + | wget https:// |
</ | </ | ||
If you have an existing Go environment, | If you have an existing Go environment, | ||
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 . | ||
</ | </ | ||
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 |
- | + | ||
- | 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 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 **/ | + | Copy the resulting binaries to **/ |
< | < | ||
cd dist | cd dist | ||
- | sudo cp -p stayrtr-0.1-91-gc4ac625-linux-x86_64 / | + | sudo cp -p stayrtr-v0.5.1-47-gfebec67-linux-x86_64 / |
- | sudo cp -p rtrdump-0.1-91-gc4ac625-linux-x86_64 / | + | sudo cp -p rtrdump-v0.5.1-47-gfebec67-linux-x86_64 / |
- | sudo cp -p rtrmon-0.1-91-gc4ac625-linux-x86_64 / | + | sudo cp -p rtrmon-v0.5.1-47-gfebec67-linux-x86_64 / |
</ | </ | ||
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 |
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 | ||
</ | </ | ||
+ | |||
==== Caveats ==== | ==== Caveats ==== | ||
Line 546: | Line 477: | ||
To turn off the automatic dropping of invalids: | To turn off the automatic dropping of invalids: | ||
< | < | ||
- | bgp bestpath prefix-validate allow-invalid | + | router bgp < |
+ | bgp bestpath prefix-validate allow-invalid | ||
</ | </ | ||
- | |||
To propagate the validation state in IBGP, both BGP speakers need: | To propagate the validation state in IBGP, both BGP speakers need: | ||
< | < | ||
neighbor x.x.x.x announce rpki state | neighbor x.x.x.x announce rpki state | ||
</ | </ | ||
- | Please do NOT do this, as there are too many operational consequences, | + | Please do **NOT** do this, as there are operational consequences, |
- | **Summary: | + | **Summary: |
+ | ==== 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. | ||
+ | < | ||
+ | router bgp <ASN> | ||
+ | no bgp bestpath prefix-validate allow-invalid | ||
+ | </ | ||
===== 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: |
< | < | ||
Line 570: | Line 508: | ||
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 579: | Line 529: | ||
</ | </ | ||
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 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 applies as // | + | The final step in JunOS is to implement Route Origin Validation. This is can be simply achieved by replacing the: |
< | < | ||
- | to be done | + | next policy |
</ | </ | ||
+ | line in the INVALID term with: | ||
+ | < | ||
+ | reject | ||
+ | </ | ||
+ | |||
+ | 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: | ||
+ | < | ||
+ | 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. | + | This section shows the basic configuration needed to get route origin validation up and running on a [[https:// |
+ | ==== Configuration with Validator ==== | ||
+ | The configuration needed for BIRD to talk with a validator is: | ||
+ | |||
+ | < | ||
+ | roa4 table r4; | ||
+ | roa6 table r6; | ||
+ | |||
+ | protocol rpki validator1 { | ||
+ | roa4 { table rpki4; }; | ||
+ | roa6 { table rpki6; }; | ||
+ | remote <ip address1> | ||
+ | retry keep 600; | ||
+ | refresh keep 3600; | ||
+ | expire keep 7200; | ||
+ | } | ||
+ | |||
+ | protocol rpki validator2 { | ||
+ | roa4 { table rpki4; }; | ||
+ | roa6 { table rpki6; }; | ||
+ | remote <ip address2> | ||
+ | retry keep 600; | ||
+ | refresh keep 3600; | ||
+ | expire keep 7200; | ||
+ | } | ||
+ | |||
+ | </ | ||
+ | where <ip address> is the IP address (IPv4 or IPv6) of the validator, < | ||
+ | |||
+ | This simply creates a validation database in BIRD - it does not touch the BGP RIB. To find out what is in the validation database (IPv4 and IPv6 shown): | ||
+ | < | ||
+ | show route table rpki4 | ||
+ | show route table rpki6 | ||
+ | </ | ||
+ | and to find out the status of the connection to // | ||
+ | < | ||
+ | show protocols validator1 | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Implementing Route Origin Validation ==== | ||
+ | |||
+ | The final step in BIRD is to implement Route Origin Validation. This needs a policy statement, to be applied as // | ||
+ | < | ||
+ | # v4 function to check if prefix valid | ||
+ | function is_v4_rpki_invalid () { | ||
+ | return roa_check(rpki4, | ||
+ | } | ||
+ | |||
+ | # v6 function to check if prefix valid | ||
+ | function is_v6_rpki_invalid () { | ||
+ | return roa_check(rpki6, | ||
+ | } | ||
+ | |||
+ | # return true if invalid, false if not | ||
+ | function prefix_is_invalid() | ||
+ | { | ||
+ | if net.type = NET_IP4 then | ||
+ | if is_v4_rpki_invalid() then return true; | ||
+ | if net.type = NET_IP6 then | ||
+ | if is_v6_rpki_invalid() then return true; | ||
+ | return false; | ||
+ | } | ||
+ | </ | ||
+ | And then the // | ||
+ | < | ||
+ | filter EXPORT | ||
+ | { | ||
+ | if (prefix_is_bogon()) then reject " | ||
+ | if (prefix_is_invalid()) then reject " | ||
+ | if (as_path_contains_bogons()) then reject " | ||
+ | if (bgp_path.len > 32) then reject " | ||
+ | if (bgp_path.len < 1) then reject " | ||
+ | accept " | ||
+ | } | ||
+ | </ | ||
===== FRrouting Hints ===== | ===== FRrouting Hints ===== | ||
- | This section shows the basic configuration needed to get route origin validation up and running on implementations using FRrouting (FRR). | + | This section shows the basic configuration needed to get route origin validation up and running on implementations using FRrouting (FRR). The commentary below assumes FRR 8.2.2. Older versions of FRR (8.1 and 7.5) have slightly different CLI and may not have all the features shown here. |
==== Configuration with Validator ==== | ==== Configuration with Validator ==== | ||
Line 690: | Line 727: | ||
show bgp | show bgp | ||
</ | </ | ||
- | commands. To show prefixes that meet any of the validation states: | + | command set. To show prefixes that meet any of the validation states: |
< | < | ||
show bgp rpki valid | show bgp rpki valid | ||
Line 696: | Line 733: | ||
will show all the entries that are //valid//. There is also a command option for //invalid// and // | will show all the entries that are //valid//. There is also a command option for //invalid// and // | ||
+ | ==== Implementing Route Origin Validation ==== | ||
+ | |||
+ | The final step in FRR is to implement Route Origin Validation. This needs a policy statement, to be applied as // | ||
+ | < | ||
+ | route-map EXPORT deny 5 | ||
+ | | ||
+ | match rpki invalid | ||
+ | exit | ||
+ | ! | ||
+ | route-map EXPORT deny 15 | ||
+ | | ||
+ | match ip address prefix-list v4bogon | ||
+ | exit | ||
+ | ! | ||
+ | route-map EXPORT permit 20 | ||
+ | | ||
+ | exit | ||
+ | ! | ||
+ | </ | ||
[[start| Back to Home page]] | [[start| Back to Home page]] | ||
hints/rpki.txt · Last modified: 2024/03/20 22:24 by philip