skip to content

What makes a BGP autonomous system stub, multihomed or transit, and when does an enterprise need an AS number of its own?

level: middleimportance: must knowfreq 45%

answer

  1. two questions, not three boxes
  2. count the neighbouring ASes
  3. whose traffic crosses it
  4. single-homed needs no AS
  5. a later plan is no reason

basics

~20 s

A stub AS has one neighbouring AS; a multihomed AS has several but, as an enterprise, carries only its own traffic; a transit AS carries traffic between other ASes. An enterprise mainly needs its own ASN to multihome.

solid answer

~50 s

Two separate questions classify an AS: how many neighbouring ASes it connects to, and whether it carries traffic that neither starts nor ends inside it. A *stub* AS has a single connection and handles only its own traffic. A *multihomed* AS connects to two or more ASes — RFC 1930 means more than one AS with its own routing policy, not redundant links into one provider — and an enterprise that is multihomed still carries only its own traffic. A *transit* AS forwards traffic between other ASes, which is what providers sell. RFC 1930 says a single-homed site needs no AS: its prefixes share the provider's policy and belong in the provider's AS. Multihoming is almost the only case where an operator should create its own AS, because its policy toward two providers differs from either one's. Planning to multihome someday is not a reason.

go deeper

for a junior

Recall the three labels: one connection and own traffic, several connections, and carrying other networks' traffic.

for a middle

Explain the two axes behind the labels and RFC 1930's rule for when a site needs its own AS, including what multihomed really means.

for a senior

Show judgment on an enterprise's first ASN: when to request it, why one origin AS matters, and how announcements keep it non-transit.

for a principal

Discuss when an organisation should deliberately become transit, for subsidiaries or partners, and what that commits it to in capacity, policy and support.

## Two axes, not three boxes The three labels answer two different questions, which is why a single network can wear two of them. | Type | Neighbouring ASes | Carries traffic between other ASes? | Example (documentation ASNs) | |---|---|---|---| | **Stub** | one | no | a site whose only external connection is provider AS 64496 | | **Multihomed, non-transit** | two or more | no | enterprise AS 64500 connected to AS 64496 and AS 64497 | | **Transit** | usually several | **yes** | provider AS 64496 carrying its customers' traffic to and from the rest of the Internet | - **Connectivity** (one neighbour or several) separates stub from multihomed. - **Role** (does third-party traffic cross it?) separates transit from non-transit. - A provider with two upstreams is both multihomed and transit. Terminology varies: some texts call any non-transit AS a stub, including a multihomed enterprise, so in an interview state which axis you mean. ## What RFC 1930 says about needing an AS RFC 1930 (BCP 6) is blunt that an AS is needed only for a routing policy that differs from your neighbours'. Its sample cases: 1. **Single-homed site, single prefix** — no separate AS; the prefix belongs in the provider's AS, because it has the same routing policy as the provider's other customers. 2. **Single-homed site, multiple prefixes** — still no separate AS. 3. **Multi-homed site** — an AS is required, distinct from the providers' ASes, so the site can express its own preference among them. RFC 1930 calls this **almost the only case** where an operator should create its own AS. Its "other factors" add that geography or topology alone rarely justify an AS, and that **future-proofing is not a reason**: a site that may add a second provider later should wait, because the AS number space is finite and the re-engineering at that point is small. RFC 1930 also pins down "multi-homed": connecting to **more than one AS with its own routing policy**. Two links to the same provider, or an IGP run over redundant paths for resilience, do not count. ## Why the multihomed site needs its own number - Its prefix should appear with **one origin AS** everywhere (RFC 1930 §7). If it sat inside provider A's AS but was also announced via provider B, the Internet would see one prefix behind two different policies. - Its policy is genuinely its own: which provider it prefers for which traffic, what it announces to each. - RFC 4271 notes that an AS with several BGP speakers that provides **transit** must keep a consistent view of exterior routes among all of them, which is part of why running transit is an engineering commitment, not a side effect. ## The enterprise's first ASN 1. Today: single-homed to AS 64496 with provider-assigned space. No ASN is needed; if it speaks BGP at all, a private ASN that the provider strips is enough. 2. It adds provider AS 64497. It is now multihomed, obtains a public ASN (written here as documentation ASN 64500) and originates its prefix from it to both providers. 3. It stays **non-transit** by announcing only its own prefixes to each provider. The export filter that enforces this is a routing-policy subject; the point here is that the AS type follows from what it announces. 4. Whether it takes full tables or only default routes from each provider changes how it picks exits, not which type of AS it is. ## Reading the type from AS paths Because every AS prepends its number when it announces a route to an external peer, the role of an AS shows up in the paths others see: - a **non-transit** AS, stub or multihomed, appears only as the **last** entry of a path — the origin of its own prefixes; - a **transit** AS also appears **in the middle** of paths, between the AS that originated a prefix and the AS that heard it; - an enterprise ASN that suddenly shows up mid-path toward another network's prefix is the visible sign that it has started carrying traffic it should not. ## Common errors - Equating "multihomed" with "transit". - Requesting an ASN for a single-homed site "to be ready". - Counting two circuits to one provider as multihoming. - Assuming a stub AS cannot run BGP — it often runs eBGP to its single provider.

  • Is a regional provider that buys service from two upstreams and sells to customers multihomed or transit?
    Both. Multihomed describes its connectivity, two upstream ASes; transit describes its role, carrying customers' traffic to and from those upstreams. The labels are separate axes, which is why describing an AS by one word often hides the question an interviewer is actually asking.
  • Does an enterprise with two links into the same ISP count as multihomed in RFC 1930's sense?
    No. RFC 1930's multihomed means connected to more than one AS with its own routing policy. Two links into one provider share that provider's policy, so the site still needs no AS of its own; if it runs BGP on those links, a private ASN that the provider strips is enough.

saying these in an interview costs you the question

  • Multihomed and transit mean the same thing.
  • Any company with two Internet links needs a public ASN.
  • Get an ASN now in case you multihome later.
  • A stub AS cannot run BGP at all.
  • A multihomed enterprise automatically becomes a transit AS.