An access port hands a device plain, untagged Ethernet frames and quietly does the VLAN bookkeeping itself. A trunk port carries several VLANs over one wire at once — and the only way to keep them straight is to tag every frame.
Every switch port has to be configured one of two fundamental ways, and the choice isn't cosmetic — it determines what kind of Ethernet frames that port is willing to send and receive. This explainer builds directly on the companion piece on broadcast vs. collision domains — VLANs are exactly the tool that segments one large broadcast domain into several smaller ones, and access ports and trunk ports are how a switch actually attaches devices to, and carries traffic between, those VLANs.
An access port is a switch port configured to belong to exactly one VLAN. Plug a standard workstation, a printer, or (in a simple configuration) an access point into it, and that device sends and receives completely ordinary, untaggedEthernet frames — frames with no VLAN information in them at all. The device has no idea a VLAN exists. It just does what every Ethernet NIC has always done: frame the data and put it on the wire. The switch is the one doing the work — internally, it associates that physical port (and therefore every untagged frame that arrives on it) with whichever VLAN the port was assigned to. The VLAN membership lives entirely in the switch's configuration, not in anything the connected device transmits.
A trunk port is configured to carry traffic for multiple VLANs simultaneously over a single physical link. That immediately raises a problem an access port never has: if VLAN 10's and VLAN 20's frames are both riding the same physical wire, how does the switch on the other end know which frame belongs to which VLAN? The answer is VLAN tagging, almost always IEEE 802.1Q: as a frame crosses the trunk link, a small VLAN tag is inserted into it identifying which VLAN it belongs to, and the receiving device reads that tag to sort the frame into the right VLAN on arrival. Trunk ports are the standard choice for switch-to-switch links, switch-to-router links (used for inter-VLAN routing), and links to any device that is itself VLAN-aware — a hypervisor host running several VLAN-tagged virtual machines, or an access point mapping multiple SSIDs to different VLANs, for example.
An access port never needs a tag, because there's only one possible answer to "which VLAN is this frame for" — whatever VLAN the port is assigned to. The switch already knows, so it doesn't need the frame to say. A trunk port has no such luxury: with several VLANs' frames interleaved on the same physical link, the receiving end has no way to tell them apart unless something in the frame itself says which VLAN it belongs to. 802.1Q tagging is exactly that something — a small field inserted into the Ethernet frame carrying the VLAN ID, added the instant a frame enters the trunk and read (then stripped back out, if the destination is itself an access port) the instant it leaves. Every device sitting on either end of a trunk link — a switch, a router sub-interface, a hypervisor, an access point — has to understand that tagging scheme, or the whole arrangement falls apart.
False, and the failure mode is immediate rather than subtle. A standard end-user device — a normal PC, a printer, anything with no VLAN awareness — has no idea how to interpret an 802.1Q tag. Plug it into a trunk port instead of an access port and it starts receiving tagged frames it simply doesn't understand; depending on the device and driver, it either fails to communicate at all or behaves unpredictably. That's exactly why standard end-user devices belong on access ports, which quietly handle the VLAN association for them and hand them nothing but plain, untagged frames. The mistake runs the other way too: connect a switch-to-switch link — which needs to carry several VLANs — to an accessport instead of a trunk, and that link can now carry exactly one VLAN. Every other VLAN that was supposed to cross that link loses connectivity, full stop. Matching port type to what's actually plugged in on each end isn't a style choice — it's a required configuration step, and getting it backwards produces a real, predictable outage rather than a merely suboptimal setup.
Explains the difference between an access port (a switch port assigned to exactly one VLAN, sending and receiving plain untagged Ethernet frames to devices with no VLAN awareness of their own) and a trunk port (a switch port carrying multiple VLANs over a single physical link, using IEEE 802.1Q tagging so both ends can tell which frame belongs to which VLAN) — and why plugging the wrong device type into the wrong port configuration causes real, predictable connectivity failures.
An access port is statically assigned to a single VLAN in the switch's configuration. Any device connected to it — a workstation, a printer, an access point in a simple deployment — sends and receives ordinary, untagged Ethernet frames, exactly as it would on any non-VLAN network. The device itself has zero VLAN awareness; it doesn't add anything to the frame to indicate a VLAN, because it doesn't know VLANs exist. All of the VLAN bookkeeping happens inside the switch: the moment an untagged frame arrives on that port, the switch internally treats it as belonging to whatever VLAN the port is assigned to, and forwards it accordingly.
A trunk port is configured to carry traffic for multiple VLANs simultaneously over one physical link — typically a switch-to-switch link, a switch-to-router link used for inter-VLAN routing, or a link to a VLAN-aware device like a hypervisor host or a multi-SSID access point. Because several VLANs' frames share the same wire, something has to identify which VLAN each frame belongs to. That something is VLAN tagging, almost always IEEE 802.1Q: a small tag identifying the VLAN ID is inserted into each frame as it enters the trunk, and the receiving end reads that tag to sort the frame back into the correct VLAN.
A standard end-user device has no idea how to interpret an 802.1Q tag. If it's connected to a trunk port, it starts receiving tagged frames it can't parse, and — depending on the specific device and network stack — either fails to communicate at all or behaves unpredictably. That's why standard devices must connect to access ports, which handle VLAN association invisibly and only ever hand the device plain, untagged frames. The failure runs the other direction too: a switch-to-switch (or switch-to-router) link that's supposed to carry several VLANs cannot do so if it's configured as an access port, since an access port only ever carries one VLAN — every other VLAN that needed to cross that link loses connectivity entirely.
Access ports are the default for end-user connections: desks, printers, single-SSID access points, IP phones (often paired with a voice VLAN using a special tagging arrangement on an otherwise-access port). Trunk ports are the default for the links that tie the switching infrastructure together: switch-to-switch uplinks, links to a router or Layer 3 switch performing inter-VLAN routing, and links to virtualization hosts running VMs across several VLANs. Misconfiguring either direction — an access port where a trunk is needed, or a trunk where an access port is needed — is one of the most common root causes of "this one link/device just won't talk to the network" tickets.
Not in the same configuration — a port is either an access port (one VLAN, untagged) or a trunk port (multiple VLANs, tagged), and switch configuration explicitly sets one mode or the other. The one common exception is a "voice VLAN" on an access port for IP phones, where the port stays an access port for the connected PC's untagged data traffic while also accepting a separately tagged VLAN for the phone's own voice traffic — a special case built for exactly that scenario, not a general trunk.
The laptop's NIC and OS have no support for interpreting 802.1Q tags in an incoming frame. Depending on the switch's native VLAN configuration and the device involved, the laptop may get no connectivity at all, or in some edge cases may only see traffic for whichever VLAN happens to be the trunk's untagged 'native VLAN' — either way, it will not function as if it were plugged into a correctly configured access port.
By default on many platforms, yes — a trunk port allows all VLANs unless it's explicitly restricted to a defined allowed list. In production networks, administrators typically prune the allowed VLAN list on each trunk to only the VLANs that actually need to cross that specific link, both for security and to reduce unnecessary broadcast traffic being trunked somewhere it doesn't need to go.
802.1Q is the open, IEEE-standard tagging method and is what virtually all modern equipment uses. Cisco's older proprietary ISL (Inter-Switch Link) protocol did the same job before 802.1Q became the near-universal standard, but it's obsolete on current hardware — any trunk port you configure today is functionally an 802.1Q trunk.
Because VLAN membership in this model is a property of the switch port, not the device. The switch alone decides which VLAN an access port's traffic belongs to, tracks it internally, and strips or adds nothing the device would ever notice. This is precisely what makes access ports simple to deploy — no configuration is required on the end device itself for VLAN membership to work correctly.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.