DEV Community

Cover image for How Switches and Routers Actually Work: The Three Tables That Run the Internet
AWS Community Builders profile image Stella Achar Oiro
Stella Achar Oiro for AWS Community Builders

Posted on

How Switches and Routers Actually Work: The Three Tables That Run the Internet

#aws #networking #cloudcomputing #devops

Yesterday, I explained the OSI model and why each layer matters for AWS.

Today, I show you what switches and routers actually do.

Here is what clicked for me, Networking is not magic. It comes down to three tables and three actions.

That is it.

Once you understand these tables, you understand how data flows from your laptop to AWS and back.

Let me show you.

The Two Fundamental Devices

Before we dive into how they work, you need to understand what they do.

Switches: Move data WITHIN networks

Your home Wi-Fi? That is a network. All your devices (laptop, phone, printer) connect through a switch (often built into your router). The switch handles communication between devices on the same network.

Routers: Move data BETWEEN networks

Your home network is separate from AWS's network. A router connects these different networks. When you access AWS, your data travels through multiple routers to get there.

Key Difference:

  • Switches operate at Layer 2 (MAC addresses)
  • Routers operate at Layer 3 (IP addresses)

AWS Equivalent:

  • Switches = Traffic within a subnet
  • Routers = VPC Route Tables moving traffic between subnets

Let me show you exactly how each one works.

How Switches Work

A switch has one job: Forward data to the correct device within a network.

Scenario:

Network: 10.1.1.0/24

         [SWITCH]
        /  |  |  \
       /   |  |   \
     A    B  C    D

Host A: MAC AA:AA, IP 10.1.1.10
Host B: MAC BB:BB, IP 10.1.1.20
Host C: MAC CC:CC, IP 10.1.1.30
Host D: MAC DD:DD, IP 10.1.1.40
Enter fullscreen mode Exit fullscreen mode

All four hosts connect to the same switch. They are all on the same network (10.1.1.x).

The MAC Address Table

Every switch maintains a MAC Address Table. This table maps switch ports to MAC addresses.

Initial State (Empty):

Port  |  MAC Address
------|-------------
(empty)
Enter fullscreen mode Exit fullscreen mode

The switch learns this table dynamically as traffic flows.

Three Switch Actions

Every switch performs exactly three actions. That is all.

1. LEARN

When a frame arrives on a port, the switch examines the source MAC address and updates its table.

2. FLOOD

When the switch does not know where the destination MAC address is, it sends the frame out all ports (except the incoming port).

3. FORWARD

When the switch knows where the destination MAC address is, it sends the frame only to that specific port.

Let me show you these actions in a real example.

Complete Example: Host A → Host D

Step 1: Host A Sends Frame

Host A wants to send data to Host D.

Frame arrives at switch on Port 1:

Layer 2 Header:
- Source MAC: AA:AA
- Destination MAC: DD:DD
Enter fullscreen mode Exit fullscreen mode

Step 2: Switch LEARNS

Switch sees frame arrived on Port 1 with Source MAC: AA:AA

MAC Address Table updates:

Port  |  MAC Address
------|-------------
1     |  AA:AA
Enter fullscreen mode Exit fullscreen mode

Step 3: Switch Checks Destination

Switch looks for DD:DD in its table.

Port  |  MAC Address
------|-------------
1     |  AA:AA
Enter fullscreen mode Exit fullscreen mode

DD:DD is not in the table.

Step 4: Switch FLOODS

Switch sends frame out all ports except Port 1:

  • Port 2 → Host B receives frame

    • Checks destination MAC: DD:DD
    • Not my MAC (BB:BB)
    • Discards frame

  • Port 3 → Host C receives frame

    • Checks destination MAC: DD:DD
    • Not my MAC (CC:CC)
    • Discards frame

  • Port 4 → Host D receives frame

    • Checks destination MAC: DD:DD
    • That is my MAC
    • Accepts and processes frame

The Return Journey: Host D → Host A

Host D sends response back to Host A.

Step 1: Host D Sends Frame

Frame arrives at switch on Port 4:

Layer 2 Header:
- Source MAC: DD:DD
- Destination MAC: AA:AA
Enter fullscreen mode Exit fullscreen mode

Step 2: Switch LEARNS

Switch sees frame arrived on Port 4 with Source MAC: DD:DD

