BGP Peering Setup: eBGP vs iBGP, Route Maps, and Filters

BGP Peering Setup: eBGP vs iBGP, Route Maps, and Filters

Border Gateway Protocol is less about magic and more about disciplined plumbing: you define who you trust, what you send, what you accept, and how you prefer to exit and enter networks.

If you keep those four levers straight—peering type, next-hop handling, policy with route maps, and defensive filtering—you can build sessions that come up fast and stay up under stress.

We’ll walk a practical path: prepare addresses and roles, bring up eBGP and iBGP, attach route maps and prefix-lists, enforce max-prefix and bogon filters, and test how traffic actually flows end to end.

Along the way we’ll note vendor-neutral behaviors and common knobs you’ll meet on Cisco, Juniper, and FRR, and we’ll call out where defaults differ so you don’t chase ghosts.

Understanding eBGP and iBGP

eBGP runs between different autonomous systems and by default rewrites the next-hop to the directly connected neighbor, sets a low Time To Live (often 1), and has an administrative distance higher than connected and static routes; iBGP runs inside one AS, preserves the original next-hop by default, requires full-mesh or route reflectors for scale, and relies on your IGP to make next-hops reachable.

Next-Hop Behavior and Propagation

On eBGP, the “next-hop” attribute of received routes is usually the eBGP neighbor’s IP, which makes those routes resolvable if the peering link is up; on iBGP, the next-hop is preserved, so internal routers might not be able to reach it unless an IGP provides a path or you set “next-hop-self” on border speakers that distribute external routes inward.

Path Selection Essentials

Local preference wins inside an AS (higher is better), AS path length comes next (shorter is preferred), origin and MED refine choices, and tie-breakers eventually prefer eBGP over iBGP, then lowest IGP metric to next-hop, then lowest router ID; set local preference to express business policy, use AS path prepending sparingly to deprioritize exits, and treat MED as a hint mainly when comparing paths learned from the same neighboring AS unless configured otherwise.

Preparing Your Network for Peering

Pick stable router IDs (loopback addresses), ensure the IGP reaches those loopbacks, and decide whether sessions will be on physical interfaces or to loopbacks with eBGP multihop; enable MD5 authentication if both sides support it to reduce spoofed TCP SYNs, consider BFD for sub-second failure detection, and enable TTL security (GTSM) when peering over directly connected or short paths to reject off-path packets.

Document every session: neighbor IPs (IPv4 and IPv6), remote AS, local AS, update-source, expected prefixes, maximum accepted routes, communities to tag, and contacts; this saves hours when sessions don’t establish or when filters bite.

Step-by-Step BGP Peering Setup

We’ll outline concrete steps you can map to vendor syntax; for readability, treat semicolons as newlines when you paste to your CLI.

Single-Homed eBGP (IPv4/IPv6)

1) Configure the peering interface: set IP addressing (/31 or /30 for IPv4, /127 or /64 for IPv6); 2) Enable BGP with your local AS; 3) Add the neighbor with remote-as; 4) For IPv6, ensure link-local or global neighbor addressing is correct and AFI/SAFI is enabled; 5) Apply inbound prefix-list and route-map to only accept what you expect; 6) Apply outbound route-map to announce specific prefixes and add communities or local-pref policies; 7) Set “maximum-prefix” with a safe threshold and a restart timer; 8) Enable “send-community” (standard and extended if used); 9) Consider “ebgp-multihop N” with “update-source loopback” if peering to loopbacks; 10) Enable TTL security (or set neighbor TTL to 255 with a hop range) on single-hop sessions; 11) Add “password” for MD5 where supported; 12) Avoid “allowas-in” unless you truly must accept your AS in AS_PATH.

iBGP Inside Your AS

1) Decide full-mesh vs route-reflector; beyond a handful of speakers, deploy route reflectors to avoid n·(n−1)/2 sessions; 2) Peer iBGP to loopbacks with update-source set to loopback; 3) Ensure IGP reaches all loopbacks so TCP can form; 4) On edge routers, set “next-hop-self” to make internal next-hop resolution trivial; 5) Standardize local preference defaults (e.g., 100), raising it per-exit for preferred outbound paths; 6) If you carry Internet routes internally, consider add-path or diverse-path extensions to reduce path starvation, and test memory impact.

Route Maps, Prefix-Lists, and Communities

Prefix-lists match exact or ranged prefixes (for example, 203.0.113.0/24 le 32) and should be your first filter; route maps combine matches (prefix, AS path, community) with actions (set local-pref, MED, community, next-hop); communities let you paint routes for downstream policies—define a small, documented set like “no-export”, “no-advertise”, “prepend-2”, “prefer-exit-A”, and automate their application per neighbor direction.

Inbound Policy Pattern

Match only allowed customer prefixes; drop bogons and special-use ranges; cap received routes with maximum-prefix; validate prefix ownership with IRR and RPKI where possible—treat RPKI invalids as reject, unknowns as accepted but monitored, and valids as preferred; avoid leaking full tables into customer sessions unless explicitly contracted.

