We begin our tour of the TCP/IP stack at the bottom, with the layer that almost never shows up in application diagrams but without which not a single bit moves: the network access layer. In OSI it was two layers (physical and data link, which you studied in 03-02 and 03-03); TCP/IP merges them into one and, above all, deliberately leaves it open: it doesn't dictate what it must look like, it only demands that it be able to carry IP packets to the next hop. This lesson explains that design decision and, more importantly, teaches you to see and handle the layer on a real system: network interfaces, their state, their MTU, and how they take shape in the Valencia router. It matters because interfaces are the stack's physical boundary: when something "has no network", the first thing a professional checks is this layer.

1. What the network access layer bundles together
2. Why TCP/IP leaves it "open": IP over anything
3. Network interfaces: the layer made into an object
4. Interfaces in practice: ip link and friends
5. The MTU: a property of each interface
6. Meridiano case: the Valencia router's interfaces

The network access layer (also called the link layer, TCP/IP's link layer, or the network interface layer, depending on the book) gathers everything needed to deliver an IP packet to the next device along the path, within a single link:

• The physical part (03-02): media, signals, encoding, connectors — Marta's Cat 6 cable, the carrier's fiber, the waves from the Wi-Fi access point.
• The data link part (03-03): frames, MAC addresses, medium access, error detection with FCS, VLANs.
• And the glue between IP and the link: ARP (02-02), which translates the next hop's IP into the MAC the frame should be addressed to.

We won't repeat any of that — you already master it. What changes here is the point of view: to TCP/IP, that entire world is a single service with a minimal contract:

"Give me an IP packet and the next hop's IP, and I will deliver it over this link. How I do it is my business."

That is why many RFCs don't even detail this layer: each technology (Ethernet, Wi-Fi, PPP...) has its own standard, and TCP/IP only defines how to fit IP on top of each one (there is literally an RFC for "IP over Ethernet", another for "IP over Wi-Fi", and even a humorous one for "IP over carrier pigeons" — RFC 1149, published on an April 1st, which says a lot about the community's pragmatic, humorous spirit).

Remember the hourglass waist from 04-01: below IP there can be any technology. That is no accident — it is the founding requirement: TCP/IP was born to interconnect heterogeneous networks (cable, radio, satellite), so it couldn't marry any of them.

The practical consequence shows up in a single workday at Meridiano:

And if Marta works from the train tethering her phone's 4G/5G, her packet begins its life over cellular radio and ends it over Ethernet — without any application or upper-layer protocol changing so much as a comma. The network access layer is renewed at every hop; IP crosses it whole. That is the division of labor: the access layer solves "the next meter" and the Internet layer (next lesson) solves "the whole journey".

If in module 3 layers 1 and 2 were concepts, on a real system the network access layer is touched through a concrete object: the network interface. An interface is the point through which the operating system's TCP/IP stack connects to a link. It can be:

• Physical: an Ethernet card, a Wi-Fi adapter. It has a factory-assigned MAC, a cable or an antenna.
• Virtual: created by software. The most common:
  • Loopback (lo, the famous 127.0.0.1): the interface the machine uses to talk to itself; it never touches any cable.
  • Tunnel interfaces (VPN): Meridiano's VPN appears on each router as just another interface, even though underneath there is no cable of its own but encrypted packets traveling across the Internet.
  • VLAN subinterfaces: a physical interface can be logically split (one per VLAN).

