8.4 Internet Components, Peering, and Transit

The Internet is a network of routing domains

The current course lists Internet components alongside introductory routing. Understand how customer access, provider transport, autonomous systems, and exchange points fit together. An Internet connection depends on both physical interconnection and routing agreements; neither one alone establishes global reachability.

A small customer can attach to one provider and use a default route. The provider aggregates many customers, carries traffic through its own infrastructure, and connects to other networks. Larger customers and content networks can have their own AS and several interconnections.

A product name does not determine a router's role. A 7750 SR can appear at a provider edge or peering boundary, while other platforms can serve access and aggregation needs.

Access, aggregation, edge, and core

A demarcation point identifies an agreed service boundary, often at the customer handoff. It is not the same as an Internet exchange point. A Point of Presence (PoP) is a location where an operator has network presence and equipment; it can host access, aggregation, core, or interconnection functions.

A large facility can contain several operators and interconnections. Sharing a building does not automatically put two customers into the same VLAN or create a BGP session.

Autonomous systems and number resources

An Autonomous System presents a coherent routing policy. Public ASNs and globally unique IP address resources support Internet routing, with IANA and the Regional Internet Registries providing the allocation/registration framework.

Do not confuse resource assignment with actual reachability. An assigned prefix is not automatically advertised, and an advertisement is not proof that every remote network accepts it. Route policy and operational state determine which information propagates.

Private addresses and private ASNs have internal uses. They require appropriate treatment at public boundaries. A provider can route private addresses in its own infrastructure without making them globally reachable customer destinations.

Transit and peering

IP transit provides reachability through another network under a service agreement. A customer buys or otherwise obtains upstream connectivity that can carry traffic toward networks beyond the immediate neighbor.

Peering exchanges agreed traffic between networks. Its scope is controlled by policy and the relationship. A peer is not automatically an unrestricted transit provider, and a peering session does not necessarily supply a full Internet routing table.

For example, content network A and provider B can exchange reachability for their own relevant destinations. That does not imply B may use A to reach every unrelated provider. Export policies enforce the intended relationship.

A useful exam distinction is “connected physically” versus “authorized to exchange a route.” A working interface and Established BGP session can coexist with no accepted route to the destination because the relationship does not include it.

Internet exchange points

An Internet Exchange Point (IXP) provides shared interconnection infrastructure where participating networks can exchange traffic. A conventional IXP offers an Ethernet switching fabric; participants can establish BGP relationships over the exchange.

An IXP is not synonymous with an ISP, a PoP, a demarcation point, or a default gateway. The exchange can host many independent ASes. The participants' routers and policies still determine reachability.

Some exchanges offer a route server to simplify routing-information exchange. The route server's control-plane role does not mean customer data packets must be forwarded through it. An ordinary participant-to-participant data path can remain directly across the exchange fabric.

A private interconnect is another way to connect two networks without using the shared exchange fabric. Both shared and private interconnections need suitable physical capacity, addressing, routing, and policy.

Follow one customer packet

Suppose an office sends to a remote content server:

1. The client sends the off-subnet packet to its local gateway.
2. Customer/provider access delivers it to the appropriate routed service.
3. The provider looks up the destination using selected routes.
4. Provider transport carries it toward an exit.
5. The exit forwards toward an accepted peer or transit next hop.
6. Remote routing delivers it toward the server.

The return path can use a different provider or exit. Asymmetry is not inherently an error. Firewalls, translation state, filtering, or a missing return route can still make asymmetric traffic fail in a specific design.

The packet does not need to carry a list of ASNs. AS_PATH is information in BGP advertisements used to calculate forwarding choices; the ordinary customer IP header carries source and destination addresses.

Diagnose interconnection failures

If an office reaches the provider gateway but not a remote server, check the selected destination route, next-hop resolution, external session/policy, and return reachability. If only one remote prefix fails, a complete access outage is less likely than a prefix-specific routing or service issue.

If a BGP session over an IXP is Established but routes are absent, inspect negotiated address families, import policy, and advertisements. If routes exist but traffic fails, inspect the forwarding next hop, interface/SAP/VLAN state, filters, and counters.

This reasoning prevents conflating the physical interconnection site, the shared Ethernet exchange, the BGP control session, and the customer's data path. They are connected dependencies with different operational evidence.

Primary references

AS creation and registration guidance, IANA ASN registry, and Nokia course outline, checked October 20, 2026.