MAC Address Table updates:

Port  |  MAC Address
------|-------------
1     |  AA:AA
4     |  DD:DD
Enter fullscreen mode Exit fullscreen mode

Step 3: Switch Checks Destination

Switch looks for AA:AA in its table.

Port  |  MAC Address
------|-------------
1     |  AA:AA  ← Found it
4     |  DD:DD
Enter fullscreen mode Exit fullscreen mode

AA:AA is on Port 1.

Step 4: Switch FORWARDS

Switch sends frame only to Port 1.

Hosts B and C do not receive this frame. The switch knows exactly where to send it.

Future Communication

All future communication between Host A and Host D is now efficient.

The switch knows both MAC addresses:

Port  |  MAC Address
------|-------------
1     |  AA:AA
4     |  DD:DD
Enter fullscreen mode Exit fullscreen mode

Every frame between A and D goes directly to the correct port. No flooding needed.

VLANs: Virtual Networks on One Switch

A VLAN (Virtual LAN) divides one physical switch into multiple isolated networks.

Example:

Physical Switch with 8 ports

VLAN 10 (Engineering):
- Ports 1, 2, 3, 4

VLAN 20 (Sales):
- Ports 5, 6, 7, 8
Enter fullscreen mode Exit fullscreen mode

How VLANs Work:

Each VLAN has its own MAC address table. Traffic in VLAN 10 cannot reach VLAN 20 (without a router).

VLAN 10 MAC Table:

Port  |  MAC Address
------|-------------
1     |  AA:AA
2     |  BB:BB
Enter fullscreen mode Exit fullscreen mode

VLAN 20 MAC Table:

Port  |  MAC Address
------|-------------
5     |  CC:CC
6     |  DD:DD
Enter fullscreen mode Exit fullscreen mode

Same three actions (Learn, Flood, Forward), just confined to specific ports.

AWS Equivalent:

VLANs are like subnets in a VPC. Each subnet isolates traffic. You need a router (or Route Table rules) to move traffic between subnets.

How Routers Work

A router has one job: Forward packets between different networks.

Scenario:

Network 1: 10.0.4.0/24    Network 2: 10.0.5.0/24    Network 3: 10.0.6.0/24

    Host A ←→ R1 ←→ R2 ←→ Host C

Host A:
- IP: 10.0.4.9
- MAC: AA:AA
- Gateway: 10.0.4.1

R1 (Router 1):
- Right interface: 10.0.4.1 (MAC: E4:E4)
- Left interface: 10.0.5.1 (MAC: E5:E5)

R2 (Router 2):
- Right interface: 10.0.5.2 (MAC: F5:F5)
- Left interface: 10.0.6.1 (MAC: F6:F6)

Host C:
- IP: 10.0.6.7
- MAC: CC:CC
- Gateway: 10.0.6.1
Enter fullscreen mode Exit fullscreen mode

Host A and Host C are on different networks. They need routers to communicate.

The Routing Table

Every router maintains a routing table. This table maps destination networks to next hop instructions.

R1's Routing Table:

Network         |  Next Hop
----------------|---------------------------
10.0.4.0/24     |  Directly Connected (right interface)
10.0.5.0/24     |  Directly Connected (left interface)
10.0.6.0/24     |  via 10.0.5.2 (R2)
Enter fullscreen mode Exit fullscreen mode

R2's Routing Table:

Network         |  Next Hop
----------------|---------------------------
10.0.5.0/24     |  Directly Connected (right interface)
10.0.6.0/24     |  Directly Connected (left interface)
10.0.4.0/24     |  via 10.0.5.1 (R1)
Enter fullscreen mode Exit fullscreen mode

Critical Point:

If a destination network is not in the routing table, the router drops the packet. The routing table must be populated before traffic flows.

Three Ways to Populate Routing Tables

1. Directly Connected

When you configure an IP address on a router interface, the router automatically adds that network to its routing table.

R1 configured with:
- Right interface: 10.0.4.1/24
- Left interface: 10.0.5.1/24

Routing table automatically includes:
10.0.4.0/24 → Directly Connected
10.0.5.0/24 → Directly Connected
Enter fullscreen mode Exit fullscreen mode

2. Static Routes

An administrator manually tells the router how to reach a network.

