Reference ASN: AS 6589  ·  Platforms: Cisco IOS-XE & Juniper JunOS  ·  PTR Naming: Rozint Standard  ·  Aligned with MANRS, RFC 7454, RFC 7999, RFC 8092, RFC 8326

1. Introduction

The Border Gateway Protocol is the protocol that holds the internet together. Every route you take across the global internet, every packet that reaches a server on another continent, passes through BGP decisions made by tens of thousands of autonomous systems. And yet, despite being the backbone of all inter domain routing, BGP was designed in an era of implicit trust. It has no built in mechanism to verify that a route announcement is legitimate, that the AS originating a prefix actually has the right to do so or that the AS path it carries has not been tampered with.

This fundamental trust model means that a single misconfiguration, whether accidental or malicious, can have cascading consequences. In April 2018, a BGP hijack redirected traffic destined for Amazon's Route 53 DNS service through a Russian hosted network, enabling attackers to steal approximately $150,000 in cryptocurrency from MyEtherWallet users. In June 2019, a small ISP in Pennsylvania accidentally became a transit provider for most of the internet after leaking over 20,000 prefixes it learned from a transit provider to another transit provider, causing widespread congestion. In October 2021, Facebook's own BGP misconfiguration withdrew all their routes simultaneously, making not just Facebook but also Instagram, WhatsApp and Oculus unreachable for over six hours.

Route leaks and hijacks happen every day, most of them small enough that they only affect a handful of networks and go largely unnoticed. The difference between a well run network and a dangerous one is the set of practices its operators put in place to prevent these events from happening and to minimize their blast radius when they inevitably do.

This guide is a comprehensive walkthrough of every major BGP best practice that a network operator should implement. It is written for the operator who is building out a new network or the engineer who has inherited an existing one and wants to bring it up to modern standards. Each section explains why it matters, what real world incident motivates it and what the relevant standards say. Configuration examples are provided for Cisco IOS-XE and Juniper JunOS. Both IPv4 and IPv6 are treated as first-class citizens throughout every section, because in 2025 a network that does not fully support IPv6 is an incomplete network. The reference ASN used throughout is AS 6589 and all infrastructure naming follows the Rozint PTR Naming Standard.

2. Infrastructure Naming and PTR Records

Before a BGP session is configured, the foundation of an operationally excellent network begins with consistent naming. When a customer runs a traceroute and sees 15 anonymous IP addresses, they learn nothing. When they see hostnames like ae0.edge1-eq-nyc-us.as6589.net, they immediately know they are traversing an aggregated Ethernet interface on an edge router in Equinix New York. This transparency builds trust, simplifies troubleshooting across organizational boundaries and is a hallmark of a professionally run network.

2a. Why Naming Matters

Consistent PTR records serve multiple operational purposes. They make traceroutes human-readable, which is critical when your NOC is diagnosing a path issue at 3 AM. They allow external operators to quickly identify which of your routers is involved in a peering or transit issue without having to cross-reference IP allocations manually. And they provide geographic context, which matters enormously when diagnosing latency problems or verifying traffic is taking the expected path.

The Rozint PTR Naming Standard provides a clean, scalable convention. The general syntax for device hostnames is:

{NAME}-[FACILITY]-{CITY}-{COUNTRY}

City codes follow the UN/LOCODE standard and country codes use ISO 3166-1-alpha-2. This avoids the ambiguity of ad-hoc abbreviations. For example, "IAD" unambiguously refers to the Washington/Ashburn metro area, "NYC" to New York and "AMS" to Amsterdam.

2b. PTR Record Syntax

Full PTR records extend the device name with interface and domain information:

[CIRCUIT].[INTERFACE].{NAME}-[FACILITY]-{CITY}-{COUNTRY}.{DOMAIN}.{TLD}

Interface abbreviations are standardized: et# for Ethernet, lo# for loopback, ae# for aggregated Ethernet (Juniper LAG terminology), lag# for vendor agnostic LAG references and vlan# for VLAN interfaces. A traceroute hop that reads vlan100.edge2-nik-ams-nl.as6589.net instantly tells you this is the VLAN 100 interface on the second edge router at Nikhef in Amsterdam.

2c. Dual-Stack PTR Records

Every interface that participates in BGP should have both forward (A/AAAA) and reverse (PTR) records configured for both IPv4 and IPv6 addresses. This is especially important for IPv6, where raw addresses like 2001:db8:abcd::1 are effectively unreadable in traceroutes. A PTR record transforms that address into lo0.core1-iad-us.as6589.net, providing the same operational clarity that IPv4 PTRs have offered for decades.

For ip6.arpa reverse zones, ensure your RIR delegation is correctly configured. Many operators neglect IPv6 reverse DNS because the zone files are more complex (each /48 generates a much deeper delegation tree than a /24). Modern DNS automation tools handle this well and the operational payoff is significant.

2d. TXT Geolocation Records

For networks with many points of presence, TXT records on hostnames can provide machine readable geolocation data. The format is:

FACILITY-ID|CITY|COUNTRY|LATITUDE,LONGITUDE

The facility ID corresponds to the PeeringDB facility identifier, enabling automated tools to correlate your router hostnames with physical facility data.

2e. Looking Glass Naming

Looking glasses should follow the convention lg-{CITY}-{COUNTRY}.{DOMAIN}.{TLD}, for example lg-iad-us.as6589.net. A critical operational note: the looking glass hostname must resolve to an IP within your own network. Placing it behind a reverse proxy like Cloudflare defeats the purpose, as operators trying to diagnose routing issues need to be able to traceroute to the looking glass itself and see it terminate within your AS.

3. BGP Session Setup and Security

A BGP session is a TCP connection, typically on port 179, between two routers that have been explicitly configured to peer with each other. The security and resilience of this session is the foundation upon which everything else is built. A session that goes down unexpectedly causes route withdrawal, which can trigger traffic shifts, convergence events and in the worst case, reachability loss. A session that is hijacked or spoofed can inject malicious routes. Every production BGP session should be hardened with multiple layers of protection and this applies equally to IPv4 and IPv6 sessions.

