On Linux, what is a veth device, why is it always created as a pair, and what happens when you attach one end of that pair to a Linux bridge device?

## The device `veth` stands for virtual Ethernet. It is a kernel network device whose defining property is that it does not exist alone: creation always yields two devices linked back to back, and iproute2 shows the relationship in the name, printing an end as something like `veth0@if12` where the number is the peer's interface index. ```bash ip link add veth0 type veth peer name veth0-br ``` The semantics are the simplest in the whole stack: a frame transmitted on one end is delivered to the receive path of the other, immediately, in the kernel. No wire, no encapsulation, no addressing decision. It behaves like a crossover cable soldered between two NICs. Delete one end and the other goes with it, because there is no meaningful half of a cable. Both ends behave like ordinary Ethernet devices in every other respect. Each gets a MAC address, each can carry IP addresses, each has an MTU you can set, each shows up with flags and an operational state. And critically, each can be **moved into a different network namespace**, which is the reason the device type exists: it is the standard way to give an isolated network environment a link back to somewhere else. One end stays in the host, the other is pushed into the isolated environment and renamed to something conventional. ## The bridge A veth pair by itself connects exactly two things. To connect many, you need a switch, and Linux has one built in: the bridge device. ```bash ip link add br0 type bridge ip link set veth0-br master br0 ``` A bridge is a layer-2 switch implemented in the kernel. Devices enslaved to it become its **ports**. Its behaviour is textbook switching: - **Learning.** When a frame arrives on a port, the bridge records the source MAC address against that port in its forwarding database. Entries age out after an inactivity timeout, so the topology can change without manual intervention. - **Forwarding.** A frame whose destination MAC is in the database is sent out that one port only. - **Flooding.** Broadcast frames, multicast, and unicast frames for an address not yet learned are sent to every port except the one they came in on. The bridge device itself is also a network device you can address. That is a distinction worth stating clearly: the *ports* are switch ports and do the layer-2 work; if the host needs an IP presence on that segment, you put the address on `br0` rather than on the enslaved port. An address left on a port that is enslaved will not participate in bridged forwarding the way people expect, and it is a frequent source of confusion. One consequence: enslaving an interface that currently carries the host's only address will cut you off, because the address is no longer where the traffic goes. Moving a physical NIC into a bridge is therefore a classic way to lock yourself out of a remote machine, and should be done as a single atomic reconfiguration. ## Putting the two together The standard topology is: one veth end inside the isolated environment with an address, the other end enslaved to a bridge in the host, and the bridge carrying the gateway address for that segment. Every isolated environment gets its own pair, all host-side ends land on the same bridge, and the bridge switches between them. From the kernel's point of view this is a perfectly ordinary Ethernet segment that happens to have no cables in it. This is the primitive that container and virtual-machine networking on Linux is assembled from, but the primitive itself is just a switch and some patch cables. ## The failure everyone hits first Both ends of a veth pair must be administratively up. Bring up only one and the pair has no carrier: the up end reports no carrier or an operational state of `LOWERLAYERDOWN`, because a veth's carrier is defined by its peer being up. The same applies to the bridge device — a bridge with no up ports has nothing to carry traffic. The symptom is an interface that looks configured, has an address, and passes nothing at all, which is why "did you bring up *both* ends?" is the first question to ask of any hand-built veth topology. A second gotcha is MTU. The bridge takes the smallest MTU among its ports, so one port left at a smaller MTU quietly constrains the whole segment. ## What an interviewer is testing Whether you understand these as kernel objects rather than as features of a product. Someone who has only used higher-level tooling will describe what a network *does*; someone who has built one by hand will describe the pair semantics, the enslavement, the learning table and the both-ends-up requirement — and will therefore be able to debug the topology when the tooling that normally builds it goes wrong.