A multihomed enterprise running BGP to two ISPs starts carrying traffic between them; how did its AS become transit, and why is that harmful?
answer
- announce means accept traffic
- routes from one upstream to the other
- providers often prefer customer routes
- a hairpin-shaped route leak
- announce only what you originate
basics
~20 sIt announced routes learned from one ISP to the other, so the second ISP, often preferring customer routes, sent traffic for the first ISP's destinations through it. Its links fill with others' traffic; RFC 7908 calls this a route leak.
solid answer
~50 sIn BGP, traffic follows announcements in reverse: announcing a prefix to a neighbour means accepting traffic for it (RFC 1930). If the enterprise's announcements to ISP B include routes it learned from ISP A, it is offering ISP B a path to ISP A's destinations. Providers commonly prefer routes learned from customers over routes from peers, and that local preference outranks `AS_PATH` length, so ISP B may send the traffic through the enterprise even though the path is longer. The enterprise's uplinks, sized for its own traffic, now carry other networks' traffic; third parties get a longer, congested path; and RFC 7908 classifies the announcement as a route leak, its 'hairpin turn' type. A non-transit AS should announce only the prefixes it originates — RFC 7454 says not to advertise prefixes with a nonempty AS path unless you intend to provide transit — and its upstreams should accept only the customer's own prefixes.
go deeper
Recall that what an AS announces decides what traffic it carries, and that an enterprise should announce only its own prefixes.
Explain the chain: a route learned from one ISP announced to the other, the second ISP's preference, and traffic entering and leaving the enterprise.
Diagnose and contain it: why loop detection is silent, why local preference beats path length, the blast radius, and filters on both sides of the link.
Decide where the guardrails live: software defaults, upstream filtering, monitoring of announcements, and who owns verifying them after every edge change.
## Announcements pull traffic RFC 1930 explains the core rule with two ASes: for traffic toward a prefix to flow from AS Y into AS X, **X must announce the prefix to Y and Y must accept it**. Announcements travel one way; traffic flows back the other way. An AS therefore carries exactly the traffic its announcements invite. A **transit** AS is one whose announcements invite traffic for destinations that are not its own, and a multihomed enterprise becomes one, by accident, the moment it announces routes it learned from one provider to the other. ## How the accident happens Using documentation ASNs and prefixes: 1. Enterprise AS 64500 runs eBGP to ISP A (AS 64496) and ISP B (AS 64497) and accepts full routes from both. 2. Its announcements to ISP B are too broad: instead of only its own `203.0.113.0/24`, they include its best routes, among them `198.51.100.0/24`, which it learned from AS 64496 with `AS_PATH` = `64496`. 3. AS 64500 announces that route to AS 64497 with `AS_PATH` = `64500 64496`. 4. AS 64497 also hears `198.51.100.0/24` directly from AS 64496, its peer, with `AS_PATH` = `64496`. If its policy gives customer-learned routes a higher local preference than peer-learned ones, the customer route wins, because the degree of preference is compared **before** `AS_PATH` length. 5. Traffic from AS 64497's network to `198.51.100.0/24` now enters AS 64500 on one uplink and leaves on the other. Nothing in this chain is a protocol error. **AS_PATH loop detection does not fire**, because no AS ever sees its own number in the path; the route is loop-free and simply violates the intended policy. RFC 7908 names this **Type 1, "hairpin turn with full prefix"**: a multihomed AS learns a route from one upstream and propagates it to another, often by accident, and it often succeeds because the second ISP prefers the customer announcement. ## Why it is harmful - **Capacity.** The enterprise's links were sized for its own traffic; third-party traffic congests them, and its own users suffer first. - **Cost.** On usage-billed links, the enterprise pays to carry other networks' traffic in both directions. - **Blast radius.** ISP B may propagate the leaked route to its own customers, peers and transit providers, so the detour can attract traffic from far beyond ISP B. - **Third parties.** Packets still reach the right destination, but over a longer, congested path through a network never built for it — latency and loss that are hard to trace across operators. - **It is not a hijack.** The origin is genuine and the traffic is delivered; that distinction matters when you report or diagnose it. ## Preventing it: whose job | Where | Measure | Source | |---|---|---| | Enterprise exports | Announce only prefixes originated by the enterprise; never a prefix with a nonempty AS path unless it intends transit | RFC 7454 §9 | | BGP software default | Add no route to an eBGP peer's Adj-RIB-Out without an explicit export policy | RFC 8212 | | Upstream imports | Accept from a customer only its own prefixes and AS paths | RFC 7454 | | Session roles | Detect leaks from the roles both sides declare | RFC 9234 | How each filter is written, and how leaks are detected across the Internet, are their own subjects; for this leaf the point is that **an AS's type is decided by its announcements, not by its topology**. Two upstreams make an enterprise multihomed; only its announcements can make it transit. ## What a strong answer adds - Distinguish multihomed (connectivity) from transit (what the AS announces and therefore carries). - Notice that taking full tables is harmless; announcing them onward is the fault. - State that local preference ranks above `AS_PATH` length, which is why a longer leaked path can still win. - Check announcements per neighbour after any change to the edge configuration, because the failure is silent until traffic moves. - Remember the leak usually runs both ways: announcements broad enough to leak ISP A's routes to ISP B usually leak ISP B's routes to ISP A as well. - Expect the symptom first on the links, not in BGP: utilisation that no longer matches the enterprise's own traffic, or flows whose source and destination are both outside the enterprise.
- If ISP B does not prefer customer routes, is the leaked announcement harmless?Less harmful, not harmless. Without a customer preference, ISP B picks its direct path, one AS long against two, and announces only that best route onward, so traffic may not move. The leak stays latent: a policy change at ISP B, or a failure of its direct path, makes the enterprise transit at once, and the same broad announcements usually leak ISP B's routes toward ISP A too.
- Why does BGP's AS_PATH loop detection not catch this leak?Loop detection only rejects a route whose AS_PATH contains the receiving AS's own number. The leaked path 64500 64496 reaches AS 64497, which is not in it, so the route is loop-free. The fault is a policy violation, which only filters or role checks can catch.
saying these in an interview costs you the question
- AS_PATH loop detection would reject the leaked routes automatically.
- An AS only becomes transit by signing a transit contract.
- Taking full routing tables from both ISPs is what makes it transit.
- The leak affects only the enterprise's own outbound traffic.
- A route leak and a prefix hijack are the same thing.