How BGP works: prefixes, AS paths, routing decisions and DDoS impact

Defining the problem

Calling BGP “the protocol of the Internet” is true but not enough. BGP is an announcement system between autonomous systems. Each network publishes prefixes, receives routes and chooses according to local policy.

This distributed nature is powerful and sometimes counter-intuitive. Different ISPs may choose different paths. A more-specific route can attract more traffic. A community can ask a transit provider to change preference, prepend or blackhole. For protected transit, these details are operational, not academic.

BGP attributes are not universal commands. Local preference is usually internal to one network, AS path prepending may or may not influence remote networks, and MED is often ignored across provider boundaries. This is why testing with real upstreams matters.

Why this matters

BGP matters for DDoS because it controls where traffic lands before filtering. If a prefix is announced only behind a small port, a volumetric attack may saturate the link before servers can respond.

Clean delivery matters as much. After scrubbing, traffic must return through tunnel, cross-connect or another defined model. Without a clear BGP design, asymmetry and route conflicts appear during incidents.

In DDoS mitigation, the most-specific accepted route often wins. A /24 IPv4 announcement can attract traffic away from a larger aggregate. That is useful for mitigation, but dangerous if it is not coordinated with RPKI, IRR objects and prefix filters.

Possible solutions

Classic customer eBGP lets the customer announce prefixes and control routing with full table or default route.

Provider-operated announcement is simpler for customers without deep routing skills, but it must remain transparent.

The mitigation model announces the prefix toward the DDoS network, filters traffic and delivers clean traffic through GRE, IPIP, VXLAN, router VM or cross-connect.

Default route is enough for many protected customers because inbound traffic is the main exposure. Full table becomes useful when the customer wants detailed egress control, traffic engineering or multiple transit relationships.

Customer eBGP

Strong control, more operational skill.

Operated announcement

Easy start, needs provider transparency.

Protected transit

Traffic is attracted, filtered and cleanly delivered.

Concrete use case

Before production, a route should be tested from several external vantage points. Looking only from the customer router proves that the session is up; it does not prove that the Internet sees the intended origin and path.

Frequent mistakes

BGP mistakes often appear only under load, when a provider changes preference or when an attack forces the network onto paths that were never tested.

Another mistake is treating BGP changes like harmless configuration edits. Route propagation, filters and cache effects can make rollback slower than expected, so changes need staged procedures.

• Thinking BGP filters packets like a firewall.
• Announcing a prefix without defining clean return path.
• Ignoring IPv4/IPv6 prefix limits.
• Using more-specific routes without policy.
• Skipping RPKI/ROA and basic routing hygiene.

FAQ