These notes were made by the operator of AS205163 (IPv6-only at the time of writing) and will be updated over time. This guide assumes basic knowledge of how BGP works and the terminology associated with this protocol. Some of the notes are only applicable to non-profit / personal AS-es, as commercial ones have to play according to different rules.

Try https://dn42.eu if you just want to learn & experiment with low risk & no cost.

ASN Management

  • Keep your PeeringDB profile up to date
    • Do NOT use “RIPE::” or any other prefix before your as-set on PeeringDB, as this may cause filter generation issues (IXPManager with bgpq3)
    • 3 essential email addresses: peering, abuse and NOC. You may add a general contact email as well
  • Organization address may be shortened to postal code with a city upon obtaining the ASN (if you are registering as an individual for non-commercial use, with PA space)
  • (mp-)import / (mp-)export attributes are usually used for AS ownership verification and documentation, rather than prefix filters. Most important for the latter part is an up-to-date as-set in PeeringDB
  • bgp.tools shows as-name in the connection graph, but org-name when you search for an ASN
  • bgp.tools provides monitoring features (including alerts) for free if you flag your ASN as personal

Prefixes

  • Proper filtering (min. length, RPKI, [IRR])

  • Exact IRR route object preferred (bgpq3 / bgpq4 generate exact match filters by default)

    • Add them ASAP for all the upstream filters to be updated before you start announcing
    • Depending on transit provider manual filter update on other side may be required. In most cases your new IRR record will fully propagate within 72h

  • Learn how one of the largest providers performs prefix filter updates: https://routing.he.net/algorithm.html

  • Add geofeed to all subnets

    • GeoIP information update may take months, certain providers may need to be contacted for a manual update
    • “google does geoip/dbs based on actual routing a lot of the time”

  • Anycast prefixes should have the same AS PATH length to all connected Tier 1 providers for proper routing

Peering

  • FogIXP, ONIX, FREMIX, NVIX are the most affordable IXPs (for beginners)

  • Virtual IXPs (e.g. BGP.Exchange, 4IXP) have the lowest joining requirements, can provide some visible peers at bgp.tools, are however relatively unstable and introduce traffic latency if connected via a tunnel

  • General IXP Rules (read their ToS carefully):

    • Only send own & downstream prefixes
    • No multicast / broadcast traffic
    • No IP / MAC spoofing
    • No ARP / NDP for IPs outside of IXP LAN
    • No ICMPv6 RA / RS
    • No default routes to IXP members unless peering and explicitly allowed by them
    • No MITM attack attempts

  • Disable rp_filter, arp, multicast, redirects, RA/RS on IXP ports and enable IP forwarding (sysctl.conf)

  • (Preferably) do not do eBGP over tunnels. This does not benefit the Internet

  • There are lots of free IPv6 transit providers for non-commercial use (see IPv6 discord). The largest one - Hurricane Electric (AS6939)

    • Peering with HE at any common IXP is very fast and straightforward - contact peering@he.net with a kind request for free IPv6 transit
    • Hurricane Electric, despite being IPv6 Tier 1 provider, isn’t peering with Cogent (AS174) due to a decade-long dispute. In case either of them is your single provider, you won’t be able to reach the other one’s customers unless they are connected to your provider as well

  • General policies (always validate routes!!!):

    • Downstreams: highest local preference, export all routes (own, peers [and transit]) and / or default route
    • Peers: slightly lower local preference, export own & downstream routes
    • Route servers: slightly lower local preference, export own & downstream routes
    • Transit providers: lowest local preference, export own [& downstream, depending on agreement] routes

  • Save peering time (till session establishment) with the following actions:

    • Add an import / export statement for the peer in advance
    • Specify the following details in your message:
      • Your name, ASN and PeeringDB profile
      • Peering location and IP
      • Prefixes to be announced (you can specify more general and more specific ones)
        • Ask them if they have automatic filter updates (otherwise you’d have to contact them for each new announced one)
      • Peering intentions (research/non-profit etc.)
      • Ask for free transit (if the provider offers one)
        • Specify if you want to get full table and / or default routes

  • bgp.tools peers = peers that announce your prefixes in IXPs and a route collector spots them / peers that export all their routes to route collector without announcing them

    • The most reliable source of your peer count is your own server. However, peering with bgp.tools route collector wasn’t possible for free plans at the time of writing

Software

BGP & Routing