3a. Dual-Stack Session Architecture

The first design decision is how to structure your dual-stack BGP sessions. There are two common approaches: running separate BGP sessions for IPv4 and IPv6 (one session per address family, each using its respective transport), or running a single session that carries both address families using Multi Protocol BGP (MP-BGP) extensions.

The separate session approach is simpler to reason about and debug: if your IPv6 session goes down, IPv4 routing is unaffected. The MP-BGP approach is more efficient (one TCP session instead of two) but ties the fate of both address families together. Most modern ISP deployments use separate sessions for eBGP because the operational isolation is worth the small additional configuration overhead. For iBGP, MP-BGP over a single session (typically transported over IPv4 loopbacks) is common because iBGP sessions are fully under your control.

Regardless of approach, the critical principle is: IPv6 is not optional and it is not an afterthought. Every filtering policy, every community schema, every RPKI check and every blackhole mechanism described in this guide must be implemented for both address families with equal rigor.

3b. MD5 Authentication

RFC 2385 defines the TCP MD5 signature option, which adds a keyed hash to every TCP segment in the BGP session. While MD5 is cryptographically weak by modern standards, its purpose here is not to protect against sophisticated attackers but to prevent casual spoofing and accidental session establishment. Without MD5 authentication, an attacker who can spoof the source IP of your peer can potentially establish a BGP session and inject routes.

The stronger alternative is TCP-AO (RFC 5925), which supports modern hash algorithms and key rotation. However, vendor support for TCP-AO in BGP remains uneven as of 2025, so MD5 remains the practical standard. The key takeaway is that every eBGP session should have authentication enabled.

Cisco IOS-XE:

! IPv4 peer
neighbor 198.51.100.17 password 7 <MD5-HASH>
! IPv6 peer
neighbor 2001:db8:174::1 password 7 <MD5-HASH>

Juniper JunOS:

/* Applied at the group or neighbor level - covers both AFIs */
authentication-key "<MD5-KEY>";

3c. TTL Security (GTSM)

The Generalized TTL Security Mechanism (GTSM), defined in RFC 5082, is one of the simplest and most effective protections for directly connected eBGP sessions. The idea is elegant: when two routers are directly connected, the IP TTL on packets between them should be 255. An attacker sending spoofed BGP packets from elsewhere on the internet would need those packets to traverse multiple hops, decrementing the TTL. GTSM configures the receiving router to discard any BGP packets with a TTL below a threshold, which means spoofed packets from remote attackers are silently dropped before they ever reach the BGP process. This is equally important for IPv6 sessions, where the hop limit field serves the same role as TTL.

Cisco IOS-XE:

neighbor 198.51.100.17 ttl-security hops 1
neighbor 2001:db8:174::1 ttl-security hops 1

Juniper JunOS:

ttl 1;   /* Applies to both IPv4 and IPv6 within the group */

GTSM should not be used for multihop eBGP sessions (such as route server peering at IXPs) because the TTL will naturally be lower. Only enable it for directly connected peers, for both address families.

3d. Bidirectional Forwarding Detection (BFD)

BGP's default hold timer is 90 seconds with keepalives every 30 seconds, which means that if a link fails silently, it can take up to 90 seconds before the BGP session drops and routes are withdrawn. For a transit carrying network, 90 seconds of blackholing traffic is catastrophic.

BFD (RFC 5880) solves this by running a lightweight, sub second detection protocol alongside BGP. BFD packets are exchanged every few hundred milliseconds and if a configurable number of consecutive packets are missed (typically 3), BFD declares the link down and immediately notifies BGP. This brings failover time from tens of seconds down to under one second.

Cisco IOS-XE:

neighbor 198.51.100.17 fall-over bfd
neighbor 2001:db8:174::1 fall-over bfd

Juniper JunOS:

bfd-liveness-detection {
    minimum-interval 300;  /* 300ms */
    multiplier 3;          /* ~900ms detection */
}

3e. Maximum Prefix Limits

Every eBGP session should have a maximum prefix limit configured. This is your circuit breaker. If a peer suddenly starts sending you 10 million prefixes when you expect 50,000, something has gone catastrophically wrong on their end. Without a maximum prefix limit, your router will happily accept all of those routes, potentially exhausting its memory and crashing.

As of 2025, the global IPv4 routing table contains approximately 950,000 prefixes and the IPv6 table approximately 200,000. These numbers grow steadily, so build in headroom. For customer sessions, the limit should reflect their actual allocation size plus a small buffer. The key point for IPv6: the table is smaller but growing faster than IPv4 and many operators under provision their IPv6 limits because they treat it as secondary. Do not make this mistake.

Cisco IOS-XE:

! IPv4 transit: warn at 90%, restart after 15 min
neighbor 198.51.100.17 maximum-prefix 950000 90 restart 15
!
! IPv6 transit: same logic, IPv6 table size
neighbor 2001:db8:174::1 maximum-prefix 200000 90 restart 15

Juniper JunOS:

family inet {
    unicast {
        prefix-limit {
            maximum 950000;
            teardown 90 idle-timeout 15;
        }
    }
}
family inet6 {
    unicast {
        prefix-limit {
            maximum 200000;
            teardown 90 idle-timeout 15;
        }
    }
}

3f. Graceful Restart

When a router's BGP process restarts due to a software upgrade, process crash, or configuration change, the default behavior is to tear down all BGP sessions, withdraw all routes and then re establish sessions and relearn the full routing table. This process can take minutes, during which traffic is disrupted.

Graceful Restart (RFC 4724) addresses this by allowing the restarting router to signal its peers to keep its routes in their forwarding table for a negotiated period while the BGP process restarts. The peer marks these routes as stale but continues forwarding traffic based on them.

Long lived Graceful Restart (LLGR, RFC 9494) extends this concept further, allowing stale routes to persist for hours or even days at a reduced preference. This is particularly useful for iBGP sessions where a route reflector restart should not cause a network wide reconvergence event.

