How does a BGP speaker use the AS_PATH attribute to keep routes from looping between autonomous systems?
answer
- a list that grows at borders
- prepend on eBGP only
- look for your own number
- exclude, do not reset
basics
~20 sEach AS adds its own number to AS_PATH when advertising a route to an external peer. A BGP speaker that finds its own AS number in a received AS_PATH treats the route as a loop and does not use it.
solid answer
~50 s`AS_PATH` is a well-known mandatory attribute listing the autonomous systems a route has crossed, most recent on the left and the origin AS on the right. RFC 4271 has a speaker prepend its own AS number whenever it advertises the route to an **external** peer, and leave `AS_PATH` untouched toward **internal** peers. On receipt, the speaker scans the whole path: if its own AS number appears anywhere, the route contains an AS loop and is excluded from the decision process. So an AS does not use a route that has already passed through it. Two consequences follow. The check sees nothing inside one AS, because iBGP never changes the path; that is why iBGP has its own propagation rule. And two sites that share one AS number cannot learn each other's routes through a provider, because each site sees its own number in the path.
go deeper
Recall the rule: each AS prepends its number at an eBGP border, and a speaker that sees its own number in the path discards the route as a loop.
Explain where the path changes and where it does not: prepend toward external peers, untouched toward internal peers, and the full-path scan for the local AS only.
Show the operational edge: two sites sharing one AS number cannot learn each other's routes, and the options that accept your own AS weaken the loop check you rely on.
Weigh AS-number allocation for a multi-site network: unique numbers keep the loop check intact, while shared numbers save allocation effort but force defaults or exceptions.
## What AS_PATH records **`AS_PATH`** (type code 2) is one of BGP's three **well-known mandatory** attributes: every BGP speaker must recognise it and every UPDATE that carries reachable prefixes must include it. It is a list of **path segments**; the ordinary segment type is an **`AS_SEQUENCE`**, an ordered list of the autonomous systems the route has crossed. The **leftmost** AS is the one that advertised the route most recently; the **rightmost** is the **origin AS**. ## How the path grows at each border RFC 4271 §5.1.2 fixes when a speaker touches the path: 1. **Originating toward an external peer**: the speaker puts its own AS number in a single `AS_SEQUENCE`. 2. **Originating toward an internal peer**: the speaker sends an **empty** `AS_PATH` (length zero). 3. **Passing a learned route to an internal peer**: the speaker **SHALL NOT** modify `AS_PATH`. 4. **Passing a learned route to an external peer**: the speaker **prepends** its own AS number on the left. If the first segment is already full (255 ASes, since the segment length is one octet), it starts a new `AS_SEQUENCE`. A speaker may also prepend its own number more than once, by local configuration; how operators use that is a routing-policy matter. ## The loop check RFC 4271 §9.1.2 states the rule: if a route's `AS_PATH` contains an AS loop, the route **should be excluded** from the phase of the decision process that picks a best route. Loop detection means scanning the **full** path and checking that the **local** AS number does not appear in it. Nothing else is compared: a path in which some *other* AS appears several times, because that AS prepended itself, is not a loop. Follow 203.0.113.0/24 from origin AS 64496: | Step | Who advertises | To | AS_PATH on the wire | Receiver's check | |---|---|---|---|---| | 1 | AS 64496 | AS 64500 (eBGP) | `64496` | 64500 absent: accept | | 2 | AS 64500 | AS 64510 (eBGP) | `64500 64496` | 64510 absent: accept | | 3 | AS 64510 | AS 64496 (eBGP) | `64510 64500 64496` | **64496 present: loop, exclude** | The route that left AS 64496 is not used by AS 64496 when it comes back, so the advertisement cannot circulate through that AS again. Note that the speaker does not reset the session or send an error: it simply does not select the route. Operating a speaker that is configured to accept its own AS number is, in RFC 4271's words, outside the scope of the document. ## What the check does not cover - **Loops inside one AS.** Over iBGP the path is unchanged, so a route circulating between internal peers carries no new information. BGP prevents that differently: a route learned from an internal peer is not re-advertised to other internal peers, unless a route reflector does so with its own loop-prevention attributes. - **Aggregates that dropped information.** When a speaker aggregates routes and drops the AS numbers they carried, the aggregate gets the **`ATOMIC_AGGREGATE`** attribute to warn that the path shown may not be the full path. The older alternative, an unordered `AS_SET` segment listing those ASes, is deprecated by RFC 9774. - **Which path is shorter.** Path length is also a tie-breaker in the decision process; that order is a separate subject. ## When the check bites a legitimate design A customer runs two sites with the **same AS number**, say 64505, both attached to provider AS 64500. Site A announces its prefix; the provider passes it to site B with path `64500 64505`. Site B finds 64505 in the path and excludes the route, so the sites cannot reach each other through the provider. The check is doing its job; the design is the problem. The remedies: - give each site its own AS number, which is the clean fix; - have site B follow a default route from the provider instead of the specific prefix; - use an implementation option that accepts the local AS number a limited number of times, or one on the provider side that replaces the customer's number in the path. Both are implementation features outside RFC 4271, and both weaken the loop check they bypass. ## A related optional check RFC 4271 §6.3 also lets a speaker check that the **leftmost** AS in a path received over eBGP equals the neighbour's own AS number. That catches a peer that failed to prepend itself. It is a sanity check on the neighbour, not loop detection.
- Why can't AS_PATH loop detection stop a route from circulating between iBGP speakers inside one AS?Over iBGP the speaker SHALL NOT modify `AS_PATH`, so the local AS number never enters the path inside the AS and there is nothing new to detect. BGP relies on a different rule there: a route learned from an internal peer is not re-advertised to other internal peers, which is why iBGP needs a full mesh or route reflectors.
- If AS 64501 prepends itself three times, does AS 64500 treat the path 64501 64501 64501 64496 as a loop?No. The check looks only for the receiver's own AS number, and 64500 is not in the path. Repeated entries of another AS are legal: RFC 4271 lets a speaker prepend its own number more than once. The path is simply longer.
- What does a BGP speaker do when it receives a looped route: drop the session or the route?Only the route. RFC 4271 §9.1.2 excludes a route whose `AS_PATH` contains the local AS from best-route selection; no NOTIFICATION is sent and the session stays up. Session-level errors are reserved for malformed messages, not for routes that fail the loop check.
A chain letter lists every town it has passed through. Each town adds its name before mailing it on; a town that finds its own name already on the list knows the letter has come back and throws it away.
saying these in an interview costs you the question
- Every BGP router adds its AS number, including on iBGP sessions.
- A route is rejected whenever any AS appears twice in its AS_PATH.
- The origin AS is the leftmost entry in AS_PATH.
- AS_PATH loop detection also prevents loops between routers inside one AS.
- A looped route makes the receiver reset the BGP session with a NOTIFICATION.
- BGP stops inter-AS loops by counting hops down like the IP TTL.