We audit a lot of ISP edge and border routers — Huawei, Cisco, Juniper, MikroTik, whatever the network happens to be running. The same handful of BGP hardening gaps show up again and again, on networks that are otherwise well run. None of these are exotic. All of them get skipped because they don't cause a problem until the day they do.
1. Max-prefix limits on every eBGP session
A route leak from an upstream or peer without a max-prefix limit doesn't stay their problem — it becomes a router with a full RIB, high CPU, and control-plane instability on your side. This is one line of configuration per session and it is still, consistently, the first gap we find on an audit.
Set it with headroom above your expected route count, and set the action to teardown rather than just a warning — a silent warning that nobody's watching isn't protection.
2. Session authentication (MD5 or TCP-AO)
An unauthenticated BGP session is vulnerable to session resets and, in the worst case, route injection from anyone who can reach the TCP session. MD5 authentication has been standard practice for years; TCP-AO is the modern replacement where your platform supports it. Either beats nothing, and "nothing" is what we still find on a meaningful share of eBGP sessions we review.
3. GTSM (Generalized TTL Security Mechanism)
For eBGP sessions between directly connected peers, GTSM rejects packets that didn't originate from an adjacent hop — meaningfully raising the bar for a remote attacker trying to inject BGP packets, since they'd need to be on-path rather than merely IP-reachable.
4. RTBH (Remote Triggered Black Hole) capability with upstreams
When a DDoS attack targets one of your subscriber IPs, RTBH lets you black-hole traffic to that single IP at your upstream's edge — before it saturates your own transit link. Without a pre-arranged RTBH community agreed with your upstreams, your only option during an attack is a phone call and hoping someone answers quickly. Set this up before you need it, not during an active attack.
5. Prefix filtering on customer and peer sessions
Every customer-facing BGP session should have an explicit prefix filter — allow only what that customer is supposed to originate. This is the difference between a customer misconfiguration causing a local problem and it propagating as a route leak across your network and beyond.
6. Disable unused management protocols on the same box
This one isn't strictly BGP, but it shows up on the same routers: Telnet still enabled alongside SSH, weak SSH cipher suites, or SNMP running with default or weak community strings. A border router carrying BGP sessions and IX peering is exactly the box you don't want reachable through a weaker side door.
The pattern behind all of this
None of these six items requires new hardware or a redesign. Every one of them is a configuration change on equipment you already own. The reason they get skipped isn't difficulty — it's that they don't show up in day-to-day operations until an upstream leaks routes, an attacker probes the session, or a DDoS attack hits during a moment when nobody has time to improvise a mitigation plan.
If you want a second set of eyes on your BGP edge configuration, that's exactly what our Carrier & ISP Core audits are for.
This is general engineering guidance based on common ISP audit findings, not a substitute for a review of your specific configuration. Get an infrastructure audit →