Cisco IOS-XE:

router bgp 6589
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360

Juniper JunOS:

routing-options {
    graceful-restart;
}

3g. Graceful Shutdown (RFC 8326)

Graceful Shutdown is the complement to Graceful Restart, but for planned maintenance rather than unplanned restarts. When you need to take a BGP session down for maintenance, you want traffic to drain away from that path before you pull the plug. Without this, tearing down a session causes an abrupt route withdrawal and traffic on that path is blackholed until the network converges on an alternate route.

RFC 8326 defines the GRACEFUL_SHUTDOWN well known community (65535:0). When applied to routes, it signals to all routers in the network that these routes are about to be withdrawn. Each router that receives a route with this community should set its local preference to 0, making it the least preferred path. Traffic naturally shifts to alternate paths and when you finally tear down the session, there is no traffic to disrupt.

The critical implementation detail is that every router in your network must honor this community on import for both IPv4 and IPv6 routes. If even one router ignores it, traffic will continue flowing through the draining path.

Cisco IOS-XE:

! On ALL routers: honor GSHUT on import for both AFIs
ip community-list standard GSHUT permit 65535:0
!
route-map IMPORT-V4 permit 5
 match community GSHUT
 set local-preference 0
!
route-map IMPORT-V6 permit 5
 match community GSHUT
 set local-preference 0

Juniper JunOS:

community GRACEFUL_SHUTDOWN members 65535:0;
policy-statement HONOR-GSHUT {
    term gshut {
        from community GRACEFUL_SHUTDOWN;
        then {
            local-preference 0;
            accept;
        }
    }
}

3h. Full Dual-Stack eBGP Session Example

Bringing all of the above together, here is a complete transit session configuration for AS 174 (Cogent) with full IPv4 and IPv6 support, all security hardening applied, on edge1-eq-nyc-us:

Cisco IOS-XE:

router bgp 6589
 bgp router-id 198.51.100.1
 bgp log-neighbor-changes
 bgp graceful-restart
 no bgp default ipv4-unicast
 timers bgp 10 30
 !
 ! --- IPv4 Transit: Cogent ---
 neighbor 198.51.100.17 remote-as 174
 neighbor 198.51.100.17 description Transit-Cogent-v4-ae0.edge1-eq-nyc-us
 neighbor 198.51.100.17 password 7 <MD5-HASH>
 neighbor 198.51.100.17 ttl-security hops 1
 neighbor 198.51.100.17 fall-over bfd
 !
 ! --- IPv6 Transit: Cogent ---
 neighbor 2001:db8:174::1 remote-as 174
 neighbor 2001:db8:174::1 description Transit-Cogent-v6-ae0.edge1-eq-nyc-us
 neighbor 2001:db8:174::1 password 7 <MD5-HASH>
 neighbor 2001:db8:174::1 ttl-security hops 1
 neighbor 2001:db8:174::1 fall-over bfd
 !
 address-family ipv4 unicast
  neighbor 198.51.100.17 activate
  neighbor 198.51.100.17 send-community both
  neighbor 198.51.100.17 route-map TRANSIT-COGENT-V4-IN in
  neighbor 198.51.100.17 route-map TRANSIT-COGENT-V4-OUT out
  neighbor 198.51.100.17 maximum-prefix 950000 90 restart 15
  neighbor 198.51.100.17 soft-reconfiguration inbound
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 2001:db8:174::1 activate
  neighbor 2001:db8:174::1 send-community both
  neighbor 2001:db8:174::1 route-map TRANSIT-COGENT-V6-IN in
  neighbor 2001:db8:174::1 route-map TRANSIT-COGENT-V6-OUT out
  neighbor 2001:db8:174::1 maximum-prefix 200000 90 restart 15
  neighbor 2001:db8:174::1 soft-reconfiguration inbound
 exit-address-family

Juniper JunOS:

protocols {
    bgp {
        group TRANSIT-COGENT {
            type external;
            peer-as 174;
            hold-time 30;
            log-updown;
            authentication-key "<MD5-KEY>";
            ttl 1;
            bfd-liveness-detection {
                minimum-interval 300;
                multiplier 3;
            }
            family inet {
                unicast {
                    prefix-limit {
                        maximum 950000;
                        teardown 90 idle-timeout 15;
                    }
                }
            }
            family inet6 {
                unicast {
                    prefix-limit {
                        maximum 200000;
                        teardown 90 idle-timeout 15;
                    }
                }
            }
            import [ REJECT-BOGONS-V4 REJECT-BOGONS-V6 TRANSIT-IMPORT ];
            export TRANSIT-EXPORT;
            neighbor 198.51.100.17 {
                description "Transit-Cogent-v4-ae0.edge1-eq-nyc-us";
            }
            neighbor 2001:db8:174::1 {
                description "Transit-Cogent-v6-ae0.edge1-eq-nyc-us";
            }
        }
    }
}

4. Route Filtering and Prefix Validation

If session security is the foundation, route filtering is the walls. A BGP router that accepts all routes from all peers without validation is a liability to itself and to the entire internet. Filtering must be applied identically to both IPv4 and IPv6 address families. Historically, many operators applied rigorous IPv4 filtering but left their IPv6 sessions wide open because "IPv6 is still small" or "nobody attacks IPv6 yet." This is dangerously false. IPv6 route hijacks and leaks are just as real and just as damaging as their IPv4 counterparts and the IPv6 routing table's smaller size makes individual hijacks proportionally more impactful.

4a. IPv4 Bogon Prefix Filtering

Bogon prefixes are IP address ranges that should never appear in the global routing table. These include RFC 1918 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), the shared address space for carrier grade NAT (100.64.0.0/10), loopback (127.0.0.0/8), link-local (169.254.0.0/16), IETF protocol assignments (192.0.0.0/24), benchmarking (198.18.0.0/15) and multicast/reserved ranges (224.0.0.0/3, 240.0.0.0/4).

