Routing policy and session security
The lab works, but it is not something you would put on the internet. With no policy, R1 accepts anything R2 sends — including bogus or hijacked prefixes — and would re-advertise anything it learns to every other peer.
Production eBGP always has:
- Outbound filtering — announce exactly your own prefixes (and your customers'), nothing else.
- Inbound filtering — reject bogons, overly specific prefixes, and anything the peer is not entitled to send. For customers this is an explicit prefix list built from IRR data (e.g. with
bgpq4). - Maximum-prefix limits — a circuit breaker for leaks.
- Session protection — TCP-MD5/TCP-AO authentication and GTSM.
- RPKI Route Origin Validation — reject routes whose origin AS is not authorised by a signed ROA. In FRR this is
rpki+match rpki invalidin the route-map.
Industry baseline: the MANRS actions — filtering, anti-spoofing, coordination, global validation.
FRR policy is built from three pieces: prefix-lists match prefixes, as-path access-lists match AS_PATH regexes, and route-maps combine matches with set actions. A route-map ends with an implicit deny.
ip prefix-list OUR-PREFIXES seq 10 permit 198.51.100.0/24
!
ip prefix-list PEER-IN seq 10 deny 0.0.0.0/8 le 32
ip prefix-list PEER-IN seq 20 deny 10.0.0.0/8 le 32
ip prefix-list PEER-IN seq 30 deny 127.0.0.0/8 le 32
ip prefix-list PEER-IN seq 40 deny 172.16.0.0/12 le 32
ip prefix-list PEER-IN seq 50 deny 192.168.0.0/16 le 32
ip prefix-list PEER-IN seq 60 deny 100.64.0.0/10 le 32
ip prefix-list PEER-IN seq 70 deny 169.254.0.0/16 le 32
ip prefix-list PEER-IN seq 80 deny 0.0.0.0/0 ge 25
ip prefix-list PEER-IN seq 1000 permit 0.0.0.0/0 le 24
!
bgp as-path access-list AS64501-ONLY seq 10 permit ^64501(_64501)*$
!
route-map R2-IN permit 10
match ip address prefix-list PEER-IN
match as-path AS64501-ONLY
set local-preference 200
set community 64500:100 additive
!
route-map R2-OUT permit 10
match ip address prefix-list OUR-PREFIXES
!
router bgp 64500
bgp router-id 10.255.0.1
neighbor 192.0.2.2 remote-as 64501
neighbor 192.0.2.2 password CHANGE-ME
neighbor 192.0.2.2 ttl-security hops 1
!
address-family ipv4 unicast
network 198.51.100.0/24
neighbor 192.0.2.2 route-map R2-IN in
neighbor 192.0.2.2 route-map R2-OUT out
neighbor 192.0.2.2 maximum-prefix 1000 90
exit-address-family
!- Line 1: Exactly the prefixes we are allowed to announce. Anything else we accidentally learn will not leak outward.
- Lines 3–9: Reject private (RFC 1918), loopback and "this network" space from the peer…
- Line 10: …anything more specific than /24, which the global table conventionally filters…
- Line 11: …and permit everything else up to /24.
- Line 13: AS_PATH regex: the path must be 64501 (optionally prepended). Our peer should only send their own routes, not transit.
- Lines 15–19: Inbound policy: both matches must pass. Accepted routes get LOCAL_PREF 200 and a community tagging where we learnt them. Anything that fails hits the route-map's implicit deny.
- Lines 21–22: Outbound policy: only our own prefixes. Without this, a misconfiguration could make us a transit for our peer — a route leak.
- Lines 24–26:
no bgp ebgp-requires-policyis gone: with route-maps applied in both directions, FRR's RFC 8212 safe default is satisfied. - Line 27: TCP-MD5 authentication. Both peers must have the same key. TCP-AO (RFC 5925) is the modern replacement where supported.
- Line 28: GTSM (RFC 5082): only accept BGP packets with TTL 255, so spoofed packets from further away are dropped.
- Lines 32–33: Attach the route-maps. Policy is per neighbor, per address family, per direction.
- Line 34: Safety net: warn at 90% of 1000 prefixes and tear the session down above 1000. Protects you if the peer leaks a full table.
Check your understanding
Your eBGP peer suddenly sends you 900,000 prefixes. Which configuration line protects you?
- neighbor 192.0.2.2 ttl-security hops 1
- neighbor 192.0.2.2 password …
- neighbor 192.0.2.2 maximum-prefix 1000 90
- route-map R2-OUT permit 10