This part mostly focuses on bird2 routing daemon, but some of the tips are applicable to all tools

  • BGP daemon comparison: https://www.youtube.com/watch?v=w_WXichTpYw (TLDW here)
  • 512MB VM isn’t enough for full IPv6 table with kernel export. However, it can handle this task with enough SWAP
  • RPKI Validators (e.g. Routinator) are very CPU intensive. You may use a central validator and fetch data via RTR / JSON (e.g. using rtrtr) on the edge nodes
  • Make sure to assign your announced router IP (krt_prefsrc) to any of the interfaces (e.g. lo)
    • Wireguard ignores krt_prefsrc if it’s not assigned to the tunnel
  • Use bird2 for stability (bird3 may crash periodically, as of October 2025)
  • Prepend self a maximum of 3 times
  • Define static routes to each hop in a multihop configuration
  • reject route inside static protocol is an alias of unreachable. The route will be exported to the specified table (master by default) as being “unreachable”
  • Exporting static unreachable routes into kernel is suggested for machines with a default route (to prevent routing loops)
  • Define an export prefix limit (export limit <N> action block). Just in case you mess up
  • BGP prefix filtering will not protect from downstream source IP spoofing - make sure to apply the filters to firewall as well
  • You BGP software will filter out the routes you announce from another PoP (Point of Presence, server location). The default behavior of BGP is to reject routes with own ASN in its path, prefer iBGP for internal route exchange instead
  • [IPv4 and IPv6 dual-stack] Prefer MP-BGP (Multiprotocol BGP) with ENH (extended next hop) to reduce BGP session & peering IP count
  • birdc quick reference:
    • c [soft] - Reload configuration [ignoring filter changes]
    • reload [in/out] <PROT_NAME> - Reload [input/output] filters for a given protocol
    • s p a [<SESSION_NAME>] - Show detailed info on all [or specific] BGP sessions (including imported / exported routes)
      • X imported, Y exported, Z preferred, where X is number of accepted routes (filters passed), Y is the number of exported routes, Z is the number of optimal routes based on BGP route selection algorithm (local preference, AS path…) that can be exported to other protocols (e.g. kernel)
    • s r for <IP>/<SUBNET> [all] - Show route to given IP / subnet [with details]
    • s r export <PROT_NAME> [count] - Show exported routes to protocol with PROT_NAME [or their count]
  • ip quick reference:
    • ip r s - All IPv4 routes
    • ip r -6 s - All IPv6 routes (same applies to further commands)
    • ip r s dev wg0 - All IPv4 routes on interface wg0
    • ip r s proto bird - All IPv4 routes exported to kernel by BIRD
    • ip r g 1.1.1.1 - Get route (interface) to host
    • ip -6 n g fe80::3739:bb71:c29:51bf dev wg0 - Get neighbour MAC on interface

Monitoring

  • Tailscale for interconnects between PoP-s
  • Akvorado for flow collection & analysis, SNMP & hsflowd as providers on edge nodes
  • Packetvis (= public BGPAlerter instance with a Web-UI) & https://bgp.tools for anomaly detection
  • Looking glass to be added

Troubleshooting

A route isn’t fully visible after more than 72h

Make sure you have appropriate RPKI / IRR route object for it (in case of automatic filtering), or that your provider manually added it to a whitelist (in case of manual filtering). Check local looking glass (can be found on PeeringDB for you transit AS) and / or various super looking glasses for your prefix

Route marked as “unreachable” after export to kernel from a multihop peer

Make sure you have defined a full static route to that peer in your routing software

Ping echo request sent successfully, echo reply wasn’t received (short time after announcement start)

Make sure that you received it on the other end (tcpdump icmp6). If not, your packet may have been blocked by an upstream (prefix has not yet been accepted / source IP blocked by firewall). If a reply was sent out but hasn’t reached the source, the route may not have propagated globally yet (again, prefix filters)

“BGP: Unexpected connect from unknown address XXX” in bird logs

If the listed address doesn’t match your peer’s one, they may have multiple routers present on the IXP and expect you to connect to a specific one (see PeeringDB). If the address is the same as in your config, they may expect other source IP from you (e.g. IXP IP instead of the one assigned by your VM provider)

“Automatic RPKI reload not active for import” in bird logs

Make sure to enable the import table with import table on. Otherwise you would have to wait for a repeated announcement from peer to accept their prefix upon RPKI reload (instead of re-checking all observed routes in the import table)

Note: enabling the import table will re-import all the routes from the provider

SNMP interface details not available to Akvorado

Make sure to export all OIDs (in snmpd.conf), rather that the default systemonly view