If you accept a bogon prefix from a peer, you are allowing that peer to hijack traffic destined for addresses that are used internally on millions of networks worldwide. This is not theoretical. If a peer accidentally announces 10.0.0.0/8, your router may start trying to send traffic destined for 10.x.x.x addresses toward that peer instead of keeping it on your internal network.

Bogon filtering must be applied on every external BGP session, both transit and peering, without exception.

Cisco IOS-XE:

ip prefix-list BOGON-V4 seq 5 deny 0.0.0.0/8 le 32
ip prefix-list BOGON-V4 seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGON-V4 seq 15 deny 100.64.0.0/10 le 32
ip prefix-list BOGON-V4 seq 20 deny 127.0.0.0/8 le 32
ip prefix-list BOGON-V4 seq 25 deny 169.254.0.0/16 le 32
ip prefix-list BOGON-V4 seq 30 deny 172.16.0.0/12 le 32
ip prefix-list BOGON-V4 seq 35 deny 192.0.0.0/24 le 32
ip prefix-list BOGON-V4 seq 40 deny 192.0.2.0/24 le 32
ip prefix-list BOGON-V4 seq 45 deny 192.168.0.0/16 le 32
ip prefix-list BOGON-V4 seq 50 deny 198.18.0.0/15 le 32
ip prefix-list BOGON-V4 seq 55 deny 198.51.100.0/24 le 32
ip prefix-list BOGON-V4 seq 60 deny 203.0.113.0/24 le 32
ip prefix-list BOGON-V4 seq 65 deny 224.0.0.0/3 le 32
ip prefix-list BOGON-V4 seq 70 deny 240.0.0.0/4 le 32

4b. IPv6 Bogon Prefix Filtering

The IPv6 bogon list is just as critical. It includes the default and loopback (::/8 covers ::/128 and ::1/128), the discard prefix (100::/64, RFC 6666), benchmarking (2001:2::/48), ORCHID (2001:10::/28), documentation (2001:db8::/32), the deprecated 6to4 relay (2002::/16), the deprecated 6bone (3ffe::/16), unique local addresses (fc00::/7), link-local (fe80::/10), the deprecated site-local (fec0::/10) and multicast (ff00::/8). Many operators forget 2002::/16 (6to4) and 3ffe::/16 (6bone) because these protocols are long dead, but their address space still occasionally appears in BGP due to stale configurations.

Cisco IOS-XE:

ipv6 prefix-list BOGON-V6 seq 5 deny ::/8 le 128
ipv6 prefix-list BOGON-V6 seq 10 deny 100::/64 le 128
ipv6 prefix-list BOGON-V6 seq 15 deny 2001:2::/48 le 128
ipv6 prefix-list BOGON-V6 seq 20 deny 2001:10::/28 le 128
ipv6 prefix-list BOGON-V6 seq 25 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGON-V6 seq 30 deny 2002::/16 le 128
ipv6 prefix-list BOGON-V6 seq 35 deny 3ffe::/16 le 128
ipv6 prefix-list BOGON-V6 seq 40 deny fc00::/7 le 128
ipv6 prefix-list BOGON-V6 seq 45 deny fe80::/10 le 128
ipv6 prefix-list BOGON-V6 seq 50 deny fec0::/10 le 128
ipv6 prefix-list BOGON-V6 seq 55 deny ff00::/8 le 128

Juniper JunOS (both address families):

policy-options {
    prefix-list BOGON-V4 {
        0.0.0.0/8; 10.0.0.0/8; 100.64.0.0/10;
        127.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12;
        192.0.0.0/24; 192.0.2.0/24; 192.168.0.0/16;
        198.18.0.0/15; 198.51.100.0/24; 203.0.113.0/24;
        224.0.0.0/3; 240.0.0.0/4;
    }
    prefix-list BOGON-V6 {
        ::/8; 100::/64; 2001:2::/48;
        2001:10::/28; 2001:db8::/32; 2002::/16;
        3ffe::/16; fc00::/7; fe80::/10;
        fec0::/10; ff00::/8;
    }
    policy-statement REJECT-BOGONS {
        term v4-bogons {
            from {
                family inet;
                prefix-list BOGON-V4;
            }
            then reject;
        }
        term v6-bogons {
            from {
                family inet6;
                prefix-list BOGON-V6;
            }
            then reject;
        }
    }
}

4c. Prefix Length Filtering

Even if a prefix is not a bogon, it may be too specific or too broad to belong in the global routing table. For IPv4, the convention is to accept /8 through /24 only. For IPv6, the convention is /16 through /48. Anything more specific was historically unroutable and, while this is changing with certain CDN and anycast deployments, accepting /128s or /64s from a transit peer would be unusual and likely indicates a misconfiguration. On the broad end, you should never accept anything shorter than /8 (IPv4) or /16 (IPv6) unless you explicitly want a default route.

Cisco IOS-XE:

! IPv4: accept /8 through /24
ip prefix-list PREFIX-LEN-V4 permit 0.0.0.0/0 ge 8 le 24
!
! IPv6: accept /16 through /48
ipv6 prefix-list PREFIX-LEN-V6 permit ::/0 ge 16 le 48

Juniper JunOS:

policy-statement REJECT-INVALID-LEN {
    term v4-too-specific {
        from {
            family inet;
            route-filter 0.0.0.0/0 prefix-length-range /25-/32;
        }
        then reject;
    }
    term v6-too-specific {
        from {
            family inet6;
            route-filter ::/0 prefix-length-range /49-/128;
        }
        then reject;
    }
}

4d. AS Path Filtering

The AS path attribute records the sequence of autonomous systems a route has traversed. Just as certain prefixes should never appear in the global table, certain ASNs should never appear in an AS path. These include AS 0 (reserved), AS 23456 (the AS_TRANS value used during the 2-byte to 4-byte ASN transition per RFC 6793), documentation ASNs (64496-64511), 16-bit private ASNs (64512-65534) and 32-bit private ASNs (4200000000-4294967294).

Cisco IOS-XE:

