Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

Networking 101: Layers (Part 2 of 3) - fixedByVonnie

Networking 101: Layers (Part 2 of 3)

In the first part of this three part series on networking layers, I showed you everything you need to know about the Physical, Data Link, and Network layers.  You also learned the the differences between hubs and switches.  We closed out the article with the inside scoop on IP addresses.

Today I’m going to show you one thing:

  • How it all fits together!

Let’s jump in!

Bringing everything together

So how does network communication really work?

I’ve showed you bits and pieces but now we need to zoom out and look at the big picture.

When two computers live on the same street they are said to be on the same LAN (Local Area Network).  Hosts can communicate with other hosts on the same LAN by sending frames directly to each other.  There’s no need to get a router involved; the switch simply does a super fast table lookup, finds which port the device lives on and shoots the frame along at lightning speed.

In the example below you can see hosts with the MAC addresses A, B, and C live on a street (network) called

Sending frames on the same LAN

The real magic happens when two hosts live on two different networks.

Pulling back the curtain

When you type in fixedbyvonnie.com it probably says “Error connecting to Database”

haha, okay let me stop bashing my own website.

Normally, when you enter fixedbyvonnie.com, the page displays in a few seconds but here’s the questions:

What’s really happening behind the scenes?

First, your computer tries to figure out the layer 3 IP address of fixedbyvonnie.com.  fixedbyvonnie.com is a webserver with an IP address so your computer needs to know the IP address of my website before it can send the homepage request.

Let’s assume your computer has the following IP information:

  • Host IP:
  • Subnet Mask: (I’ll explain masks in a future tutorial)
  • Default Gateway:
  • DNS:

And let’s say fixedbyvonnie.com is really

Resolve the hostname to an IP address

Your PC says:

My DNS is but my host IP is so we don’t live on the same network.  Hmm…  I’ll ask everyone on the LAN for the MAC address of my default gateway.  I don’t know how to get to but my default gateway probably knows a router that does.

So your computer sends out what’s known as an ARP broadcast so that it can find the default gateway.  ARP stands for the Address Resolution Protocol and it’s a layer 2 protocol that resolves IP Addresses to MAC addresses.

How ARP works

For example, when you enter fixedbyvonnie.com in Google Chrome, your NIC sends an ARP frame with your computers physical address as the source MAC but with a destination MAC address of all F’s (which are all ones in binary but we’ll talk about that later):


This just means: Send the frame to every host on the LAN

So every host on the LAN gets the frame but only the default gateway router responds with his MAC address.

Next, your computer makes a DNS request to and your computer forwards the request to the default router which sends it along through the internet (using a process I’m about to describe)

The DNS server replies with what’s known as Type A record which returns the IP address assigned to the fixedbyvonnie.com domain name.  In our case, the DNS reply contains an A record for

Next your host completes what’s known as a TCP three-way handshake with the server.  I won’t get into the details yet but just know that the three-way handshake is how TCP/IP ensures the reliable delivery of information.

It all starts at the Application Layer

Alright, so now we know the IP address of the webserver thanks to DNS.

Here’s the setup:

Network Topology Cloud

The moment you popped open Chrome and typed http://www.fixedbyvonnie.com/, the HTTP service took over the web request in the Application Layer.  DNS resolved the hostname to an IP address and then HTTP passed the protocol data unit (PDU) down to the Transport layer.

At the Transport Layer your computer says:

I see this is a HTTP request so I’ll use TCP to guarantee delivery.  Also I know that most webservers listen on TCP port 80 so I’ll put that port in the destination field of my TCP header.

The segment moves down the TCP/IP stack on your computer and gets swallowed up by the Network layer header.  The Network layer looks at the segment and says:

The source IP will be which is the IP address of the sending computer and the destination address will be, which is the IP address I got from DNS.

The Network layer mashes this header on the TCP segment and passes the packet down to the Data Link layer.


At Layer 2 the computer says:

I’m on street but the webserver is on street.  We’re in two different streets so I know the webserver is not in my LAN.  I need to forward this request to my default gateway so I can get off the local network and into the interwebs.

The default gateway receives the frame, de-encapsulates it and checks out the physical address.

Ahh, the frame is destined to me!  Cool, but what’s the IP address?  That tells me the ultimate destination.

Next, the default gateway looks at the layer 3 IP address:

The destination IP address is which doesn’t belong to me but I know the best path to the network where that host lives.  I’ll forward it to the MAC address of the next hop router.

Router 2 gets the bits, reassembles the frames, checks out the source MAC address and instantly realizes:

Hey! This frame is for me.  Where is the final destination?

After chopping off the Ethernet header and trailer it peals back the layer 3 destination IP address.

Ah ha!  So this packet is going to the web server that’s directly connected to my gi1/0 interface

Router 2 encapsulates the packet, slaps on the layer 2 destination address of the webserver 00:00:dd and forwards the packet to the switch.

When the switch gets it it says:

I know which layer 2 addresses live off all my switchports.  You want to send it out the port that’s connected to MAC address 00:00:dd? Alright, hang on tight!  I can do that!

So the bits race along port 2 and enter the NIC of the fixedbyvonnie.com webserver.  When the bits arrive, the NIC sees the destination MAC address matches his MAC address.  Then it passes the frame up to layer 3 and sees the layer 3 IP address also matches his IP address.


The server passes the packet up to layer 4 and notices the destination port is for port 80 which it just happens to be listening for incoming connections on!  Different applications listen on different ports so when data enters the computer, it knows which application to send it to.  Port 80 is a well-known port for webservers so there is no guessing here.

Next, the TCP/IP request is received by the HTTP protocol running at the Application Layer – and BAM!

That’s how network communication works.

When the webserver sends the reply with the requested webpage; the entire process repeats itself in reverse.

The server encapsulates the reply down through the TCP/IP layers and forwards it to the switch.  The switch makes a forwarding decision based on the layer 2 information and sends the frame to Router 2.

Router 2 de-encapsulates the frame, checks out the layer 3 information and forwards the packet to Router 1.

Router 1 does the same thing and sends it to our computer which de-encapsulates it up the TCP/IP stack until it arrives back in the Application Layer in your browser.

The Bottom Line

Network communication isn’t so difficult when you take the time to break down the process.

In the last part of our series I’ll show you real packet captures from a HTTP request to fixedbyvonnie.com.  We’re going to dive into the nitty details of the headers and see exactly what’s happening under the hood.

I can’t wait to see you here tomorrow.


Connect with Vonnie on Twitter

Posted in What Is Tagged with: ,