BGP and ASNs: how Internet networks exchange routes

The Internet is made of many autonomous systems, each applying its own routing policy. BGP lets those networks tell one another which IP prefixes they can reach.

What an autonomous system represents

An autonomous system is a group of IP networks and routers operated under a common routing policy. It can be assigned an ASN. An ASN is not a server or user identifier; it identifies a participant in interdomain routing.

Registration information about an ASN can be compared with the autonomous-system overview and IP data. One operator can use several ASNs, while one online service can depend on several network operators.

What BGP advertises

BGP distributes reachability for IP prefixes together with route attributes. AS_PATH records autonomous systems traversed by an advertisement, but it is neither a geographic map nor a guaranteed record of every packet's path.

Operator policy, peering and backup links affect route selection. A destination can therefore keep the same IP address while the route used to reach it changes.

Using routing data for troubleshooting

Compare the ASN and prefix with 2ip IP information, then inspect the observed path with traceroute. Do not diagnose an outage from AS_PATH length alone: BGP describes the control plane, while traceroute provides a limited data-plane observation.

The base BGP-4 specification is RFC 4271.

Locate the fault by network layer

A useful workflow starts at the edge of the local network. Check the interface address, default route and DNS configuration, then test the local gateway before moving to the public address and remote service. This prevents a Wi-Fi or Ethernet problem from being mistaken for an ISP routing problem. If the gateway remains stable while latency appears farther away, compare several destinations and repeat the measurement at another time.

Intermediate devices are not required to answer every diagnostic probe. Control-plane filtering, rate limiting and asymmetric routing can change what a trace displays while the application path continues to carry traffic normally.

Addresses, routes and the network you observe

A device's local address, its public egress address and the destination address describe different parts of the path. NAT, CGNAT, VPNs, proxies, CDNs and Anycast introduce additional boundaries, so one IP address should not automatically be treated as an identity for a user or a physical server. Record the destination and time of a test because DNS and BGP can lead a later measurement to different infrastructure.

With IPv6, one interface can also have several addresses, including temporary addresses. Source-address selection is performed by the network stack and can affect the path that is observed.

Make measurements reproducible

A single test is a snapshot. Repeat measurements in a series and record whether the connection is wired or wireless, whether a VPN is active, which resolver is in use and whether background traffic is present. Compare latency to the same destination and run throughput tests under comparable conditions. If latency rises only while the link is busy, investigate queueing and bufferbloat separately.

Keep the context as well as the final number. That makes it possible to distinguish a persistent configuration fault from a brief route change, radio congestion or a different remote edge being selected.