In BGP, what is an autonomous system, and what does its AS number do in the routes BGP exchanges?
answer
- a unit of policy, not of ownership
- one coherent picture to outsiders
- My Autonomous System in the OPEN
- AS_PATH lists ASes, not routers
- your own number in the path
basics
~20 sAn autonomous system is a network, or group of IP prefixes, run under one clearly defined routing policy. Its AS number identifies it to BGP peers and is prepended to AS_PATH, which BGP uses to compare paths and reject loops.
solid answer
~50 sRFC 1930 defines an AS as a connected group of IP prefixes, run by one or more operators, with a *single, clearly defined routing policy*; RFC 4271 adds that however many IGPs run inside it, the AS presents one coherent picture of what is reachable through it. BGP treats the AS as its routing unit. A speaker states its ASN in the OPEN message's `My Autonomous System` field, and each AS prepends its number to `AS_PATH` when it advertises a route to an external peer, so a route records the ASes it crossed, not the routers. That list does two jobs: a shorter `AS_PATH` is one of BGP's tie-breakers, and a speaker that finds its own ASN in a received `AS_PATH` excludes the route as a loop. Comparing the peer's ASN with your own also tells you whether a session is external or internal.
go deeper
Recall the one-line definition: one routing policy, one number. Say that BGP's AS_PATH lists autonomous systems, not routers.
Explain where the ASN appears: the OPEN message, the eBGP/iBGP distinction, AS_PATH prepending and the loop check that drops a route carrying your own number.
Show you know policy draws the border: when a site needs no AS, when it needs one, and what goes wrong when two sites of one AS meet only through a provider.
Discuss how an organisation should map its routing policies onto ASes, and the cost of splitting or merging ASes once peers and filters are built around the numbers.
## What an autonomous system is An **autonomous system (AS)** is the unit BGP routes between. RFC 4271, the BGP-4 specification, gives the *classic* definition: a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to route packets inside the AS, and an inter-AS protocol to route packets to other ASes. It then notes that many ASes now run several IGPs and several sets of metrics, and that what still makes them one AS is that the administration *appears to other ASes to have a single coherent interior routing plan* and presents a consistent picture of the destinations reachable through it. RFC 1930 (BCP 6) restates this more sharply: - an AS is **a connected group of one or more IP prefixes run by one or more network operators which has a single and clearly defined routing policy**; - "routing policy" means how routing decisions are made between ASes: which prefixes an AS announces to a neighbour, and which announcements it accepts; - **without exception, an AS must have only one routing policy** — it is not a convenient label for everything one organisation owns. ## Policy, not ownership, draws the border Because the AS is the unit of policy, the org chart does not decide how many ASes you have: - a site connected to a single provider shares that provider's policy, so RFC 1930 says it needs no AS of its own — its prefixes belong in the provider's AS; - a network connected to two providers has a policy of its own (which provider to prefer, what to announce where), so it needs its own AS; - one organisation may run more than one AS if parts of it genuinely follow different policies, though RFC 1930 calls this rare. Each AS has a number, the **ASN**, which RFC 1930 describes as both the identifier of the AS and the value used when exchanging routing information between neighbouring ASes. ## What the AS number does on the wire | Where the ASN appears | What BGP does with it | |---|---| | OPEN message, `My Autonomous System` (a 2-octet field) | The peer checks it against the ASN it expects; an unacceptable value is answered with a NOTIFICATION whose error subcode is **Bad Peer AS**. A 4-octet ASN travels in a capability instead (RFC 6793). | | Session classification | A peer in a different AS is an *external* peer (eBGP); a peer in the same AS is an *internal* peer (iBGP). | | `AS_PATH` attribute | When a route is advertised to an external peer, the advertising AS prepends its own number, so the path lists every AS the announcement crossed, newest first. | | Loop detection | RFC 4271 §9.1.2: if the local ASN already appears in a received `AS_PATH`, the route is excluded from the decision process. | | Path comparison | Among routes of equal preference, the one with the shorter `AS_PATH` wins a tie-break (the full decision order is its own subject). | Two details of origination matter. A speaker that originates a route sends an `AS_PATH` holding **one `AS_SEQUENCE` segment containing only its own ASN** to external peers, and an **empty** `AS_PATH` to internal peers, because no AS boundary has been crossed yet. ## A worked trace Using documentation ASNs (RFC 5398) and a documentation prefix: 1. Enterprise AS 64500 originates `203.0.113.0/24` to its provider AS 64496 with `AS_PATH` = `64500`. 2. AS 64496 advertises it to AS 64497, prepending itself: `64496 64500`. 3. AS 64497 advertises it to its own neighbours as `64497 64496 64500`. 4. If that announcement ever comes back to AS 64500, the enterprise finds `64500` in the path and discards the route: an AS loop. Inside each AS, an IGP still decides which router and link a packet uses; BGP's view stays at the level of "which sequence of ASes leads to this prefix". ## Common misreadings - **"An AS is a company's network."** It is a policy domain; a company may have none, one or several. - **"AS_PATH records the routers a route passed."** It records ASes only; ten routers inside one AS add one entry. - **"Seeing your own ASN just makes a path longer."** It makes the route ineligible. Accepting it anyway is an implementation option that RFC 4271 places outside its scope and RFC 7454 advises operators against enabling. - **"Every Internet-connected site needs an ASN."** A single-homed site does not.
- Does an organisation need one autonomous system per site or per business unit?No. RFC 1930 ties an AS to routing policy, not to the org chart: prefixes that share one policy belong in one AS, and a site single-homed to one provider shares that provider's policy, so it needs no AS of its own. A separate AS is justified by a genuinely different policy, multihoming to several providers being the usual case.
- If BGP rejects routes containing its own AS number, how do two sites of one AS that meet only through a provider learn each other's prefixes?By default they cannot: each site drops the other's routes because the shared ASN is already in AS_PATH. Options are giving the sites separate ASNs, using a default route toward the provider, or an implementation feature that accepts the local ASN in the path. RFC 4271 leaves that acceptance outside its scope, and RFC 7454 advises against overriding the default without a reason.
AS_PATH works like the exit stamps in a traveller's passport: every country stamps it on the way out, and a border officer who finds his own country's stamp already there turns the traveller away as someone who has gone round in a circle.
saying these in an interview costs you the question
- An autonomous system is simply every network one company owns.
- AS_PATH lists every router the route passed through.
- Every site connected to the Internet needs its own AS number.
- An AS must run exactly one IGP inside it.
- Finding your own ASN in AS_PATH only makes the path longer, not invalid.