R1 manual configuration:
"To reach 10.0.6.0/24, send packets to 10.0.5.2"

Routing table now includes:
10.0.6.0/24 → Static, via 10.0.5.2
Enter fullscreen mode Exit fullscreen mode

3. Dynamic Routes

Routers automatically share network information with each other using routing protocols (OSPF, BGP, EIGRP).

R1 tells R2: "I know about 10.0.4.0/24"
R2 tells R1: "I know about 10.0.6.0/24"

Both routers update their tables automatically.
Enter fullscreen mode Exit fullscreen mode

AWS Equivalent:

VPC Route Tables work like routing tables. You populate them with:

  • Local routes (automatically added)
  • Static routes (you configure manually)
  • Dynamic routes (VPC peering, Transit Gateway)

Routers Also Have ARP Tables

Critical concept: Routers are just nodes with IP addresses.

Just like hosts, routers use ARP to map IP addresses to MAC addresses.

R1's ARP Table (initially empty):

IP Address  |  MAC Address
------------|-------------
(empty)
Enter fullscreen mode Exit fullscreen mode

R2's ARP Table (initially empty):

IP Address  |  MAC Address
------------|-------------
(empty)
Enter fullscreen mode Exit fullscreen mode

Routers populate ARP tables dynamically as needed, just like hosts do.

Complete Packet Flow: Host A → Host C

Now let me show you every step as a packet travels from Host A to Host C through two routers.

Step 1: Host A Prepares Packet

Host A has data for Host C (10.0.6.7).

Create Layer 3 header:

Source IP: 10.0.4.9 (Host A)
Destination IP: 10.0.6.7 (Host C)
Enter fullscreen mode Exit fullscreen mode

Host A determines: Destination is foreign (10.0.6.x not equal to 10.0.4.x)

Must send to default gateway: 10.0.4.1 (R1)

Step 2: Host A ARPs for Gateway

Host A does not know the gateway's MAC address.

ARP Request:

Who has 10.0.4.1?
Tell 10.0.4.9 at MAC: AA:AA
Enter fullscreen mode Exit fullscreen mode

R1 receives and responds:

10.0.4.1 is at MAC: E4:E4
Enter fullscreen mode Exit fullscreen mode

Host A updates ARP table:

10.0.4.1 → E4:E4
Enter fullscreen mode Exit fullscreen mode

Step 3: Host A Sends Packet to R1

Complete packet:

[Layer 2: AA:AA → E4:E4]          (to R1)
[Layer 3: 10.0.4.9 → 10.0.6.7]    (end-to-end)
[DATA]
Enter fullscreen mode Exit fullscreen mode

Packet travels to R1.

Step 4: R1 Processes Packet

R1 receives packet on right interface.

Action 1: Remove Layer 2 header (purpose complete: reached R1)

Action 2: Check routing table

Destination IP: 10.0.6.7
Which network? 10.0.6.0/24

Routing table match:
10.0.6.0/24 → via 10.0.5.2 (R2)
Enter fullscreen mode Exit fullscreen mode

Next hop IP: 10.0.5.2

Action 3: Need new Layer 2 header