The key idea for your mental model: to the upper layers, all interfaces are equal. The routing table (we'll see it in 04-03) decides "this packet goes out through this interface", and it couldn't care less whether that interface is an Ethernet card or a VPN tunnel. The interface is the boundary of the stack: above it, everything is kernel software; below it, driver, hardware and medium.

On Linux (like the intranet server), the modern tool is the ip command. Its link subcommand operates exactly at the network access layer — links, not IP addresses.

Let's read it line by line, because every field tells a story:

• 1: / 2: — the interface index (an internal kernel number).
• lo / enp3s0 — the interface name. lo is the loopback. enp3s0 follows modern Linux's predictable naming scheme: en = Ethernet, p3s0 = physical position on the board (PCI bus 3, slot 0). You will also see eth0 (the classic scheme), wlan0/wlp2s0 (Wi-Fi, wl = wireless LAN), tun0/wg0 (VPN tunnels). On Windows, the names are descriptive: "Ethernet", "Wi-Fi", and you list them with ipconfig /all.
• <BROADCAST,MULTICAST,UP,LOWER_UP> — capabilities and state. The two that matter for diagnosis:
  • UP: the interface is administratively enabled (someone turned it on in configuration).
  • LOWER_UP: there is a carrier signal — the physical level detects a link (cable plugged into a powered-on switch, Wi-Fi associated). It is the equivalent of the link LED we talked about in 03-02.
• mtu 1500 — covered in the next section.
• state UP — an operational summary of the state.
• link/ether aa:bb:cc:00:10:10 — the interface's MAC address (02-02); brd ff:ff:... is the link's broadcast address.

The combination of the two state flags is a mini diagnostic table in its own right:

Two basic administrative operations (they require privileges):

This is the first thing to check when a machine "has no network": before suspecting IP, DNS or the server, verify the interface exists, is UP and has LOWER_UP. If this layer fails, everything above fails — the vertical-dependency lesson you already know from OSI, applied to the real world.

In 03-04 you met the MTU (Maximum Transmission Unit) when discussing fragmentation. Now we can pin it down precisely in the system: the MTU is a property of each interface, visible in the ip link output we just read.

• enp3s0: mtu 1500 — 1500 bytes is Ethernet's classic MTU: the biggest IP packet that fits in one frame.
• lo: mtu 65536 — the loopback has no real physical medium, so it can afford enormous frames.
• A VPN tunnel interface usually shows a smaller MTU (e.g. 1400-1460): the tunnel adds its own headers to the packet, and that overhead has to be subtracted from the 1500 of the real link the tunnel travels over.

Each interface can have a different MTU, and the kernel respects it when building packets that leave through it. What happens when a packet is bigger than the path's MTU — and why Meridiano's VPN is exactly where this bites — we will see in the next lesson, because the reaction (fragmenting or reporting back) is the Internet layer's job. For now, keep the division of labor: the interface declares the limit; the Internet layer decides what to do about it.

Routers are the best place to see that "interface" is this layer's central concept, because they have several, of different kinds. The Valencia router (192.168.10.1) conceptually has these:

• lan0 — physical interface toward the office switch. It is the default gateway every machine in Valencia has configured (192.168.10.1). Through it come the frames of the corporate VLAN 10 (and, per the design from 03-03, the guest VLAN 20's traffic arrives tagged over the same trunk link).
• wan0 — physical interface toward the carrier. Different technology (fiber), a public IP address, the outside world.
• tun0 — the virtual VPN tunnel interface toward Bilbao. To the router's routing table it is an interface like any other ("to reach 192.168.20.0/24, go out through tun0"), but it has no cable of its own: every packet that "leaves" through tun0 is encrypted and forwarded inside normal packets that leave through wan0. It is the materialization — now with its technical name — of the conceptual VPN from module 1; and note its reduced MTU.

The Bilbao router (192.168.20.1) is its mirror image: its lan0 toward Jon's switch, its wan0 toward its carrier and its tun0 pointing at Valencia. When we read routing tables in 04-03, these interfaces will be the final column of every route: every routing decision ends in a "go out through this interface".

• Confusing "no cable" with "disabled". UP without LOWER_UP = physical problem (cable, switch port, Wi-Fi association); interface in DOWN = someone switched it off in software. The treatment is completely different: in the first case you check hardware, in the second, configuration.
• Believing a virtual interface is "less real". To the stack, tun0 is as much an interface as lan0: it has state, an MTU and routes that leave through it. Half of all VPN problems are diagnosed exactly like those of a physical card: is the interface up? what MTU does it have? are there routes using it?
• Looking for eth0 on a modern Linux and concluding "there is no network". Predictable names (enp3s0, wlp2s0) baffled an entire generation of administrators. Always list with ip link show instead of assuming names.
• Forgetting that Wi-Fi and Ethernet are the same layer but not the same link. A laptop with both cable and Wi-Fi active has two interfaces, each with its own MAC, its own state and potentially its own network. Many a "it's slow" is explained by traffic leaving through the interface you didn't expect.
• Touching the MTU without a reason. The default MTU (1500 on Ethernet) is correct almost always. Adjusting it only makes sense in specific scenarios like tunnels — and even then, better after understanding the next lesson.
• Tip: faced with "I have no network", diagnose bottom-up starting here: ip link (interface UP and with carrier?) before ip addr, before ping, before blaming the server. It will save you hours.

On the intranet server, a junior administrator runs ip link show and gets:

Users report the intranet is not responding. (a) Is the interface administratively enabled? (b) What does NO-CARRIER (the absence of LOWER_UP) indicate? (c) What are the two most likely physical checks that will resolve the case?

Jon, from Bilbao, downloads a document from the .10 server over the VPN. List, in order, the interfaces (with their type: physical LAN, physical WAN or virtual tunnel) through which the request packet leaves along its journey: Jon's PC → Bilbao router → Valencia router → server. How many distinct frames, at a minimum, will that single IP packet have been encapsulated in?

The Valencia router's tun0 interface shows mtu 1436 while wan0 shows mtu 1500. Explain in your own words why the tunnel's MTU is smaller, and what the 64-byte difference roughly represents.

Exercise 1: (a) Yes: the UP flag is present, so it is administratively enabled (the final state DOWN reflects the operational state, not the administrative one). (b) NO-CARRIER means there is no physical signal: the card detects no link at the other end of the cable. (c) Check the cable between the server and the switch (unplugged or damaged) and the switch port (off, faulty or disabled). There is no point checking IP, DNS or the web service until the carrier signal is back: with no access layer, nothing above works.

Exercise 2: The packet's exits: (1) the physical Ethernet interface of Jon's PC toward the Bilbao switch; (2) at the Bilbao router, the routing decision sends it out the virtual tunnel interface (tun0) — and the resulting encrypted packet physically leaves through its physical WAN interface toward the carrier; (3) at the Valencia router, after decryption, it leaves through its physical LAN interface toward the switch and the .10 server. Distinct frames: at least three visible to Meridiano (Ethernet on the Bilbao LAN, the carrier's WAN link, Ethernet on the Valencia LAN) — and in reality more, because inside the Internet every hop between the carrier's routers re-encapsulates again. The original IP header (protected inside the tunnel) survives intact; the frames are renewed on every link.

Exercise 3: Packets that "leave" through tun0 don't travel alone: the tunnel encrypts them and wraps them with extra headers (the VPN protocol's plus the new outer IP/transport headers), and the result must still fit within the 1500-byte MTU of the real link (wan0). The ~64 bytes of difference are, roughly, that tunnel encapsulation overhead. If tun0 kept an MTU of 1500, every large packet would exceed 1500 once wrapped, forcing fragmentation or losses — the kind of problem we will analyze in the next lesson.

The network access layer is TCP/IP's great "open container": it bundles the physical and data link worlds you already studied, and deliberately refuses to impose a technology so that IP can travel over Ethernet, Wi-Fi, fiber or 5G interchangeably — renewed at every hop while the packet crosses it whole. In practice, this layer is seen and administered through interfaces: physical or virtual, each with its name, its MAC, its state (UP/LOWER_UP) and its MTU, and the Valencia router's (lan0, wan0, tun0) sum up their variety nicely. With the bottom boundary of the stack mastered, we climb one rung to the layer that turns many loose links into a single worldwide network: the Internet layer, home to IP, ICMP and — now for real, line by line — the routing tables.