ebgp peering, simpler than it sounds

bgp has a scary reputation it doesn't deserve

bgp runs the entire internet, which makes it sound like some untouchable wizard protocol. it's not. it's a handshake between two networks that says "here's what i own, send me your traffic for it." the scary part isn't the protocol, it's what happens when nobody's watching the session. that's the part defenders actually need to care about.

setting up an ebgp neighbor, the basics

external bgp just means the two routers talking to each other belong to different autonomous systems. autonomous system numbers are like network zip codes, they tell the internet who owns what. here's the skeleton config:

router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 203.0.113.2 remote-as 65002
 network 198.51.100.0 mask 255.255.255.0

router bgp 65001 starts the bgp process under your own as number. bgp router-id gives the process a unique identifier, usually a loopback address, so the router can be told apart from every other router in the swarm. neighbor ... remote-as is the actual peering statement, you're telling your router "this ip belongs to a different as, go establish a session with it." and network with an exact mask is you announcing your own prefix to the world, note the word exact, bgp will not advertise a network statement that doesn't match a route in your table down to the mask.

checking the session, breaking down the command

show ip bgp summary

this pulls up every neighbor your router knows about and the state of each session. the column that matters most is PfxRcd, prefixes received. a number in that column means the session is up and your neighbor is actually sending you routes. if you see "idle," "active," or "connect" instead of a number, the session never finished forming and no routes are flowing. that state column is your first troubleshooting clue, and it's also your first security clue.

why this matters for defense, not just uptime

bgp was built in an era where everyone assumed everyone else was trustworthy. that assumption is why route hijacks and leaks still happen today, a misconfigured or malicious as can announce a prefix it doesn't own and pull traffic toward it. as a defender running your own bgp sessions, your job isn't to worry about attacking anyone, it's to make sure nobody can quietly reroute your traffic or impersonate your network. a few things to actually check on your own gear:

filter what you accept. use prefix lists or route maps on every ebgp neighbor so you're only accepting the routes you expect, not everything the neighbor decides to send.

ip prefix-list ALLOWED-IN permit 198.51.100.0/24
neighbor 203.0.113.2 prefix-list ALLOWED-IN in

filter what you announce. the network command doesn't stop you from accidentally leaking internal or customer prefixes if your routing table gets messy. lock down outbound announcements the same way you lock down inbound.

turn on md5 or ttl security. bgp sessions can be authenticated with a shared password, and the ttl security check (bgp ttl-security hops) makes it much harder for someone off-path to spoof a peering session.

neighbor 203.0.113.2 password yourSharedSecret
neighbor 203.0.113.2 ttl-security hops 1

monitor your own prefixes on the internet. services that track route origin (rpki monitors, looking glass tools, bgp alerting services) will tell you if someone out there is announcing your ip space without permission. that's a hijack in progress and you want to know within minutes, not weeks.

adopt rpki if your upstream supports it. route origin validation lets other networks cryptographically verify that you're the legitimate owner of a prefix before they accept your announcement. it doesn't fix everything but it closes off a huge chunk of the accidental-leak and casual-hijack problem.

the takeaway

eBGP peering itself is a short config and one command to verify. the real work of running bgp safely is everything around it, filtering what you trust, authenticating your sessions, and watching for your own prefixes showing up somewhere they shouldn't. learn the protocol, then spend your energy locking down the edges. that's where the actual risk lives.