ip as-path access-list 10 deny _0_
ip as-path access-list 10 deny _23456_
ip as-path access-list 10 deny _[64496-64511]_
ip as-path access-list 10 deny _[64512-65534]_
ip as-path access-list 10 deny _65535_
ip as-path access-list 10 deny _[4200000000-4294967294]_
ip as-path access-list 10 permit .*

Juniper JunOS:

as-path BOGON-ASNS ".*(0|23456|[64496-64511]|[64512-65534]|65535|[4200000000-4294967294]).*";
policy-statement REJECT-BOGON-ASNS {
    term bogon-asn {
        from as-path BOGON-ASNS;
        then reject;
    }
}

4e. IRR Based Filtering for Customers

Customer sessions require the strictest filtering: only accept prefixes documented in the Internet Routing Registry. The tool bgpq4 generates prefix lists from IRR data for both IPv4 and IPv6:

# IPv4 prefix-list for customer AS 65001
bgpq4 -4 -l CUST-65001-V4 AS65001

# IPv6 prefix-list for customer AS 65001
bgpq4 -6 -l CUST-65001-V6 AS65001

Regenerate these filters nightly via cron. For IPv6, ensure customers have registered route6 objects in the IRR, not just route objects. A surprising number of operators register their IPv4 prefixes but forget to register their IPv6 allocations, which causes their IPv6 routes to be filtered by well run peers and transit providers.

4f. Filtering Your Own Prefixes

You should always reject your own prefixes when received from any external peer. If you accept your own routes back from a peer, you create a routing loop. This happens more often than you might think, particularly when a customer or peer has a misconfiguration and reannounces routes they learned from you.

4g. Complete Dual-Stack Import Policy

A proper import policy chains all filters in order: bogon prefixes, bogon ASNs, own prefixes, default route, prefix length, RPKI invalids, RPKI valids (elevated local-pref), then accept remainder. This chain must exist separately for both IPv4 and IPv6.

Cisco IOS-XE (IPv6 import route-map):

route-map TRANSIT-V6-IN deny 10
 description "Reject IPv6 bogons"
 match ipv6 address prefix-list BOGON-V6
!
route-map TRANSIT-V6-IN deny 20
 description "Reject bogon ASNs"
 match as-path 10
!
route-map TRANSIT-V6-IN deny 30
 description "Reject our own IPv6 prefixes"
 match ipv6 address prefix-list OUR-V6-PREFIXES
!
route-map TRANSIT-V6-IN deny 40
 description "Reject default route"
 match ipv6 address prefix-list DEFAULT-V6
!
route-map TRANSIT-V6-IN deny 50
 description "Reject RPKI Invalid"
 match rpki invalid
!
route-map TRANSIT-V6-IN permit 60
 description "RPKI Valid - elevated preference"
 match rpki valid
 set local-preference 200
 set community 6589:100 6589:1100 additive
!
route-map TRANSIT-V6-IN permit 70
 description "RPKI Not Found - standard preference"
 match rpki not-found
 set local-preference 100
 set community 6589:100 6589:1000 additive
!
ipv6 prefix-list OUR-V6-PREFIXES permit 2001:db8:abcd::/48
ipv6 prefix-list DEFAULT-V6 permit ::/0

5. BGP Community Signaling

BGP communities are perhaps the most powerful and underutilized feature available to network operators. They transform BGP from a simple reachability protocol into a rich policy signaling framework. A community is a tag attached to a route that carries no routing information itself but signals intent to any router that knows how to interpret it.

5a. The Three Types of Communities

Standard communities (RFC 1997) are 32-bit values conventionally written as two 16-bit integers separated by a colon, such as 6589:100.

Extended communities (RFC 4360) are 64-bit values primarily used in MPLS VPN and EVPN environments.

Large communities (RFC 8092) are 96-bit values written as three 32-bit integers, such as (6589, 100, 174). They were designed explicitly to solve the 32-bit ASN problem and to provide a structured, hierarchical namespace. For any network running a 32-bit ASN, large communities should be the primary community type.

5b. Designing a Community Schema

A well designed community schema serves two purposes: it provides operational visibility through informational communities and it enables customers and internal engineers to control routing behavior through action communities.

Informational Communities

Informational communities tag routes with metadata about where and how they were learned. They do not change routing behavior but are invaluable for troubleshooting.

Action Communities

Action communities instruct your routers to modify how a route is treated or announced. These are the communities your customers will use for traffic engineering.

Large communities enable per peer granularity that is impossible with standard communities alone. A customer can say "prepend twice to Cogent (AS 174) but not to Lumen (AS 3356)" by attaching (6589, 201, 174).

5c. Processing Communities in Export Policies

The community schema only works if your export policies actually process the communities and act on them. Every export route-map must include terms that check for no-announce communities, prepend communities and blackhole communities before the route is sent to a peer. Check for no announce first to avoid prepending a route you are about to suppress, then apply prepending, then strip internal communities before the route leaves your network.

6. Downstream and Customer Support

Customer sessions require the strictest filtering of any peer type. A customer re-announcing the full table they learned from you is a route leak that could make you an accidental transit provider for the entire internet. Every customer session must have explicit IPv4 and IPv6 prefix-lists, AS-path validation, RPKI checks and tight maximum prefix limits for both address families.

6a. Dual-Stack Customer Session

Example: Customer AS 65001 with IPv4 allocation 203.0.113.128/25 and IPv6 allocation 2001:db8:cust::/48.

Cisco IOS-XE:

