OSI model and TCP/IP

moparbob

Hey guys I am studying for CCENT and having a hard time understanding the OSI model and TCP/IP. Understand some of it like the Application layer(using Chrome, Firefox, outlook)

The Presentation layer (.jpg, .gif, mp3..... )

Session layer - making connections and stuff

Physical layer - cables and such

It just the books and everything kind of confuse it for me ....lol

gorebrush

This is a very good question. Confusing at first though admittedly. Basically, you can think of your web browser as a layer 7 application. When you make a request for a website, you typing in an address, lets pretend Google. At layer 7 your browser takes your request for the website, and it progresses down the OSI model (it is conceptual though, so the OSI model isn't a literal model), but as it progresses down, you get to say, layer 4 - which is where TCP lives, HTTP requests are port 80, layer 3 would be the IP address where the destination server is - Layer 2 would be the MAC address of your router where the packets initially leave your network, and of course layer 1 is the physical serialisation of the packets onto the media that your network is connected it.

As your request progresses down the model conceptually, it is being built into actual data that is sent across the network, so an IP packet at layer 3 with the TCP data at Layer 4 and above is encapsulated at Ethernet (Layer 2) and then serialised onto whatever your physical medium is (Layer 1)

So if you are using a DSL connection - this operates in a different manner at Layer 1 to say a Dial up connection (for the sake of comparison) but the principle is exactly the same.

As the packets go up to the destination, then layer 1 is the physical data, 2 is the MAC of the eventual destination, Layer 3 is the same destination IP as picked at the beginning (remember that MAC addresses change hop to hop, IP addresses do not). Layer 4 dictates that the packets are destined for whatever is listening on port 80, and up from there.

The return is the same principle, I'll not repeat myself

Hope that helps clear it up a little

OfWolfAndMan

The semantics of the OSI model have been debated for years. While the OSI model is usually referenced when explaining network concepts, TCP/IP is a much better representation for explaining things.

Before I go over the different layers, I want you to see this process from a big picture perspective. Check out the picture below on the bottom of the page:

The TCP/IP Guide - Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)

As you will see, data is "Encapsulated" from layer 7 down. Think of encapsulation as envelopes in more envelopes as it descends the layers. The top envelope is the header for the current layer of encapsulation, and all layers' data and headers below that are relevant to the process of sending data from point A to point B.

The word "Application" in the world of OSI is different than saying "Chrome, Firefox, Outlook". There are "services" or "applications" that are defined for the application layer. Chrome and Firefox are applications, but can run HTTP, HTTPS, FTP. In outlook, you use the SMTP and IMAP applications to make outlook work. In the world of OSI, "Application" does not mean a standard windows/mac/linux program, but means the services that make your programs work. As you see, the words can be confusing.

Because this is the CCENT, I will keep the rest of the application layers brief to the above. Presentation is self-explanatory, and session is difficult for me to explain. Now to the transport Layer (4). You could call the transport layer the liaison between the lower network layer and the upper application layers. It also deals with making sure the transport of the data is sent correctly, and establishes "sessions" with different connections via port numbers (TCP sessions and session layer is NOT the same). In addition, one port number does not correlate to one program. For example, port 80 is for HTTP, but so is 591. Think of the port number as an extension to a phone number. The IP is the phone number and the port is the extension. The two types of transport protocol (And the only two you really hear about in the R&S world these days) is TCP and UDP. When you hear the word "Reliable" and "unreliable" in the context of these words, reliability is based on making sure the packets are sent in the correct order, and in the case of partial loss, the lost segments are retransmitted to ensure reliability of delivery. However, TCP only offers this service. If you look at a TCP segment, you will see a sequence number, ack number, and window size. These are all used to ensure that reliability. You will see, in both UDP and TCP segments, there is a checksum in both of the headers. However, a checksum may be able to detect packet errors, but it can't do anything about it.

Onto the network layer (3). The network layer is responsible for internetwork (Meaning between multiple networks) addressing and routing. Both routing (OSPF, EIGRP, IS-IS) and routed (IP, IPv6, GRE, IGMP) protocols work at this layer. Omit, for a moment, the comment about IP and phone numbers I mentioned earlier. Think of an IP packet as an envelope with your address and the receiver's address on it. The IP destination address is your ultimate destination.

Then there's layer 2 (Data link). Layer 2 headers deal with the LOCAL NETWORK. While L3 protocols rely on IP addressing, L2 works with the physical address of the devices for switching (AKA MAC address). The L2 header is only concerned with source device to the first hop router. Every time a packet hops from router to router, the L2 header must be rewritten. So if you run a traceroute from your home computer to google.com (I'm getting ten hops from where I am), that's how many times the L2 header is rewritten. Now, luckily with CEF it makes things easier, but you'll learn about that later. L2 headers are usually ethernet, but they can also be Frame relay, CDP, STP, MPLS (Even though its considered 2.5), etc.

Physical is exactly that. It deals with physical serialization of packets over a physical medium. Not too much to explain.

Hope this helped!

SWtacoma

I also highly suggest running a packet capture with Wireshark. Do something simple like bringing up a webpage and capture the traffic involved in the process. The capture breaks things down by layer and can give you a good idea of the behind the scenes workings. There are many tutorials for wireshark online and it is a tool you will use a lot in networking.