Outbound Policy Pattern

Announce only aggregates and selected more-specifics; attach “no-export” to traffic-engineering specifics; set local-pref to express exit preference; use AS path prepends to de-prefer an upstream; never advertise default or full routes to peers who shouldn’t see them; consider a graceful-shutdown community when draining maintenance.

Filtering for Stability and Safety

Maintain a bogon list (RFC 1918 and other special-use ranges) and well-known documentation prefixes; drop prefixes longer than /24 in IPv4 and /48 in IPv6 unless you have a justified reason; enforce a maximum AS_PATH length; reject private ASNs on eBGP unless explicitly allowed for customers; use damping only when you understand the collateral impact; and keep all filters under version control so changes are reviewed.

Monitoring and Safety Nets

Enable “maximum-prefix” with a threshold that anticipates normal growth; set a restart-interval so incidental spikes don’t wedge the session; monitor BGP states (Idle, Active, Established), flap counts, prefixes in and out, and route-map hit counters; activate graceful restart only if you control both ends and understand the transient blackhole risk; collect NetFlow or sFlow and BGP telemetry so you can prove policy works as intended.

Troubleshooting Checklist

1) Transport: can you ping or traceroute the neighbor IP and is TCP/179 reachable; 2) Session parameters: ASNs, update-source, TTL or multihop, MD5 key; 3) Address families: did you activate IPv4 and IPv6 AFI/SAFI under the neighbor; 4) Next-hop: on iBGP, can devices resolve the next-hop via IGP or do you need next-hop-self; 5) Policy: are prefix-lists or route-maps silently dropping what you expect; 6) Capacity: maximum-prefix hit and session reset; 7) Path: is local-pref or MED steering the route you think; 8) External evidence: use looking glasses and route servers to see what you’re advertising.

Minimal Vendor-Neutral Examples (Semicolon-Separated)

eBGP to ISP on interface: router bgp 65010; neighbor 203.0.113.2 remote-as 64500; address-family ipv4 unicast; neighbor 203.0.113.2 route-map OUT-POLICY out; neighbor 203.0.113.2 route-map IN-POLICY in; neighbor 203.0.113.2 maximum-prefix 100000 90 restart 10; neighbor 203.0.113.2 send-community both; neighbor 203.0.113.2 password 7 XXXXXX; network 198.51.100.0 mask 255.255.255.0; exit-address-family.

iBGP to route reflector via loopback: router bgp 65010; neighbor 192.0.2.11 remote-as 65010; neighbor 192.0.2.11 update-source Loopback0; address-family ipv4 unicast; neighbor 192.0.2.11 next-hop-self; exit-address-family.

Where Next-Hop and Max-Prefix Commonly Break

Most “session up, no traffic” issues boil down to unresolved next-hops on iBGP—verify loopbacks in IGP and use next-hop-self on border routers; most “sudden outage” incidents are maximum-prefix thresholds during route leaks—set thresholds with headroom and alarms so you can react without a full blackout; when peering over a routed underlay, confirm TTL or GTSM settings don’t block packets in transit.

Operational Tips That Usually Pay Off

Keep policies symmetric and explicit, comment every route-map entry with who and why, automate prefix-list generation from IRR and RPKI, test failover by administratively shutting a neighbor during a maintenance window, and record baseline counters when the network is healthy so you know what “normal” looks like.

BGP Peering Setup and Best Practices (FAQ)

eBGP usually rewrites the next-hop to the neighbor so routes resolve immediately, while iBGP preserves the original next-hop, so you either must carry that next-hop in your IGP or set next-hop-self on border routers.

If your edge sits behind NAT or you’re unsure of the WAN assignment, check your router, then verify with a quick What Is My query and use that address in the peering request template.

Max-prefix caps how many routes you’ll accept from a neighbor; set it to the expected table size with 10–20% headroom and a restart timer so incidental spikes don’t wedge the session, and alert when you approach the threshold.

Do a reverse lookup to see whether the IP maps to the provider’s domain and forward-resolves back to the same IP; a quick Reverse DNS Lookup helps you confirm both directions line up.

/31 wastes zero addresses and works on modern routers, while /30 offers two usable IPs and simplicity on older gear; if you’re unsure, model both with a Subnet Calculator and prefer /31 when both sides support it.

Check public route servers or do an ASN Lookup to ensure the remote AS matches your LOA, then use looking glasses to verify your prefixes appear with the intended path and communities.

Ping the neighbor’s link-local or global address, confirm ICMPv6 works, and run an IPv6 Test from a host behind the router to ensure end-to-end connectivity before activating AFI or SAFI.

BGP doesn’t require DNS, but bad FQDN-to-IP documentation can send you to the wrong address; when in doubt, verify with a quick DNS Lookup and always configure sessions by IP, not by name.