router bgp 6589
 !
 ! --- IPv4 Customer Session ---
 neighbor 192.0.2.2 remote-as 65001
 neighbor 192.0.2.2 description Customer-ExampleCorp-v4-vlan200.edge2-nik-ams-nl
 neighbor 192.0.2.2 password 7 <MD5-HASH>
 neighbor 192.0.2.2 ttl-security hops 1
 neighbor 192.0.2.2 fall-over bfd
 !
 ! --- IPv6 Customer Session ---
 neighbor 2001:db8:link::2 remote-as 65001
 neighbor 2001:db8:link::2 description Customer-ExampleCorp-v6-vlan200.edge2-nik-ams-nl
 neighbor 2001:db8:link::2 password 7 <MD5-HASH>
 neighbor 2001:db8:link::2 ttl-security hops 1
 neighbor 2001:db8:link::2 fall-over bfd
 !
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 send-community both
  neighbor 192.0.2.2 prefix-list CUST-65001-V4 in
  neighbor 192.0.2.2 route-map CUSTOMER-65001-V4-IN in
  neighbor 192.0.2.2 maximum-prefix 10 90 restart 15
  neighbor 192.0.2.2 default-originate
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 2001:db8:link::2 activate
  neighbor 2001:db8:link::2 send-community both
  neighbor 2001:db8:link::2 prefix-list CUST-65001-V6 in
  neighbor 2001:db8:link::2 route-map CUSTOMER-65001-V6-IN in
  neighbor 2001:db8:link::2 maximum-prefix 5 90 restart 15
  neighbor 2001:db8:link::2 default-originate
 exit-address-family
!
! --- IPv4 IRR prefix filter ---
ip prefix-list CUST-65001-V4 permit 203.0.113.128/25
ip prefix-list CUST-65001-V4 permit 203.0.113.128/26
ip prefix-list CUST-65001-V4 permit 203.0.113.192/26
!
! --- IPv6 IRR prefix filter ---
ipv6 prefix-list CUST-65001-V6 permit 2001:db8:cust::/48
ipv6 prefix-list CUST-65001-V6 permit 2001:db8:cust::/47 le 48

Juniper JunOS:

group CUSTOMER-65001 {
    type external;
    peer-as 65001;
    hold-time 30;
    authentication-key "<MD5-KEY>";
    bfd-liveness-detection {
        minimum-interval 300;
        multiplier 3;
    }
    family inet {
        unicast {
            prefix-limit { maximum 10; teardown 90; }
        }
    }
    family inet6 {
        unicast {
            prefix-limit { maximum 5; teardown 90; }
        }
    }
    import CUSTOMER-65001-IMPORT;
    export CUSTOMER-65001-EXPORT;
    neighbor 192.0.2.2 {
        description "Customer-v4-vlan200.edge2-nik-ams-nl";
    }
    neighbor 2001:db8:link::2 {
        description "Customer-v6-vlan200.edge2-nik-ams-nl";
    }
}

6b. Local Preference for Customer Routes

Customer routes should always have the highest local preference in your network after blackhole routes. This follows the fundamental business logic of internet routing: you always prefer to send traffic toward paying customers rather than toward peers or transit providers.

6c. Default Route Advertisement

Most customers will want to receive a default route (0.0.0.0/0) from you and many will want only a default route rather than the full routing table. The default-originate feature on Cisco or a static default export policy on Juniper sends a default route to the customer regardless of whether one exists in your own routing table. This should be a per customer configuration decision.

6d. Customer Traffic Engineering Communities

A good transit provider empowers its customers with community based traffic engineering. At minimum, you should support prepending, selective no announce and blackholing. Your community schema should be publicly documented on your website and in PeeringDB so that customers can use it without needing to contact your NOC.

7. IXP and Peering Support

Internet Exchange Points are the glue of the peering ecosystem. By connecting to an IXP, a network can establish BGP sessions with dozens or hundreds of other networks through a single physical connection. Most major IXPs operate fully dual stack and your peering sessions should always include both IPv4 and IPv6 address families. Many of the most desirable peers (such as Google, Cloudflare and Netflix) are reachable only via IPv6 at some exchanges, so an IPv4 only IXP configuration leaves significant traffic on the table.

7a. Route Server Peering

Route servers redistribute routes from all participating networks. You configure a single session and receive routes from everyone who peers with it. Your import policy should apply identical bogon, AS-path and RPKI filtering to route server sessions as to any other external peer, for both address families. Note that IXP route servers typically do not support MD5 authentication and GTSM should not be used because the route server may not be directly connected at layer 3.

Cisco IOS-XE (AMS-IX RS, AS 6777):

! IPv4 route server session
neighbor 80.249.208.1 remote-as 6777
neighbor 80.249.208.1 description IXP-RS-AMSIX-v4-vlan100.edge2-nik-ams-nl
neighbor 80.249.208.1 maximum-prefix 300000 90 restart 15
!
! IPv6 route server session
neighbor 2001:7f8:1::a500:6777:1 remote-as 6777
neighbor 2001:7f8:1::a500:6777:1 description IXP-RS-AMSIX-v6-vlan100.edge2-nik-ams-nl
neighbor 2001:7f8:1::a500:6777:1 maximum-prefix 100000 90 restart 15
!
address-family ipv4 unicast
 neighbor 80.249.208.1 activate
 neighbor 80.249.208.1 route-map IXP-RS-V4-IN in
 neighbor 80.249.208.1 route-map IXP-RS-OUT out
exit-address-family
!
address-family ipv6 unicast
 neighbor 2001:7f8:1::a500:6777:1 activate
 neighbor 2001:7f8:1::a500:6777:1 route-map IXP-RS-V6-IN in
 neighbor 2001:7f8:1::a500:6777:1 route-map IXP-RS-V6-OUT out
exit-address-family

7b. Bilateral Peering

Bilateral peering is a direct BGP session between you and another network at the IXP, bypassing the route server. This is preferred for high traffic peers because it gives you more control: you can negotiate MD5 authentication, apply peer specific filtering and use BFD. Many large networks like Cloudflare, Google and Netflix prefer bilateral peering and may not even participate in route servers.

7c. IXP Export Policy

At an IXP, whether through the route server or bilateral peers, you should only announce your own prefixes and your customers prefixes. This is the cardinal rule of peering. Announcing transit learned routes to a peer violates the implicit contract of settlement free peering and could make you an unpaid transit provider.

8. Blackhole and RTBH Support

