How Packet Switching Works at Layer 2 and Well-Known Ports

Posted on by

Packet switching works by breaking application data into units that can move independently across networks. On a typical web request, the browser’s data is carried in a TCP segment or UDP datagram, wrapped in an IP packet, then placed inside an Ethernet frame for delivery on the local link. Switches use MAC addresses to move frames across Layer 2, while routers use IP addresses to choose the next hop. TCP and UDP port numbers identify the service at the destination, but they do not belong in the Ethernet header.

A clear way to follow the data is to trace one request end to end: a client may first use DNS on UDP port 53 to find a server, then connect to the website on TCP port 443. The DNS and HTTPS port numbers travel in the transport layer header, not in Layer 2, so the frame format, the MAC addresses, and the switching decision stay separate from service identification.

From application data to frames and packets

Application data starts at the top of the stack, such as a browser request for a web page, an email message, or a DNS lookup. Before that data leaves the host, each lower layer adds its own header so the next device knows what to do with it.

At the transport layer, TCP or UDP adds port numbers. The destination port tells the receiving host which process should handle the data. For example, a browser session may use destination port 443 for HTTPS, while a DNS query uses destination port 53. The source port is usually ephemeral and lets the reply return to the correct application.

At the network layer, IP adds the source and destination IP addresses. That lets routers move the packet across multiple networks. The packet can cross many links, but the IP addresses stay meaningful from sender to receiver, aside from changes such as TTL being reduced at each router.

At Layer 2, Ethernet adds a frame header and trailer for the local link:

  • Destination MAC address identifies the next local device that should receive the frame.
  • Source MAC address identifies the interface that sent it on that link.
  • EtherType signals what the payload carries, such as IPv4 or IPv6.
  • FCS trailer provides error detection for the frame.

This encapsulation is the key to understanding how does packet switching work: the same application message is carried inside headers that serve different scopes. Ports answer “which application?” IP answers “which host and network?” MAC addresses answer “which device on this link?”

What Layer 2 of the OSI model does on the local link

Layer 2 of the OSI model handles delivery within a single local network segment. It is responsible for turning network-layer packets into frames, moving those frames across a shared medium or switched Ethernet, and checking whether the frame arrived intact.

Its main functions are practical rather than global:

  • Framing wraps Layer 3 packets in a format that can cross the local link.
  • MAC addressing identifies the sender and the next local receiver.
  • Media access coordinates use of the link so devices can transmit in an orderly way.
  • Error detection uses the frame check sequence to detect corruption.
  • Local delivery gets the frame to the correct interface on the same LAN.

A Layer 2 switch works by reading the destination MAC address in the frame header and forwarding the frame out the correct port. It learns which MAC addresses are reachable on which switch ports by watching source MAC addresses in incoming frames. If it already knows the destination MAC, it sends the frame only where it needs to go. If it does not know the destination yet, it may flood the frame within the VLAN until the address is learned.

Switching is not the same as routing. A switch forwards frames at Layer 2 based on MAC addresses. A router forwards packets at Layer 3 based on IP addresses and a routing table. Keeping those jobs separate is essential to understanding packet movement.

Layer 2 also provides the first line of error handling on the local link. If the FCS does not match, the frame is considered damaged and is dropped. The receiving device does not try to repair the frame at Layer 2; higher layers rely on retransmission or recovery if needed.

How packet switching works, hop by hop

Packet switching means the network carries data as discrete packets that are forwarded one hop at a time rather than reserved on a fixed circuit. Each hop examines the information relevant to that layer and passes the packet onward.

Consider a browser opening https://example.com:

  1. The browser creates application data and, before the web connection begins, may send a DNS query using UDP to destination port 53.
  2. The host wraps that query in an IP packet addressed to the DNS server.
  3. The host then places the packet in an Ethernet frame addressed to the MAC address of the default gateway if the DNS server is off-net.
  4. A switch on the local LAN forwards the frame using the destination MAC address.
  5. The router receives the frame, checks the FCS, strips the Ethernet header and trailer, and examines the IP packet.
  6. The router decrements TTL, consults its routing table, and chooses the next hop toward the destination network.
  7. The router re-encapsulates the same IP packet in a new Layer 2 frame for the outgoing link, with new source and destination MAC addresses appropriate for that link.
  8. That process repeats at each router until the packet reaches the destination network.

This is where IP forwarding and re-encapsulation matter. The packet keeps its end-to-end IP addresses while the Layer 2 frame changes at every link. The router does not keep the original Ethernet header, because that header only makes sense on the local segment that just handled the frame.

At the final hop, the destination router or the last switch places the packet into a frame addressed to the server’s MAC address. The server receives the frame, verifies the FCS, removes the Ethernet header, reads the IP header, and then checks the TCP or UDP header. Only at that point do the port numbers matter for handing the data to the correct service process.

If the connection uses HTTPS, the server sees destination TCP port 443 and sends the data to the HTTPS listener. If the earlier DNS query used UDP port 53, the DNS server delivers that datagram to its DNS service. The port number identifies the service, but the Ethernet frame still only needed MAC addresses and an EtherType.

Which well-known TCP and UDP ports you see most often

Well-known ports are the standardized service ports most often used by servers. They live in the transport layer, not in Layer 2. A switch cannot forward a frame based on port 443, because the port number is not in the Ethernet header at all.

Common examples include:

  • TCP 20/21 — FTP data and control
  • TCP 22 — SSH
  • TCP 23 — Telnet
  • TCP 25 — SMTP
  • UDP 53 — DNS queries and many DNS replies
  • TCP 53 — DNS over TCP, often for large responses or zone transfers
  • UDP 67/68 — DHCP server and client
  • TCP 80 — HTTP
  • UDP 123 — NTP
  • TCP 110 — POP3
  • TCP 143 — IMAP
  • UDP 161/162 — SNMP and SNMP traps
  • TCP 443 — HTTPS
  • UDP 514 — Syslog in many deployments

These ports help a host choose the right application after the packet reaches the destination machine. They do not guide Ethernet switching, and they are not visible in the Layer 2 frame header. The frame only carries the next-hop MAC addresses, the payload type, and the integrity check.

In practice, a client often combines both transport protocols in a single workflow: DNS over UDP 53 to find the server, then HTTPS over TCP 443 to exchange web data. The packets may travel through several routers, but the port numbers stay in the transport header while the MAC addresses change from hop to hop.