Source MAC: E5:E5 (R1's left interface)
Destination MAC: ??? (need R2's MAC)
Enter fullscreen mode Exit fullscreen mode

Problem: R1 does not know R2's MAC address.

Step 5: R1 ARPs for R2

ARP Request:

Who has 10.0.5.2?
Tell 10.0.5.1 at MAC: E5:E5
Enter fullscreen mode Exit fullscreen mode

R2 receives and responds:

10.0.5.2 is at MAC: F5:F5
Enter fullscreen mode Exit fullscreen mode

R1 updates ARP table:

10.0.5.2 → F5:F5
Enter fullscreen mode Exit fullscreen mode

Step 6: R1 Forwards to R2

Packet with new Layer 2 header:

[Layer 2: E5:E5 → F5:F5]          (R1 to R2)
[Layer 3: 10.0.4.9 → 10.0.6.7]    (SAME)
[DATA]
Enter fullscreen mode Exit fullscreen mode

Notice: Layer 3 header never changed.

Packet travels to R2.

Step 7: R2 Processes Packet

R2 receives packet on right interface.

Action 1: Remove Layer 2 header (purpose complete: reached R2)

Action 2: Check routing table

Destination IP: 10.0.6.7
Which network? 10.0.6.0/24

Routing table match:
10.0.6.0/24 → Directly Connected (left interface)
Enter fullscreen mode Exit fullscreen mode

This is the final hop.

Action 3: Need new Layer 2 header

Source MAC: F6:F6 (R2's left interface)
Destination MAC: ??? (need Host C's MAC)
Enter fullscreen mode Exit fullscreen mode

Problem: R2 does not know Host C's MAC address.

Step 8: R2 ARPs for Host C

ARP Request:

Who has 10.0.6.7?
Tell 10.0.6.1 at MAC: F6:F6
Enter fullscreen mode Exit fullscreen mode

Host C receives and responds:

10.0.6.7 is at MAC: CC:CC
Enter fullscreen mode Exit fullscreen mode

Host C also learns from the request and updates its ARP table:

10.0.6.1 → F6:F6
Enter fullscreen mode Exit fullscreen mode

R2 updates ARP table:

10.0.6.7 → CC:CC
Enter fullscreen mode Exit fullscreen mode

Step 9: R2 Delivers to Host C

Final packet:

[Layer 2: F6:F6 → CC:CC]          (R2 to Host C)
[Layer 3: 10.0.4.9 → 10.0.6.7]    (SAME)
[DATA]
Enter fullscreen mode Exit fullscreen mode

Packet travels to Host C.

Step 10: Host C Processes Packet

Host C receives packet:

  1. Remove Layer 2 header (arrived at correct NIC)
  2. Remove Layer 3 header (arrived at correct host)
  3. Process DATA

Return Traffic: Host C → Host A

Good news: All ARP tables now populated. Much faster journey back.

Host C Sends Response

[Layer 2: CC:CC → F6:F6]          (to R2)
[Layer 3: 10.0.6.7 → 10.0.4.9]    (response)
[DATA]
Enter fullscreen mode Exit fullscreen mode

R2 Processes

Remove Layer 2 header.

Check routing table: Destination 10.0.4.9 matches 10.0.4.0/24 via 10.0.5.1

Already has ARP for 10.0.5.1 → E5:E5

Create new Layer 2 header immediately:

[Layer 2: F5:F5 → E5:E5]
[Layer 3: 10.0.6.7 → 10.0.4.9]
[DATA]
Enter fullscreen mode Exit fullscreen mode

Send to R1.

R1 Processes

Remove Layer 2 header.

Check routing table: Destination 10.0.4.9 matches 10.0.4.0/24 Directly Connected

Already has ARP for 10.0.4.9 → AA:AA

Create new Layer 2 header immediately:

[Layer 2: E4:E4 → AA:AA]
[Layer 3: 10.0.6.7 → 10.0.4.9]
[DATA]
Enter fullscreen mode Exit fullscreen mode

Send to Host A.

Host A Processes

Remove Layer 2 header. Remove Layer 3 header. Process response data.

Key Observations

1. Layer 3 Header Never Changes

Throughout entire journey:

Source IP: 10.0.4.9 (Host A)
Destination IP: 10.0.6.7 (Host C)
Enter fullscreen mode Exit fullscreen mode

Constant from start to finish. This is end-to-end delivery (Layer 3's job).

2. Layer 2 Header Changes at Every Hop

Hop 1: Host A → R1

Layer 2: AA:AA → E4:E4
Enter fullscreen mode Exit fullscreen mode

Hop 2: R1 → R2

Layer 2: E5:E5 → F5:F5
Enter fullscreen mode Exit fullscreen mode

Hop 3: R2 → Host C

Layer 2: F6:F6 → CC:CC
Enter fullscreen mode Exit fullscreen mode

This is hop-to-hop delivery (Layer 2's job).

3. Every Router Follows Same Process

  1. Remove old Layer 2 header (hop complete)
  2. Check routing table (where does this go?)
  3. Determine next hop IP (from routing table)
  4. ARP if needed (get next hop MAC)
  5. Create new Layer 2 header (for next hop)
  6. Forward packet

This process repeats at every router across the entire internet.

The Three Critical Tables

Understanding data flow equals understanding these three tables:

1. MAC Address Table (Switches)

Port → MAC Address mapping
Enter fullscreen mode Exit fullscreen mode

Actions: Learn, Flood, Forward

Purpose: Move data within networks

2. ARP Table (Hosts and Routers)

IP Address → MAC Address mapping
Enter fullscreen mode Exit fullscreen mode

Purpose: Resolve next hop MAC addresses

Populated: Dynamically as needed

3. Routing Table (Routers)

Network → Next Hop mapping
Enter fullscreen mode Exit fullscreen mode

Purpose: Determine packet path

Populated: Directly connected, static, dynamic

AWS VPC Route Tables

AWS VPC Route Tables work exactly like router routing tables.

Example VPC Configuration:

import boto3

ec2 = boto3.client('ec2')

# Create VPC
vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16')
vpc_id = vpc['Vpc']['VpcId']

# Create public subnet
public_subnet = ec2.create_subnet(
    VpcId=vpc_id,
    CidrBlock='10.0.1.0/24',
    AvailabilityZone='us-east-1a'
)
public_subnet_id = public_subnet['Subnet']['SubnetId']

# Create private subnet
private_subnet = ec2.create_subnet(
    VpcId=vpc_id,
    CidrBlock='10.0.2.0/24',
    AvailabilityZone='us-east-1a'
)
private_subnet_id = private_subnet['Subnet']['SubnetId']

# Create Internet Gateway
igw = ec2.create_internet_gateway()
igw_id = igw['InternetGateway']['InternetGatewayId']

# Attach Internet Gateway to VPC
ec2.attach_internet_gateway(
    InternetGatewayId=igw_id,
    VpcId=vpc_id
)

# Create route table for public subnet
public_route_table = ec2.create_route_table(VpcId=vpc_id)
public_rt_id = public_route_table['RouteTable']['RouteTableId']

# Add route to Internet Gateway
ec2.create_route(
    RouteTableId=public_rt_id,
    DestinationCidrBlock='0.0.0.0/0',
    GatewayId=igw_id
)

# Associate route table with public subnet
ec2.associate_route_table(
    RouteTableId=public_rt_id,
    SubnetId=public_subnet_id
)
Enter fullscreen mode Exit fullscreen mode

Resulting Route Table:

Destination      |  Target
-----------------|------------------
10.0.0.0/16      |  local (VPC)
0.0.0.0/0        |  igw-xxxxx (Internet Gateway)
Enter fullscreen mode Exit fullscreen mode

This works exactly like a router routing table:

  • 10.0.0.0/16 → local means "directly connected" (traffic stays in VPC)
  • 0.0.0.0/0 → igw-xxxxx means "default route" (send to Internet Gateway)

View Your VPC Route Tables 

import boto3

ec2 = boto3.client('ec2')

# Get all route tables
route_tables = ec2.describe_route_tables()

for rt in route_tables['RouteTables']:
    print(f"\nRoute Table: {rt['RouteTableId']}")
    print(f"VPC: {rt['VpcId']}")
    print("\nRoutes:")

    for route in rt['Routes']:
        destination = route.get('DestinationCidrBlock', 'N/A')

        # Determine target
        if 'GatewayId' in route:
            target = route['GatewayId']
        elif 'NatGatewayId' in route:
            target = route['NatGatewayId']
        elif 'NetworkInterfaceId' in route:
            target = route['NetworkInterfaceId']
        else:
            target = 'local'

        print(f"  {destination} → {target}")
Enter fullscreen mode Exit fullscreen mode

Output example:

Route Table: rtb-abc123
VPC: vpc-xyz789

Routes:
  10.0.0.0/16 → local
  0.0.0.0/0 → igw-123456
Enter fullscreen mode Exit fullscreen mode

This is your router routing table in AWS.

Troubleshooting with Tables

When connectivity fails, check the three tables:

Problem: "EC2 instance in private subnet cannot reach internet"

Check 1: Routing Table

$ aws ec2 describe-route-tables --route-table-ids rtb-abc123
Enter fullscreen mode Exit fullscreen mode

Look for:

0.0.0.0/0 → nat-xxxxx (NAT Gateway)
Enter fullscreen mode Exit fullscreen mode

If missing: Private subnet needs route to NAT Gateway.

Check 2: Security Groups (Layer 4)

$ aws ec2 describe-security-groups --group-ids sg-abc123
Enter fullscreen mode Exit fullscreen mode

Look for outbound rules allowing traffic.

Check 3: Network ACLs (Layer 4)

$ aws ec2 describe-network-acls --network-acl-ids acl-abc123
Enter fullscreen mode Exit fullscreen mode

Look for rules allowing traffic in and out.

Problem: "Cannot connect two VPCs"

Check 1: VPC Peering Connection

$ aws ec2 describe-vpc-peering-connections
Enter fullscreen mode Exit fullscreen mode

Verify status is active.

Check 2: Route Tables

Both VPCs need routes pointing to the peering connection:

VPC A Route Table:

10.1.0.0/16 → local
10.2.0.0/16 → pcx-xxxxx (peering connection)
Enter fullscreen mode Exit fullscreen mode

VPC B Route Table:

10.2.0.0/16 → local
10.1.0.0/16 → pcx-xxxxx (peering connection)
Enter fullscreen mode Exit fullscreen mode

If routes missing: Add them.

Real-World AWS Example

Scenario: Web application with public and private subnets

VPC: 10.0.0.0/16

Public Subnet: 10.0.1.0/24
- Web servers (EC2)
- Internet-facing load balancer
- Route to Internet Gateway

Private Subnet: 10.0.2.0/24
- Database servers (RDS)
- Application servers
- Route to NAT Gateway (for updates)
Enter fullscreen mode Exit fullscreen mode

Public Subnet Route Table:

Destination      |  Target
-----------------|------------------
10.0.0.0/16      |  local
0.0.0.0/0        |  igw-xxxxx
Enter fullscreen mode Exit fullscreen mode

Web servers can:

  • Talk to anything in VPC (10.0.0.0/16 → local)
  • Access internet (0.0.0.0/0 → Internet Gateway)

Private Subnet Route Table:

Destination      |  Target
-----------------|------------------
10.0.0.0/16      |  local
0.0.0.0/0        |  nat-xxxxx
Enter fullscreen mode Exit fullscreen mode

Database servers can:

  • Talk to anything in VPC (10.0.0.0/16 → local)
  • Access internet through NAT (0.0.0.0/0 → NAT Gateway)
  • Cannot receive inbound internet traffic (NAT is one-way)

Traffic Flow: User → Web Server → Database

  1. User (internet) → Internet Gateway → Public subnet web server
  2. Web server (10.0.1.50) → Local route → Private subnet database (10.0.2.100)
  3. Database response → Local route → Web server
  4. Web server response → Internet Gateway → User

Each hop uses the routing table to determine next destination.

Key Takeaways

Switches (Layer 2):

  • Operate within networks
  • Use MAC Address Table
  • Three actions: Learn, Flood, Forward
  • AWS equivalent: Traffic within subnets

Routers (Layer 3):

  • Operate between networks
  • Use Routing Table and ARP Table
  • Forward packets based on destination network
  • AWS equivalent: VPC Route Tables

Layer 2 changes every hop. Layer 3 stays constant.

The three tables:

  1. MAC Address Table (switches)
  2. ARP Table (hosts and routers)
  3. Routing Table (routers)

AWS VPC Route Tables work exactly like router routing tables.

What Comes Next: Part 3

You now understand how switches and routers move data. But what about the protocols that make it all work?

In Part 3, I will explain:

  • IP addresses and subnet masks
  • ARP, DNS, DHCP in detail
  • The four things every host needs
  • Network protocols (HTTP, HTTPS, TCP, UDP)
  • How it all works together in AWS

Your Turn

What networking concept still confuses you?

Drop a comment. I am building this series based on real questions from people studying AWS.

Following this series? You will also like:

  • Part 1: The OSI Model Explained
  • Part 3: IP Addresses and Protocols
  • Part 4: Complete Data Flow Example

I share daily AWS learning on Twitter/X, code examples on GitHub, and weekly deep dives on Substack.

Let me learn cloud networking with you.

Resources

AWS Documentation:

Hands-On Practice:

My Resources:

Stella Achar Oiro is a software developer with clinical healthcare experience, currently studying for AWS certifications while building HIPAA-compliant cloud infrastructure. She shares her learning journey to help other developers transition to cloud engineering.

This is Part 2 of a 4-part series on Networking Fundamentals for Cloud Engineers.

Top comments (0)