Remotely Triggered Black Hole (RTBH) routing is the network operator's emergency stop button for DDoS attacks. When a destination IP address is under volumetric attack, the attack traffic consumes bandwidth on every link it traverses before reaching the target. RTBH solves this by injecting a BGP route that causes all routers in the network to drop traffic destined for the attacked IP at the network edge.

8a. How RTBH Works

A /32 host route (or /128 for IPv6) is injected into BGP with a special next-hop that points to a null interface. The route is tagged with the blackhole community and given a very high local preference (typically 500) to ensure it overrides any legitimate route for that IP. When this route propagates across the network's iBGP mesh, every router installs a /32 pointing to null and all traffic to that IP is silently dropped at ingress.

The critical constraint is that blackhole routes must be /32 or /128. Accepting a blackhole for a /24 would be far too disruptive.

8b. Customer Triggered Blackhole (IPv4 and IPv6)

Allowing customers to trigger blackholes themselves enables sub-second DDoS mitigation without NOC involvement. The customer announces the attacked IP as a /32 or /128 with the blackhole community and your import policy validates it falls within their allocation.

Cisco IOS-XE:

! Null routes for blackhole next-hops
ip route 192.0.2.66 255.255.255.255 Null0
ipv6 route 100::66/128 Null0
!
! IPv4 blackhole: /32 only within customer allocation
ip prefix-list CUST-65001-BH-V4 permit 203.0.113.128/25 ge 32 le 32
!
! IPv6 blackhole: /128 only within customer allocation
ipv6 prefix-list CUST-65001-BH-V6 permit 2001:db8:cust::/48 ge 128 le 128
!
! IPv4 customer blackhole import
route-map CUSTOMER-65001-V4-IN permit 5
 match community BLACKHOLE
 match ip address prefix-list CUST-65001-BH-V4
 set ip next-hop 192.0.2.66
 set local-preference 500
 set community 6589:666 65535:666 no-export additive
!
! IPv6 customer blackhole import
route-map CUSTOMER-65001-V6-IN permit 5
 match community BLACKHOLE
 match ipv6 address prefix-list CUST-65001-BH-V6
 set ipv6 next-hop 100::66
 set local-preference 500
 set community 6589:666 65535:666 no-export additive

Juniper JunOS:

routing-options {
    static {
        route 192.0.2.66/32 discard;     /* IPv4 blackhole NH */
        route 100::66/128 discard;        /* IPv6 blackhole NH */
    }
}
policy-statement CUSTOMER-BLACKHOLE {
    term v4-blackhole {
        from {
            family inet;
            community BLACKHOLE;
            prefix-list-filter CUST-65001-V4 longer;
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then {
            local-preference 500;
            community add no-export;
            next-hop 192.0.2.66;
            accept;
        }
    }
    term v6-blackhole {
        from {
            family inet6;
            community BLACKHOLE;
            prefix-list-filter CUST-65001-V6 longer;
            route-filter ::/0 prefix-length-range /128-/128;
        }
        then {
            local-preference 500;
            community add no-export;
            next-hop 100::66;
            accept;
        }
    }
}

8c. Upstream Blackhole Signaling

When the attack is large enough that even your network's edge cannot absorb the traffic, you can signal your upstream transit providers to blackhole the attacked prefix on their side by reannouncing the blackhole /32 with the RFC 7999 community (65535:666). The trade off is significant: the attacked IP becomes completely unreachable from the entire internet. This is a last resort, not a first response.

8d. RFC 7999

RFC 7999 established 65535:666 as a globally recognized blackhole community. Best practice is to always tag blackhole routes with both your custom community and 65535:666 and to always add the no-export community to prevent the blackhole from propagating beyond your immediate upstream.

9. RPKI: Resource Public Key Infrastructure

RPKI is the single most important security technology deployed across the internet routing ecosystem in the past decade. It addresses BGP's fundamental trust problem by providing a cryptographic mechanism to verify that an AS is authorized to originate a specific prefix.

9a. How RPKI Works

The system has three components. First, the prefix holder creates a Route Origin Authorization (ROA) in their RIR's RPKI portal. The ROA states: "Prefix X may be originated by AS Y, with a maximum prefix length of /Z." This ROA is cryptographically signed using the RIR's certificate hierarchy.

Second, RPKI validators like Routinator or rpki-client download the complete set of ROAs from all five RIRs, validate the cryptographic signatures and build a Validated ROA Payload (VRP) table.

Third, the router connects to the validator using the RTR protocol (RFC 8210) and downloads the VRP table. When a BGP route is received, the router checks the route's prefix and origin AS against the VRP table and classifies it as Valid, Invalid, or Not Found.

9b. Why RPKI Matters

This works identically for IPv4 and IPv6. In fact, IPv6 RPKI coverage is actually ahead of IPv4: over 60% of IPv6 prefixes have ROAs compared to approximately 50% for IPv4. This makes RPKI validation even more effective for IPv6 routes. Major networks including Cloudflare, Google, Amazon, Microsoft, NTT, Lumen and Cogent perform Route Origin Validation and reject RPKI-invalid routes. If your prefixes do not have ROAs, you are at a disadvantage: if someone hijacks your prefix, RPKI-validating networks will prefer the hijacker's route if it is signed over your unsigned one.

9c. Deploying RPKI Validators

Run at least two RPKI validators in your network for redundancy. Routinator by NLnet Labs is the most widely deployed open source validator, written in Rust with low memory requirements.

# Install and run Routinator
apt install routinator
routinator init --accept-arin-rpa
routinator server --rtr 0.0.0.0:3323 --http 0.0.0.0:8323

9d. Router Configuration for RPKI

Cisco IOS-XE:

router bgp 6589
 ! RPKI validators serve both IPv4 and IPv6 VRPs
 bgp rpki server tcp 198.51.100.10 port 3323 refresh 600
 bgp rpki server tcp 198.51.100.11 port 3323 refresh 600
!
! Verify with:
! show bgp ipv4 unicast rpki table
! show bgp ipv6 unicast rpki table
! show bgp rpki servers

Juniper JunOS:

routing-options {
    validation {
        group RPKI-VALIDATORS {
            session 198.51.100.10 {
                port 3323;
                refresh-time 600;
                hold-time 1200;
            }
            session 198.51.100.11 {
                port 3323;
                refresh-time 600;
                hold-time 1200;
            }
        }
    }
}
/* Validation applies to both inet and inet6 routes */
/* Use: from validation-database valid/invalid/unknown */

9e. Route Origin Validation Policy

Cisco IOS-XE:

! Reject RPKI Invalid
route-map TRANSIT-IN deny 50
 match rpki invalid

! Prefer RPKI Valid
route-map TRANSIT-IN permit 60
 match rpki valid
 set local-preference 200
 set community 6589:1100 additive

! Accept RPKI Not Found at baseline
route-map TRANSIT-IN permit 70
 match rpki not-found
 set local-preference 100
 set community 6589:1000 additive

Juniper JunOS:

term reject-rpki-invalid {
    from validation-database invalid;
    then reject;
}
term prefer-rpki-valid {
    from validation-database valid;
    then {
        local-preference 200;
        community add RPKI-VALID;
        accept;
    }
}
term accept-rpki-unknown {
    from validation-database unknown;
    then {
        local-preference 100;
        community add RPKI-UNKNOWN;
        accept;
    }
}

9f. Creating Your Own ROAs

Publish ROAs for all your prefixes in your RIR's portal. This is critical for both IPv4 and IPv6. Set max-length equal to the prefix length unless you intentionally announce more-specifics. A /48 with max-length /128 is a dangerous misconfiguration: an attacker could announce any /64 within your /48 and it would pass RPKI validation. Tight max-length settings are essential for strong RPKI protection and this applies equally to your IPv6 allocations.

10. Operational Best Practices

10a. MANRS Compliance

The Mutually Agreed Norms for Routing Security (MANRS) initiative defines four actions that every network operator should implement. The four actions are: (1) Filtering, preventing the propagation of incorrect routing information. (2) Anti spoofing, implementing BCP38/BCP84 source address validation. (3) Coordination, maintaining accurate contact information in PeeringDB and RIR databases. (4) Global validation, publishing ROAs and performing Route Origin Validation.

10b. AS-Path Prepending: Use Sparingly

AS-path prepending is the most commonly used traffic engineering technique and also the most commonly misused. Prepending has diminishing returns: one or two prepends may shift traffic, but beyond three, the effect becomes negligible. Excessive prepending does nothing useful but does bloat the global routing table, increases the attack surface for AS-path manipulation and makes your routes look unstable. If three prepends don't achieve your traffic engineering goal, prepending is the wrong tool and you should use communities to adjust local preference at your upstream instead.

10c. BGP Dampening: Generally Avoid

BGP route dampening (RFC 2439) was designed to penalize unstable routes by suppressing them after repeated flaps. While the concept is sound, the default dampening parameters cause far more harm than good. Research by RIPE and Geoff Huston at APNIC demonstrated that dampening disproportionately penalizes stable routes that withdraw and reannounce once while failing to significantly reduce convergence time for genuinely unstable routes. The consensus recommendation since approximately 2013 has been to not enable BGP route dampening.

10d. Monitoring and Alerting

A BGP configuration is only as good as the monitoring that surrounds it. At minimum, your monitoring system should alert on BGP session state changes, sudden changes in received prefix count, RPKI validator reachability and new prefixes appearing from customer sessions that are not in the IRR filter.

For external visibility, participate in BGP route collector projects such as RIPE RIS and Oregon Route Views. Subscribe to alerting services like Cloudflare Radar, BGPStream, or RIPE Stat to receive notifications when your prefixes are announced by unexpected origins.

10e. PeeringDB Maintenance

PeeringDB is the directory of the internet's peering ecosystem. Ensure your ASN, network name, IRR as-set, facility listings, IXP connections, NOC contact information, peering policy and prefix limits are all current. Networks that want to peer with you will check PeeringDB first and an incomplete or outdated entry signals that you are not serious about peering.

10f. Maintenance Procedures

Every BGP maintenance event should follow a documented runbook. The minimum procedure for taking a session down should be: (1) apply graceful shutdown community to drain traffic, (2) verify traffic has shifted using monitoring, (3) perform the maintenance, (4) remove graceful shutdown and verify session reestablishment, (5) confirm prefix counts and traffic levels return to normal.

11. Quick Reference

Local Preference Ladder

500  Blackhole (highest priority, ensures null-routing)
300  Customer routes (revenue-generating, always preferred)
200  RPKI-Valid transit routes (cryptographically verified)
150  Peer / IXP routes (settlement-free, preferred over paid)
100  Transit / RPKI-Unknown (baseline)
 50  Deprioritized (community-triggered)
  0  Graceful shutdown (draining before maintenance)

Community Schema Summary

INFORMATIONAL                     ACTION
6589:100  = transit-learned       6589:666  = blackhole
6589:200  = customer-learned      65535:666 = RFC 7999 blackhole
6589:300  = peer-learned          6589:3001 = prepend x1
6589:400  = ixp-rs-learned        6589:3002 = prepend x2
6589:500  = self-originated       6589:3003 = prepend x3
6589:1001 = US-East               6589:4000 = no-announce-all
6589:1002 = US-West               6589:4100 = no-announce-transit
6589:1003 = EU-West               6589:4200 = no-announce-peers
6589:1100 = RPKI Valid            6589:4300 = no-announce-ixp
6589:1000 = RPKI Not Found

LARGE COMMUNITIES (per-peer control)
(6589, 0,   PEER_ASN) = learned from ASN
(6589, 100, PEER_ASN) = do not announce to ASN
(6589, 101, PEER_ASN) = announce only to ASN
(6589, 200, PEER_ASN) = prepend x1 to ASN
(6589, 201, PEER_ASN) = prepend x2 to ASN
(6589, 202, PEER_ASN) = prepend x3 to ASN

Maximum Prefix Guidelines (2025)

IPv6 Bogon Quick Reference

Key RFCs Referenced