How poor BGP design costs businesses thousands every year

BGP is often treated as finished once prefixes appear in the routing table. That is understandable during a pressured deployment, but it is also how fragile designs survive for years. The network appears healthy until an upstream failure, route leak, DDoS event or maintenance window exposes decisions that were never made deliberately.

The commercial cost is rarely limited to an engineer’s time. Poor routing can create customer-facing outages, asymmetric paths, avoidable transit spend, failed migrations, emergency call-outs and reputational damage. For an MSP or ISP, it can also undermine confidence in the wider service.

1. Exchanging routes without a documented policy

A good BGP design begins with intent. Which paths should be preferred? Which prefixes may each neighbour advertise? What should be announced to transit providers, internet exchanges, direct peers and customers? How should blackhole routes be handled? What happens when the preferred path disappears?

When these questions are not written down, filters become a collection of historical decisions. One engineer adds a rule to resolve an incident. Another copies the filter to a new peer. Over time, the configuration still exchanges routes, but nobody can confidently explain the complete behaviour.

2. Giving every route the same local preference

Local preference is one of the clearest ways to express outbound path choice inside an autonomous system. If direct peers, route servers and transit all receive the same preference, path selection becomes dependent on attributes that may not reflect commercial or operational intent.

A common design might prefer direct private peers first, internet exchange route servers second, primary transit third and backup transit last. The exact values are less important than consistency and documentation. The policy must also account for customer routes, internal infrastructure and exceptional paths such as mitigation services.

Without this hierarchy, traffic can leave through a more expensive or less suitable path even though a better route exists.

3. Weak inbound and outbound filtering

Inbound filters protect the network from bad information. Outbound filters protect the rest of the Internet—and your reputation—from incorrect announcements. Both should be explicit.

At a minimum, production policy should consider allowed prefix lengths, expected customer prefixes, default routes, bogons, private address space, martians, your own prefixes, maximum-prefix limits and the role of each neighbour. Customer sessions should normally be constrained to an agreed prefix set rather than trusting anything the customer sends.

Outbound filtering deserves equal care. A service provider should be able to demonstrate exactly which aggregate prefixes may leave each external session. Accidental more-specific announcements can change traffic flows immediately and may be difficult to notice from inside the originating network.

4. Treating RPKI as an optional future task

RPKI origin validation helps identify announcements where the originating ASN does not match the authorised route origin. It is not a complete security system, but it is now a normal part of responsible routing policy.

A sensible rollout starts with visibility: connect to reliable validators, observe valid, invalid and not-found routes, confirm cache resilience and understand how current peers behave. Enforcement can then be introduced in a controlled way, normally rejecting invalid routes while maintaining clear monitoring and change records.

The operational mistake is not only failing to deploy RPKI. It is deploying it without monitoring, redundancy or a plan for validator failure.

5. Having no tested DDoS routing workflow

During an attack is the wrong time to design a blackhole process. Networks that use remotely triggered blackholing should document the accepted prefix lengths, BGP community, authorised sources, validation rules, propagation behaviour and removal process.

The technical configuration is only part of the answer. The NOC or support team must know who can trigger mitigation, how the action is recorded and how it is safely withdrawn. Where upstream scrubbing is available, the routing policy should define when traffic moves from local mitigation to the provider’s service.

6. Adding IPv6 as an afterthought

IPv6 should follow the same quality of design as IPv4. That includes addressing plans, route aggregation, prefix filtering, RPKI, firewall policy, monitoring, customer delegation and failover behaviour.

Simply enabling an IPv6 address on interfaces can create a network that is technically dual-stack but operationally incomplete. Teams then discover that monitoring only covers IPv4, access controls differ between protocols or customer prefixes are not aggregated cleanly.

Building IPv6 into the routing architecture early is usually cheaper than retrofitting it after every platform, process and customer template has been designed around IPv4 alone.

7. Assuming two connections automatically create resilience

Two upstreams do not guarantee high availability. Both services may share the same fibre path, building entry, power domain, exchange fabric or carrier dependency. The routers may also rely on a single internal switch, route reflector, management network or configuration process.

Real resilience requires failure-domain analysis. Test physical failures, BGP withdrawal, partial packet loss, high latency, stale routes and maintenance scenarios. Confirm not only that traffic moves, but that it moves to the intended path within an acceptable time and returns predictably afterwards.

For live customer networks, the rollback process deserves as much design effort as the preferred migration path.

Anonymous project example: multi-carrier policy redesign

A service provider had accumulated multiple transit and peering connections over several years. The network had connectivity, but path preference was inconsistent, filters had been copied between sessions and the team could not confidently predict the effect of losing a carrier.

The engagement began by documenting commercial and technical intent. Peers were grouped by role, local preference was standardised, allowed announcements were reduced to explicit aggregate sets, RPKI validation was introduced and blackhole handling was separated from normal customer route acceptance.

The migration was staged connection by connection. Each change included route-table checks, advertised-route validation, traffic observation and rollback criteria. The final result was not merely a cleaner configuration: the operations team could explain why each path was selected and test failure without relying on guesswork.

What I would review first

• A complete neighbour inventory and the purpose of every session.
• Inbound and outbound prefix policy by peer role.
• Local preference, MED, communities and prepend strategy.
• RPKI validator resilience and invalid-route handling.
• Customer prefix limits and explicit allowed-prefix lists.
• IPv6 parity across routing, security and monitoring.
• Blackhole and DDoS escalation procedures.
• Failover testing, convergence expectations and rollback plans.
• Monitoring for session state, route count and unexpected announcements.