This guide describes a simple configuration for OpenBGPD running on OpenBSD. The portable version should run with little to no configuration changes on other operating systems as well.

Setup

Only IPv6 is used for the sake of simplicity. Neighbors use ULA addresses (/127 transfer net) assigned from one of the peer’s allocation.

The goal is to have a small, yet complete setup for all peers with ROA validation and other safety measurements in place.

Configuration

/etc/bgpd.conf contains all information and may include further (automatically generated) files, as is done in this guide.

As per the manual, configuration is divided into logical sections; /etc/examples/bgpd.conf is a complete and commented example which this guide is roughly based on.

By default, bgpd(8) listens on all local addresses (on the current default routing domain), but this guide explicitly listens on the configured transfer ULA only for each peer to better illustrate of this setup.

local host

Information such as ASN, router ID and allocated networks are required:

# macros
ASN="4242421234"

# global configuration
AS $ASN
router-id 1.2.3.4

prefix-set mynetworks {
        fd00:12:34::/48
}

These can be used in subsequent filter rules. The local peer’s announcements is then defined as follows:

# Generate routes for the networks our ASN will originate.
# The communities (read 'tags') are later used to match on what
# is announced to EBGP neighbors
network prefix-set mynetworks set large-community $ASN:1:1

neighbors

For each neighbor its ASN and transfer ULA is required. An optional description is provided such that bgpctl(8) for example can be used with mnemonic names instead of AS numbers:

# peer A, transport over IPSec/GRE
$A_local="fd00:12:34:A::1"
$A_remote="fd00:12:34:A::2"
$A_ASN="4242425678"

listen on $A_local

neighbor  $A_remote {
    remote-as $A_ASN
    descr "A"
}

filter rules

bgpd blocks all BGP UPDATE messages by default. The filter rules are evaluated in sequential order, form first to last. The last matching allow or deny rule decides what action is taken.

Start off with basic protection and sanity rules:

# deny more-specifics of our own originated prefixes
deny quick from ebgp prefix-set mynetworks or-longer

# filter out too long paths, establish more peerings instead
deny quick from any max-as-len 8

quick rules are considered the last matching rule, and evaluation of subsequent rules is skipped.

Allow own announcements:

# Outbound EBGP: only allow self originated networks to ebgp peers
# Don't leak any routes from upstream or peering sessions. This is done
# by checking for routes that are tagged with the large-community $ASN:1:1
allow to ebgp prefix-set mynetworks large-community $ASN:1:1

Allow all remaining UPDATES based on Origin Validation States:

# enforce ROA
allow from ebgp ovs valid

Note how the ovs filter requires the roa-set {...} to be defined; see the ROA section below.

path attributes

Besides allow and deny statements, filter rules can modify UPDATE messages, e.g.

# Scrub normal and large communities relevant to our ASN from EBGP neighbors
# https://tools.ietf.org/html/rfc7454#section-11
match from ebgp set { large-community delete $ASN:*:* }

# Honor requests to gracefully shutdown BGP sessions
# https://tools.ietf.org/html/rfc8326
match from any community GRACEFUL_SHUTDOWN set { localpref 0 }

ROA

An roa-set can be generated from the registry directly or you can use the following pre-build tables.

One single roa-set may be defined, against which bgpd will validate the origin of each prefix; this allows filter rules to use the ovs keyword as demonstrated above.

ROA files generated by dn42regsrv are available from burble.dn42:

/etc/dn42.roa-set is the generated set:

roa-set {
    fd00:12:34::/48 source-as 4242421234
    fd00:ab:cd::/44 maxlen 64 source-as 4242427890
    ...
}

Include it in /etc/bgpd.conf:

# defines roat-set, see _rpki-client crontab
include "/etc/dn42.roa-set"

Looking glass

This is mostly OpenBSD specific since bgplg(8) and httpd(8) ship as part of the operating system. The bgplg manual contains the few steps and example httpd.conf(5) required to enable the looking glass.

See https://t4-2.high5.nl/bgplg for a running instance operating within DN42.