Tuesday, August 31, 2010

Lesson 9 - Bridging/Switching Learning Process

In the previous lesson we looked at the Ethernet and a hub operation. We classified hub to be a layer 1 device as it does not understand any headers used by upper layers of our networking model. It simply forwards the bits it receives out all remaining ports. Even though, they do provide basic connectivity to our hosts, they also reveal a lot of weaknesses. For details look at the lesson 8.

A more intelligent and robust device that can replace a hub is a layer 2 switch. You've already learned how to navigate in IOS, and provide the switch with a simple configuration. With this lesson we begin a more serious exploration of layer 2 through layer 4 functions starting with Layer 2. This is good enough excuse to brush upon encapsulation/de-encapsulation process, and the structure of the headers.

Enapsulation Process Re-Visited
This is a quick review of encapsulation process I would present to my nine year old son (if he wanted to learn more).

1. Assuming that TCP session is already complete, the application is forming the request (data) which is sent down to the layer 4. Layer 4 process places source and destination port numbers in the header (Pic. 1).

Pic. 1 - Application sends data to the Transport layer.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

2. Transport layer sends the segment down to the layer 3 for processing. This payload ends up encapsulated in an IP header with the source and destination IP addresses added in the header (Pic. 2).

Pic. 2 - Transport layer sends the segment to the Internet layer.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

3. The layer 3 sends the packet down to the layer 2 (Data-Link) for processing. Layer 2 adds its own header (here the Ethernet header) with the source and the destination MAC addresses (Pic. 3).

Pic. 3 - Internet layer sends packet down to Data-Link layer.

Then, this whole 'thing' is converted into bits and put onto the wire.

Now, we can see what happens when the bits are sent to the port of the switch to reach the destination computer. Let's bring back the Ethernet header to see what we find in it (Pic. 4).

Pic. 4 - Ethernet Header
Icons designed by: Andrzej Szoblik - http://www.newo.pl

In this header there are two pieces of information that switches use to build their mac-address-table (CAM) and make forwarding decisions. Those are: source and destination MAC addresses. And here is how it works.

Initially, the mac-address-table (aka CAM) is completely empty (Pic. 5).

Pic. 5 - Content Addressable Memory (CAM) initially is empty.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

Sooner or later, some computers begin to transmit something across the network. In my example, the PC1 (source MAC address: 1111.1111.1111) begins transmission to PC3 (destination MAC address: 3333.3333.3333). Below is the sequence of events.

1. PC1 with the source MAC address of 1111.1111.1111 sends the Ethernet frame to the destination MAC address of 3333.3333.3333 (PC3).

2. SW1 receives the frame on port F0/1. It 'reads' the source MAC address and maps it to the receiving port in its CAM (like shown in the Pic. 6).

Switches learn MAC addresses by reading the SOURCE MAC from the INCOMING frames (going towards the switch) only. They do not learn anything when the frame leaves the switch.

Pic. 6 - SW1 learns dynamically 1111.1111.1111 by reading the source MAC address from the incoming frame.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

3. SW1 then, reads the destination MAC address and will try to find the outbound port for that destination. Since 3333.3333.3333 has not yet been mapped to any port, the switch will perform flooding (Pic. 7).

Flooding is the act of sending a frame out of all active ports except the port where the frame arrived.

There are few reasons why switch decides to flood a frame:
  • Switch does not know where the destination host is = unknown MAC address.
  • The destination MAC address is broadcast: FFFF.FFFF.FFFF.
  • The destination MAC address is multicast.
 Pic. 7 - SW1 Floods unknown destination MAC address 3333.3333.3333.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

4. Computer with MAC address other than 3333.3333.3333 drop the incoming frames. PC3 is the destination of the frame so it further processes it (de-encapsulation). Meanwhile, the SW2 learns the source MAC address on the receiving port F0/12 and maps it in its CAM. Since, as of right now, it does not know where 3333.3333.3333 resides, it also floods the frame (Pic. 8).

Pic. 8 - SW2 is learning 1111.1111.1111 on F0/12 and flooding the frame.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

5. PC3 (3333.3333.3333) responds the PC1 (1111.1111.1111). SW2 receives the frame sourced with 3333.3333.3333 on port F0/2. It puts this in its mac-address-table (CAM), mapping it to the inbound port F0/2. Next, it will read the destination MAC address in the frame (1111.1111.1111) and consults it with its CAM entries. It finds the outbound port F0/12 where this address has already been learned from the incoming frame. This time, the transmission is not flooded as SW2 has the mapping in the table. SW1 receives the frame on its port F0/12. It reads the source MAC address (3333.3333.3333) and maps it to the receiving port F0/12 in its CAM table. Then it looks at the destination MAC address (1111.1111.1111) and finds the outbound port which is F0/1. NO FLOODING THIS TIME on either switch! All illustrated in the Pic. 9.

Pic. 9 - Port-to-Port transmission in the reply as all MAC addresses in question have already been learned.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Since all computers 'speak' now and then, the switches will learn their MAC addresses from the incoming frames by reading the source MAC address field in the headers. They will populate the CAM and like depicted in Pic. 10.

All entries in the CAM table (mac-address-table) have a default aging timer which is 300 seconds (5 minutes). If the host do not refresh those entries by sending frames toward the port, the entries will be removed after 5 minutes. Of course, if the host transmits the frames again the incoming ports will map them again.

Pic. 10 - Content Addressable Memory (CAM) full.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

In the next lesson we will look at Cisco Discovery Protocol.In lesson 11, we're going to put all the pieces together to show you the practical applications of what you have learned.

Thursday, August 26, 2010

Lesson 8 - Ethernet and Hub Operations

After my last conversation with my son about building the home network I promised I'd explain to him how a hub worked. And now, he's showing at the door... . So, like in the previous lessons I'll focus on the most important aspects regarding CCNA level.

In order to explain how hub works, let me talk about the Ethernet technology first. Ethernet sets the rules regarding how data coming down from the upper layers (Layers 5 through 3) should be placed on the media. It defines such transmission aspects like the maximum speed, cable type and length, connector types, how frame should be structured etc. In other words, Ethernet defines both the layer 2 and the layer 1 of our OSI model. The reason the layer 3 cannot send data directly onto the media is that there are different, disparate media types and technological limitations related to them. For instance, there will be different way of transmitting data between Ethernet switches and two computers using modems to communicate. That is why, we need the layer 2 as a "translator" so the layer 3 protocol can use different types of media without re-writing its functions. Besides Ethernet, there were other protocols in use such as Token-Ring, but today Ethernet seems to be the most commonly used solutions in local area networks (LANs).

Initially, Ethernet used coaxial cable that was terminated on both ends, and the computers were attached to the cable using so called 'T-connectors'. They shared the media, and as a result of that, they shared the available bandwidth. Today, coaxial cable is not used that often. Instead, we use UTP cable (details in the Lesson 7). But the logic of operation in both cases is quite similar.

Ethernet, using a coaxial or a UTP cable (with the hub as concentrator connecting hosts), is based on the idea that only ONE computer can transmit something at a time. Other computers will ALL receive this signal and have to wait for their turn if they have something they want to transmit (Pic 1).

Pic1. Ethernet transmissions in bus (coaxial cable) and star topology (UTP cable + hub).
Switch/router/computer icons designed by: Andrzej Szoblik - http://www.newo.pl

There is no arbiter to decide who can talk in a given time. Instead, the devices have a mechanism allowing them to 'sense' the wire to see if there is any transmission in progress. If not, they can use the media. However, if a host is already transmitting and, some other hosts "thinks" the medium is not used and starts transmitting as well, this phenomenon is called a collision. In that case, both senders will stop their transmission and wait a specified by the algorithm time before they try again. How long they have to wait is determined by so called back off algorithm. Needles to say, the more collisions occur the longer the hosts have to wait before they retransmit corrupted bits. The mechanism of checking the wire before transmission, detecting and reacting to collisions is known as CSMA/CD (carrier sense, multiaccess with collision detection).

  • Carrier Sense - "listen" to the wire to see if you can transmit.
  • Multiple Access - multiple hosts share the bandwidth and only one computer can send or receive bits but not both at the same time (half-duplex).
  • Collision Detection - in case other computer(s) started transmitting while other transmission is in progress, detect it and use back off algorithm.

The major downsides of this approach are the security (everyone "hears" everyone else), and the fact that only one computer can send data across the network at a time. What's worse, it can either transmit or receive bits (half duplex). The more computers you throw in the network, the harder is for them to get a chance to send something. Also, the chances for collisions are higher. In fact, collisions are imminent and make the system perform poorly.

A hub is a simple type of concentrator used to connect multiple computers, servers, printers etc., together. It is considered a layer 1 device due to the fact that it does not understand any headers. All it recognizes are electrical signals representing 1s and 0s. Hub operation is very simple. If signals appears on one port (interface), it is replicated on to all other active interfaces like depicted in picture 1 (right hand side).

Since hubs follow Ethernet rules in which there can be only one sender at a time, and because they transmit bits out of all remaining ports, they maintain one single collision domain.  

Pic. 2 - Hubs maintain one single collision domain.
Switch/router/computer icons designed by: Andrzej Szoblik - http://www.newo.pl

A collision domain could be defined as any group of devices which can receive transmissions from other hosts. So, hubs are not seriously considered to be a proper solution in medium/large networks. The problem with the collisions, typical in hub-based networks, has been solved by introducing another type of concentrators called bridge (old, software-based device) and switch (modern, hardware-based device) equipment used in the layer 2 of OSI mode.

Discussion on bridges and switches though, are the topic I reserve for the next lesson.

Monday, August 23, 2010

Lesson 7 - Building a Home Network

"Dad! What are you doing?" - My son Mattie is looking over my shoulder while I'm connecting three old computers to the hub I'v salvaged from a certain death. "I'm building a small, home network." - I reply surprised at his sudden interest. "What do you need to build a small network?" - There's this little sparkle in his eyes only kids his age have. "And how do you do it?". There's nothing I can do but explain to him how it's done!

We will need few components to build this network. First of all, we'll need computers, running some operating system that can talk across the network (like Mac OS, Windows, Linux).

Pic. 1 - Computers.

Computers are already equipped with NICs (Network Interface Cards) by the manufacturer.
"What does the NIC look like dad?" - He interrupts. Nine years old kids can be very tenacious, almost obsessive. They are not easily dismissed. They won't stop unless they're fully satisfied with the answer. So, I'm taking one NIC out of the computer and explain that it is plugged in to the PCI slot in order to work. "PCI slot is connected to the motherboard of the computer and the operating system uses a special piece of software to talk to the NIC. It's called a driver. The driver translates between an operating system and the NICs hardware. The NIC sends bits down to the wire and knows what to do when bits come back from the network". Bits are small pieces of information (1s and 0s) which in software make data like music, pictures, text documents etc.

Pic. 2 - NIC (Network Interface Card).

"Okay." - Mattie says, "But what else will you need?

"I will need Unshielded Twisted Pair cables (UTP). One, for each computer. The cables (sometimes referred to as Ethernet cables), use RJ-45 connectors that the most commonly used nowadays." - I reply. "Here's the cable without the connector:

Pic. 3 - UTP cable without RJ-45 termination

"Mattie's looking at the cable and I know what's going to happen next. "Dad, why does it have so many wires and why are those twisted like that?"

One pair of the wires (two wires) are used to transmit data. Another pair, is used to receive data from the network. Other wires can be used to carry the power to some types of the devices (PoE devices) or to accomplish faster speeds (1Gbps etc.). They are twisted like that on purpose. The guy who invented that concept was Graham Bell. He invented it for the telephony purposes and patented that in 1881. He discovered that twisting wires (conductors) minimized or canceled Electromagnetic Interference (EMI) from external sources and, so called, cross talk from the neighboring wires.

The cable must be terminated at both ends with RJ-45 type of connector, like the one depicted below:

Pic. 4 - RJ-45 Connector.

Below is the cable with the connectors.

Pic. 5 - UTP cable with RJ-45 connectors.
The UTP cables can have different category numbers (CAT 1-6). The higher the category number is, the better quality of the cable, the faster, and better transmissions are going to be. Also, the UTP cables can be terminated in two different ways like explained below.

Straight-Through Cable
In straight through cable the transmitting pair of wires are 1 and 2, the receiving pair of are wires 3 and 6. There are two major standards (ways) of using the colored wires, but important thing is, that the colors on the both ends of the cable are terminated identically. Please, look at the picture below.

Pic. 6 - Straight Through Cable.

Cross-over Cable
In the cross-over cable, the position of the wires is changed such that the sending pair is terminated at the receiving pair on the other side of the cable. It is illustrated below.

Pic. 7 - Cross-over Cable

My son Mattie's holding both types of cable, looking at them and I know I cannot dismiss him with that explanation. So, I continue.

If you connected two computers together and the NICs are wired identically, you would connect the sending pair (pins 1 and 2) to the sending pair on the other end. This obviously would not work. You must connect sending pair on one end (pins 1 and 2) to the receiving pair (pins 3 and 6) on the other end. For instance, if you connect the following devices together, you'll need cross-over cable:
  • computer-to-computer
  • switch-to-switch
  • hub-to-hub
  • computer-to-router (directly)

Modern NICs can 'sense' the type of cable and adjust the operation regardless of the cable used. But this is not always the case.

Devices such as hubs and switches, are designed such way they can use straight-through cables. The cross between the transmitting and receiving pairs is done in their port controllers. So, the following device connections will use straight-through cable:
  • computer-to-hub
  • computer-to-switch
  • router-to-hub
  • router-to-switch
Now, all we have to do is to connect the cables to the the hub, configure IP addresses on the NICs and voila! They can talk to one another.

Ethernet Hub
It is a simple device that allows to connect a few computers together. Look at the typical, cheap hub you can buy for home purposes:

Pic. 8 - An Ethernet Hub.

"How does the hub work then?" - I can tell my son got some interest by now.
"Well, that is the topic of our next lesson." - I say smiling.

Friday, August 20, 2010

Lesson 6 - Example of TCP/IP Traffic Flow

In the lesson 4 I discussed the TCP/IP model and the terminology that is commonly used in the networking field. Lesson 5, focused on explaining the process of encapsulation and de-encapsulation that computers apply in order to send and receive data across a network. Those concepts are the minimum knowledge we need to posses to understand this lesson.

In this lesson, you will get to see the bare bones. I am going to show you more details regarding the headers used in encapsulation and de-encapsulation process. Also, we will consider a typical transmission to shed more light on somewhat 'dry' content of the previous two lessons.

As mentioned before, the application layer on the client computer is sending some data (request that will look differently depending on the applications used) destined to the application on the server computer. A detailed explanation of what happens during the transmission can be found in the free, on-line 'TCP/IP Guide' book. The link is available below. However, the above guide is a hefty book. If you want to stick to the basics please, keep on reading.


All transmissions use similar process so, as an example, I'm going to show you a typical web client to web server transmission step-by-step. The methodology is almost identical for all other types of data exchange. Before I do that though, please familiarize yourself with the headers that will be used during the encapsulation (sender) and de-encapsulation (receiver) process. Do NOT dwell on those, or try to understand all the mentioned fields. Instead, take a brief look, and refer to them while reading the lesson.

Transport Layer Headers (layer 4)

Pic. 1 - UDP Header (used mostly in voice/video transmissions/dns queries, etc.)

Pic. 2 - TCP Header (used when reliable transport is required)

Internet Layer Header (layer 3)

Pic. 3 - IP Header

Data-Link Layer Header (layer 2)

Pic. 4 Ethernet Header (most commonly used technology in our LAN networks)

Click on the pictures to enlarge them.

The following discussion has been simplified in order to help you understand the general process. Keep in mind that in reality, it is much more complex process than the explanation presented below.

Web Client to Web Server Transmission Step-by-Step

The best way to learn the theory is to see things working in practice. That is why, I am going to capture the web traffic initiated by my client computer destined to my web server. Before you delve into analyzing the details, please familiarize yourself with my client and server addresses first.

Web Client Details:
IP Address:
MAC Address: 00:24:e8:fa:07:1a

Web Server Details:
IP Address:
MAC Address: 00:50:bf:9c:45:6a

Step 1
In the URL field of my web browser I'm typing in the address of the server using HTTP protocol (Layer 5 protocol used as an example). This will tell the application what the address of the server is. I accept it by hitting the 'Enter' key.

Pic. 5 - URL Address of the web server

Step 2
The client computer realizes that the address of the recipient (web server) is in the same layer 3 network (the first 24 bits of the both source and destination address are the same). More on this, you will learn in the upcoming lessons. As a result of that, the client needs to obtain the MAC address of the web server first. Recall from the previous lesson that IP packet is encapsulated in layer 2 header, which in our case uses source and destination MAC addresses. Normally, the client computer is going to check the local 'arp cache' to find out if the mapping of the destination IP address to its MAC address is there. If not, like in my example, the client is going to issue 'ARP Request' message (Address Resolution Protocol) to learn the destination's computer MAC address. This request is propagated to ALL local machines in the network Pay attention to the highlighted lines in the picture. The destination MAC address in the query is the Ethernet broadcast address: FF:FF:FF:FF:FF:FF. In the ARP request the client computer asks for its MAC address (which, as of right now, is all 0s; see the below pic. 6).

Pic. 6 - ARP Request

The ARP request is considered a layer 2 protocol. It is directly encapsulated in the Ethernet II frame. Its header is presented in the second line in the middle panel (under the 'Frame 3').

Step 3
There is only one computer with its unique address of in the network. This one replies to the query with the 'ARP Reply' message back to the sender of the request, telling it what the MAC address it uses. The address is seen in the middle of the pic. 7 (highlighted) belongs to web server. The address reads:

Pic. 7 - ARP Reply

Step 4
The MAC address of the web server was the missing piece of information the client needed to proceed with the TCP session establishment. TCP, being a session-oriented and reliable transport protocol, must establish the mutual communication with the web server first, before it is allowed to send the data from the web browser. This is known as the 3-way handshake. Let us look at the details of the first TCP segment in this session establishment phase.

1. The client ( sends an 'empty' TCP segment (i.e. with no data from the application included in it).
  • It chooses a random source port number first. In the transmission presented the TCP Src-Port: 51504 is chosen. Also it uses the Dst-Port: 80 which identifies web server destination application. This pair of ports will uniquely identify this particular transmission, as the client can initiate multiple transmissions at the same time. Those two ports (source and destination port numbers) allow multiple transmissions without a risk of 'mixing up' which reply from the servers should be sent back to which inititiating that request process. This way, the process that initiated transmission is going to receive the right reply. I need to add here that TCP and UDP ports are divided into two major groups: 'well-known ports' which are ports between 1-1023 (always destination ports for the client initiating transmissions), and 'ephemeral ports' between 1024-65535 numbers. The latter ones, clients choose randomly to mark the source process for their transmissions.
  • Sequence Number in the segment = 0. If the web server (destination) receives this segment and replies to it, it will put a value of 1 in the Acknowledgment field. That is an indication for the client, that the first segment did arrive successfully at the server.
  • The SYN flag = 1, and all the rest of the flags are set to 0. It means,that this is the first handshake in the exchange. It is the client's request to establish session with the server.

    The layer 4 segment has been encapsulated in the layer 3 header (pic. 8: 'Internet Protocol') and further encapsulated in the Ethernet frame (pic. 8: Ethernet II). The first line in the middle section of the picture, is what is seen on the wire.

    Pic. 8 -  TCP Syn Segment

    2. The next segment captured (pic. 9) comes from the web server and is the reply for the 'SYN' message sent by the web client. Now, please compare both pictures (pic. 8 and pic. 9). Pay attention to the source and the destination TCP port numbers, and the source and destination addresses used in the layer 3 (IP header) and the layer 2 (Ethernet header). Did you notice they are reversed now?

    • TCP port numbers are now reversed (TCP Src-port=80, Dst-port=51504) in order to send the reply directly to the port that initiated the request).
    • The server's segment has the Sequence number=0, but the Acknowledgement number=1. It is what we expected. This means that the delivery of the client's first segment was successful).
    • The flag ACK=1, which is the acknowledgement for the SYN flag from the client.
    • The server also wants to synchronize the transmission with the client. That is why it sets its own SYN=1 in this segment.

    Pic. 9 - Server's response SYN, ACK

    3. The client needs to reply to the server's SYN message with its ACK=1 to finalize the session establishment (see the pic. 10). Here's what you find in the third handshake from the web client:
    • Src-port=51504, Dst-port=80.
    • Acknowledgement=1, which is to tell the server that its segment sequence=0 has arrived successfuly.
    • Sequence=1, which means that it is the second segment sent to the server. That's what the server expects to receive (in the next reply from the server, it should see Acknowledgment=2).
    • The flag ACK=1, which is the response to the SYN=1 flag received from the server.
    This way, the 3-way handshake is complete!

    Pic. 10 - Final ACK from the server

    Step 5
    The client has established session with the server, so now it sends the first DATA packet (GET request), asking the server for its main page (look at pic. 11).

    Pic. 11 - Request from the client web browser

    The data from the client (GET) is encapsulated in the layer 4 header, this in turn is encapsulated in the layer 3 header, and the whole thing further encapsulated in the layer 2 header. It is what I described in the lesson 5. See the details in the pic. 11.

    Step 6
    Finally, the reply comes back from the server to the client with the html page (see the pic. 12).

    Pic. 12 - Reply from the web server

    One last thing, I would like to bring up here. Since the appropriate layer understands its header (TCP-talks-to-TCP, IP-talks-to-IP, Ethernet-talks-to-Ethernet), we have two different inter-layer communications taking place:
    1. Vertical communication occurs when the upper layer is sending something to the lower layer and vice versa.
    2. Horizontal (virtual) communication between hosts when the destination host reads the appropriate header encapsulated by the sender. 
    Both are depicted in the picture below:

    Pic. 13 - Horizontal and vertical inter-layer communication.

    The content of this lesson is very simplified, just to get the juices flow. Below I present a short video which walks you through the whole process again. You might find it useful to fully understand the content of this lesson. If you caught the idea, please proceed to the next lesson.

    Tuesday, August 17, 2010

    Lesson 5 - Encapsulation and De-enapsulation Process

    Assuming that you have read my previous lesson about TCP/IP Layers, it's a good idea to take a closer look at the vertical transmissions between layers occurring on the sender host and the reverse process occurring at the receiving end.

    So, the main topic of this lesson, is going to be encapsulation and de-encapsulation process.

    The terminology used in this and subsequent lessons is defined in Lesson 4.

    Remember that TCP/IP model does not follow OSI model exactly. OSI model is now used as a reference. What's described in this blog is TCP/IP model, not OSI or IPX/SPX model. Look at the comparison below:

    Application Layer ==> Transport Layer
    All transmissions start at the application Layer (layer 5; keep in mind, that here we're talking about TCP/IP model NOT OSI model which uses 7 layers; just the answer to a comment I got). The application on the local computer (client) initiates a request destined for the application installed on some other remote host (server). That request CANNOT be sent directly on to the wire (layer 1). Instead, it must be processed by ALL the layers in between (layers 4 through 2) before it reaches the media. This way, the request from the application is sent down to the transport layer (layer 4) for processing. Application will choose one of the two common protocols used in the layer 4: either TCP, for reliable connections, or UDP for un-reliable connections.

    Transport Layer ==> Internet Layer
    The transport layer, upon receiving the request from the application layer, will process it according to what it has been designed to do, and is going to stick a so called header to the incoming data (for the details regarding all headers please, see the next lesson). This header will be understood and processed by the layer 4 at the receiving host (remote computer). This segment (as we call it a 'segment' now), is sent down to layer 3 for processing.

    Internet Layer ==> Network Interface (Data-Link Layer)
    The internet layer will process the incoming data from the layer 4 (which now consists of data or payload from layer 5 + layer 4 header) and will stick its own, layer 3 header, to the payload coming from the upper layers. Once it's done, it will send the packet (as we call it a 'packet' at this layer) down to the layer 2 for processing.

    Data-Link Layer ==> Network Interface (Physical Layer)
    The Layer 2, similarly to the previous layers (layer 4 and layer 3), is going to process the incoming packet according to the functions designed for this layer. Then, it will attach its own layer 2 header, and is going to send the frame (the name given to the layer 2 protocol data unit) down to the layer 1. 

    Physical Layer = Signaling
    The layer 1 is going to transmit bits, 1s and 0s. Bits is the name given to protocol data unit at this layer according to the OSI model which is the reference for all models). Technically, Layer 1 is common for any networking model and follows IEEE specifications.

    The process described above, attaching the controlling information in the forms of the headers, is called encapsulation.

    Once the bits arrive at the destination computer (host), the reverse process takes place which is called de-encapsulation.

    Network Interface (Physical Layer) ==> Data-Link Layer
    The layer 1 is going to accept incoming bits and send them up to the layer 2 for processing.

    Network Interface (Data-Link Layer) ==> Internet Layer
    The layer 2 piece of software can properly interpret the header information (control information) initially attached by the sender's layer 2 process. So, it reads the layer 2 header, then strips this off, and the content of the frame (without the layer 2 header it's called a packet now), is sent up to the layer 3 for processing.

    Internet Layer ==> Transport Layer
    The layer 3 is going to perform similar actions that the layer 2 just did. It reads and processes the layer 3 header in the packet. Notice, that only layer 3 process understands the layer 3 header. Then, it removes the layer 3 header and sends the content of the packet (data without layer 2 and layer 3 headers is called a segment) up to the layer 4.

    Transport Layer ==> Application Layer
    I'm sure you have already guessed what is going to happen next. Yes, the transport layer will read the layer 4 header, which consists of the instructions what to do next. Then, uppon stripping off the layer 4 header it will send what was originally created (data request from the client software) to the appropriate process/application at the receiving host (server application).

    When the server sends the reply back to the client, the whole encapsulation process will occur again. The client receives the reply from the server, and de-encapsulates the incoming data like explained above.

    And this whole process is repeated back and forth until all data has been exchanged.

    This process is presented with the below graphics for better understanding of this lesson.

    Click the picture to enlarge it.

    In the next lesson, we will take a look at the content of those headers and go over and discuss few important fields. This will help us understand the basic communication process using TCP/IP model.

    Sunday, August 15, 2010

    Lesson 4 - Introduction to TCP/IP Layers

    In this lesson we take a sneak peek at the fundamentals regarding TCP/IP. This is one of the most important aspects to understand in order to follow the upcoming lessons. It is not my ambition to explain everything here as this would turn into a hefty book to read. You can find a lot of them on the market anyway. Instead, I will try to focus on some basic aspects of TCP/IP. They will constitute the minimum knowledge to help us understand how computers communicate.

    If you feel the urge to learn more on TCP/IP right now please visit the following site: http://www.tcpipguide.com/free/t_toc.htm

    Familiarize yourself with ALL terms in red. They will be used throughout the classes.

    Computer communication follows some well defined rules and guidelines which we call protocols. In order for the computers to exchange data they have to agree on using the same rules, otherwise they become incompatible. That was the case in the past. This was one of the reasons to create a common model for communication. It was called OSI Model (Open Systems Interconnection). This was an attempt to make different vendor's computers exchange data easily. This way IBM machines could talk to DEC machines and so on. Today however, it is the TCP/IP model that is all-pervasive. This protocol suite is derived from OSI model and somewhat loosely follows its rules and terminology. This is going to be the focus of our discussion and the main topic of this lesson.

    Remember that TCP/IP model does not follow OSI model exactly. OSI model is now used as a reference. What's described in this blog is TCP/IP model, not OSI or IPX/SPX model. Look at the comparison below:

    TCP/IP Layers
    The designers decided to break down the whole complexity of data exchange and created five layers of functions to accomplish the goal. This approach helps develop and modify certain layers of code without touching other layers. For instance, if you are an application programmer, you will be writing a code in the 'application layer' which allows you to use already written code dealing with the transport of data between computers. You do not even have to learn how this transport is done. It has already been written for you. This way, you focus on the application you're creating, what it does and how it works rather than learning about network adapter drivers, signaling and other gory, hardware details.

    TCP/IP model divides the functions related to data transmission by using five distinct layers of responsibility. Below area these layers.

    Layer 5-7 - Application
    This is where the data's journey begins. Everyday, you use many applications that  rely on network services. Those applications are classified to be layer 5 code. Your web browser and web server, mail client and mail server, ssh client and ssh server etc. You may have noticed the term client and server often used in the above description. Pretty much all applications use this architecture. Client, is an application that requests some services from the server application. Server application is providing a client with what they want. A common example of that architecture is your Firefox or Internet Explorer web browser (client application) requesting a page from Apache or IIS web server (server application). Applications, in general, provide a User Interface (UI) which offloads us from a burden of knowing how a computer does things internally.

    So, once your application formed the request, that one is sent down to the layer 4 (transport layer) asking for the delivery to the host somewhere in the network.

    Layer 4 - Transport
    This layer accepts all requests coming from the upper layer (application layer) and tries to organize the transport of that request across the network. In TCP/IP model this layer of software is responsible for:
    • Breaking down big files that are sent across into smaller chunks called segments. There are technology limitations that do not allow our computers to send large files in one piece. It would not be a good idea anyway as any small change of the data during transmission would make the sender re-transmit the whole file again instead of the smaller chunk only. That of course, would take more time and resources to successfully transmit the data.
    • As your computer uses many applications that will transmit something across the network at the same time, the system must know how to mark those request such that they are delivered to the right receiver applications. And once the replies are coming back, they should be delivered back to the same process that initiated them. The concept of the port number has been introduced to deal with that. Source and destination ports ensure that all requests and replies are delivered to the appropriate processes on the computers exchanging data. More on that later in the upcoming lessons.
    • This layer also allows the application to use connection-oriented or connectionless services. The former, establishes communication with the receiving computer (or more generally: destination host) before data can be exchanged, the latter will send data without ensuring that the destination application is running and willing to receive anything. This form of transmission is used primarily for voice and video applications.
    • This layer will also give applications some options in terms of the reliability. Depending on which layer 4 protocol the application is designed to use, the reception of data can be verified or not. That creates reliable versus unreliable transport respectively. In the reliable transport any data that has not been delivered will be retransmitted, unlikely the unreliable transport.
    • One other function of layer 4 could be to moderate the transmissions so that the receiving host is neither swamped by the excess of packets coming in nor is it waiting and doing nothing because the sender's speed of transmission is too slow. Majority of the functions above are performed by TCP protocol, not UDP as applications choose one of them to use.
    Once all aspects and functions in this layer have been taken care of, layer 4 sends the data it received from layer 5 down to the layer 3 requesting its service.

    Layer 3 - Internet
    Upon receiving a request from layer 4, this code is going to process the incoming information. Since, typically we have more than one path between the sender (source) and the receiver (destination), the function of this layer is to find the best path between them. In order to accomplish that there are two concepts I need to introduce here.

    Firstly, we need to know how computers find themselves in the network. This is accomplished by using specially designed, layer 3 addresses uniquely identifying computers in any network. The addresses used by this layer consist of four bytes delimited by the dots (e.g. which are followed by a, so called, 'netmask' also consisting of four bytes with the dot used as the delimiter (e.g. The whole IP address can look like this: More on those later.

    Secondly, because the destination of our data can be outside of our own network, a device called router has been introduced to find the optimal paths between the different networks in which the computers reside. The data processed by layer 3 is called a packet or datagram. This layer also uses a mapping to the upper layer 4 that has requested its services. This is due to the fact that there are more than one protocols available in layer 4 (TCP or UDP). This information (which layer 4 protocol is sending the data) is going to be useful when the data arrives at the destination and the destination's layer 3 process needs to send the content to the appropriate layer 4 protocol for processing. It has to be the SAME protocol that the sender used in layer 4.

    Layer 2 - Network Interface (Data Link in OSI model)
    There is a great variety of technologies that handle data transmission on media such as copper and fiber optics cables or air (wireless). In order to offload the layer 3 protocols from learning all possible signaling methods, layer 2 was created. Thus, layer 3 can focus on finding the best path between the source and the destination, and the layer 2 functions will handle the details of preparing the data to be placed on the actual media (copper wire, fiber, air etc.). The piece of information processed at this layer is called a frame. This layer will also use specially designed addressing scheme to recognize the next device which a computer is sending the data to. For instance, in the commonly used layer 2 technology called Ethernet, this address uniquely identifying hosts in the same network is called MAC Address. The reason why we use different addressing schemes: layer 3 and layer 2, will become clearer when we get into some details of the actual data exchange. Please, bear with me till we reach the right lesson that explains it in more detail. The device that is capable of understanding the structure of a frame and delivers the data between the hosts in the SAME network is called bridge, or switch. As of the time of writing this, switches are very popular devices and bridges can be found mostly in museums.

    Once the layer 2 has prepared the data which layer 3 requested to send, (the process is called 'framing'), layer 2 will send the request to layer 1 asking for the data to be placed onto the wire/fiber/air using the appropriate signaling method.

    Layer 1 - Network Interface (Physical Layer in OSI)
    This layer receives requests from layer 2 (data traveled from layer 5 to layer 1 now). The physical layer is going to encode data received from layer 2 software and place them in the form of bits (1s and 0s) on the medium. This way, ones and zeros travel across the media to deliver them to their receipient. The bits can traverse multiple devices as they go across such as hubs, switches, routers. What type of devices will forward those bits depends on the design of the network. The devices referred to as layer 1 devices are hubs, cables, network adapters, connectors, transceivers etc. Also the data processed by this layer is called bits. This layer defines low level aspects of the transmission such as cables used, maximum distance the cable can reliably sent bits across, types of the connectors, speed of the transmissions etc.

    The names given to the data at each of the layers described above (segment, packet, frame, bits) are taken from the OSI model terminology. They are referred to as: Protocol Data Unit (PDU).

    Understanding the terminology and the concepts presented in this lesson are the pre-requisites to understand the next lesson.

    Please, make sure that you read carefully this lesson before proceeding to lesson 5 in which I am going to show you some details regarding the protocols and headers used in TCP/IP transmissions.

    Monday, August 9, 2010

    Lesson 3 - Initial Configuration of Cisco Switch and Router

    Understanding technologies requires a skill. Even though not mine, but the best definition of what a skill is, could be summarized in five words: knowledge and one thousand repetitions.

    In this lesson, there is no real technology to explain. Instead, you will get familiar with some useful commands we use very often while configuring our routers and switches. This practical exercise however, is going to help hone your skills obtained in the previous lesson.

    Take a look at our simple topology first:

    Switch/router/computer icons designed by: Andrzej Szoblik - http://www.newo.pl

    And here's our plan for the initial configuration.
    1. Configure the host names on both the switch and the router (SW1 and R1 respectively).
    2. When you mistype the command in the 'enabled mode' the IOS is trying to resolve this name to ip address. Disable that name resolution.
    3. Protect the 'privileged exec mode' with clear text password. Use 'cisco_enable' as your password.
    4. Encrypt the password with 'over-shoulder' algorithm.
    5. Protect the access to the console port 0. Use 'cisco_console' as your password.
    6. Configure the console port 0, so it disconnects you after 5 min. 30 sec. of idleness.
    7. Configure the console port 0 such, that system messages sent to the screen, do not interfere with what you are typing.
    8. After careful consideration you decide to use the most secure access to the 'privileged exec mode'. Disable the previous method and configure the same password using MD5 algorithm to encrypt the password.
    9. On the switch assign ip address (use: on the management interface Vlan 1.
    10. Configure the switch to use the default-gateway (address of the default gateway: in case it is managed remotely from another subnet or network.
    11. Enable the router's interface FastEthernet1/0. Use address.
    12. Enable the interface facing the Internet Serial0/1 (we pretend it is the public interface). Use ip address
    13. Enable the remote access to your devices via telnet. Use password 'cisco_remote'.
    14. After careful consideration you decide to use ssh as the remote access method rather than telnet. Configure that.
    15. Save the configuration on both switch and the router so it is available after reload/power cycle.
    1. Configure the host names on both the switch and the router (SW1 and R1 respectively).

    Most of the steps are identical on a switch and a router.  That is why I'm presenting, router's configuration only. You have to repeat them on the switch yourself. If the configuration of the switch is different, it is presented as well (step 9 and step 10).

    If your prompt shows the user mode '>' you must enter the privileged mode first by typing 'enable':


    Then, in order to set the host name on the router you must enter the 'config mode' (you can abreviate the command to 'conf t'):

    Router#configure terminal

    Finally, you type in:

    Router(config)#hostname R1

    The commands take effect immediately as long as their syntax is correct.

    2. When you mistype the command in the 'enabled mode' the IOS is trying to resolve this name to ip address. Disable that name resolution.

    R1(config)#no ip domain-lookup

    3. Protect the 'privileged exec mode' with clear text password. Use 'cisco_enable' as your password.

    R1(config)#enable password cisco_enable

    4. Encrypt the password with 'over-shoulder' algorithm.

    R1(config)#service password-encryption

    5. Protect the access to the console port 0. Use 'cisco_console' as your password.

    In order to do that you have to change the context from 'config mode' to 'line console 0' mode. Pay attention to the prompt! The 'login' keyword is going to prompt the user for the password.

    the 'no login' command would allow the user to access the console 0 WITHOUT asking for the password even if one was configured.

    R1(config)#line console 0
    R1(config-line)#password cisco_console

    6. Configure the console port 0, so it disconnects you after 5 min. 30 sec. of idleness.

    We're still in console 0 prompt so, we can continue configuring console 0.

    R1(config-line)#exec-timeout 5 30

    If you wanted the console line 0 to never disconnect you during the time of idleness, you would use: exec-timeout 0 0.

    7. Configure the console port 0 such, that system messages sent to the screen, do not interfere with what you are typing.

    By default, all system messages are sent to the console 0 and they may interfere with what you are currently typing on the console 0 line. If you are accessing the device via telnet/ssh (remotely), you do not see any messages. If you want to see them on the vty lines (remote connection via telnet/ssh), you must type in: 'terminal monitor' in the 'enabled mode'. Here is the command to satisfy the step 7 in our design:

    R1(config-line)#logging synchronous

    8. After careful consideration you decide to use the most secure access to the 'privileged exec mode'. Disable the previous method and configure the same password using MD5 algorithm to encrypt the password.

    As we are still in the line console 0 context (look at the prompt), we need to step back to the 'config mode', and then remove the previous 'enable' password. Next we will proceed with md5 password configuration. If you did not remove the previous 'enable password', system is going to use the more secure one anyway.

    R1(config)#no enable password
    R1(config)#enable secret cisco_enable

    9. On the switch assign ip address (use: on the management interface Vlan 1.

    I assume that you have completed the steps 1-8 on BOTH router and switch. The commands and prompts will be identical. Now, you can assign ip address on Vlan 1 interface.

    SW1#conf t
    SW1(config)#interface vlan 1
    SW1(config-if)#ip address
    SW1(config-if)#no shutdown

    10. Configure the switch to use the default-gateway (address of the default gateway: in case it is managed remotely from another subnet or network.

    We need to step back to 'config mode' from interface Vlan1 mode to accomplish the task.

    SW1(config)#ip default-gateway

    11. Enable the router's interface FastEthernet1/0. Use address.

    R1(config)#interface f1/0
    R1(config-if)#ip address
    R1(config-if)#no shutdown

    12. Enable the interface facing the Internet Serial0/1 (we pretend it is the public interface). Use ip address

    Even though we are currently in F1/0 interface context (look at the prompt), we can jump directly towards s0/1 without typing 'exit' first. If you use real routers (not dynamips), one end of the connection must use DCE cable and the other DTE cable. They are connected back-to-back and DCE interface must be set up with the clock rate.

    R1(config-if)#interface s0/1
    R1(config-if)#ip address
    R1(config-if)#no shutdown

    13. Enable the remote access to your devices via telnet. Use password 'cisco_remote'.

    Remote access connections are service by special, virtual lines called vty. Here, we will use vty lines 0 through 4, allowing only five concurrent connections via telnet.

    R1(config-if)#line vty 0 4
    R1(config-if)#password cisco_remote

    14. After careful consideration you decide to use ssh as the remote access method rather than telnet. Configure that.

    This is going to be the most complex part in our lab. Below are four steps need to complete the task.

    a) Configure system domain-name. Without the domain name, IOS cannot generate rsa keys used for encryption and decryption (public/private). The domain name can be any name you choose to use (here: ccna.local) but company's real name is a good idea.

    R1(config)#ip domain-name ccna.local

    b) When you type the below command the system will ask you what should be the length of the keys. Choose 1024 value. IOS will take a few seconds to generate them and automatically start SSH server. Wait till it's done.

    R1(config)#crypto key generate rsa

    c) Create a user account that will be used for ssh access (here: user=admin, password=S3cr3t).

    R1(config)#username admin password cisco_remote

    d) Enable ssh protcol and disable telnet on vty lines 0 4. Make sure that ssh will use locally created user (admin) for ssh connections. This is done using 'login local' command.

    R1(config)#line vty 0 4
    R1(config-line)#transport input ssh
    R1(config-line)#login local

    15. Save the configuration on both switch and the router so it is available after reload/power cycle.

    R1#copy running-config startup-config

      Sunday, August 8, 2010

      Lesson 2 - Navigating in Cisco IOS

       LESSON 2 - LAB

      Once, you have connected to your terminal to Cisco switch or router console port power it up and observe startup messages on your screen.

      In case your network device does not have startup-configuration saved in NVRMA/Flash memory, you will be greeted with 'Would you like to enter the initial configuration dialog [yes/no]:' message as depicted below:

      Pic. 1 - System Configuration Dialog

      You can safely cancel this request as its capability to configure the device is not very impressive. Just enter: no and hit enter twice. Wait, as it takes few seconds for the device to give you prompt back.

      What follows is bunch of messages sent to the screen and after hitting the Enter key few times you get something like this (here is the router, but a switch would introduce itself as ... Switch> ):


      What you are looking at right now is prompt of IOS operating system. Terminal and commands you type are the primary means of 'talking' (configuring/monitoring) your network node (switch/router).

      IOS Modes (contexts)

      From the very beginning try to be attentive to details you see on the screen.

      The prompt of the device tells you which 'context' you are in.

      The prompt that presents '>' character is called 'user exec mode' or 'privilege level 1 mode'. You can't configure much in this mode of operation. It is designed as a 'monitoring' mode not a 'configuration' one. You should also know that even monitoring capability in user exec mode is limited. For instance, you can't see the running configuration of the device. However, it is useful for less experienced users who want to perform basic diagnostics of the device without risking of accidental re-configuring the device and causing a problem.

      Make sure that if you are learning networking you DO NOT USE PRODUCTION equipment. You should have some lab gear to experiment on.

      Assuming you are using lab equipment let's roll up our sleeves and begin to learn about different IOS contexts.

      Type in the following command:


      The prompt changes to '#' which is called 'privileged exec mode', 'enabled mode' or sometimes 'privilege level 15 mode'. I would like to draw your attention to two things here. Both modes of operation (or contexts, if you like) have two things in common:
      1. They are used primarily to monitor the device (you will be using 'show' and 'debug' commands in those modes).
      2. Using any IOS command and pressing enter will execute the command as long as its syntax is correct. In case you make a typo or command is not available in the context you are in, an error shows up on the screen and the command will not be executed.
      IOS takes a single command per line that must be accepted with Enter.
      Now, coming back to those two modes (contexts) here's a somewhat concise explanation of what they are used for and how to use them:
      1. User Exec Mode - is limited in terms of what information will be available.
      2. Enabled Exec Mode - gives the operator ALL information (like root or Administrator account on a computer).
      Question Mark

      IOS commands (one per line) can be a single keyword or a keyword followed by one or more arguments. You should learn how to ask IOS for help as there will be a lot of commands to remember and a lot of arguments those commands can take.

      Question mark '?' is your best friend in learning commands. It is a built-in help that is a 'context-sensitive help'. This means that depending on which context you use, typing a question mark (?) will display only keywords (commands) available in this particular context.


      In order to configure things in Cisco IOS (except for some minor changes), you must enter the 'global configuration mode' first which is characterized by the following prompt:


      This context can be accessed by typing the following command in the 'privileged exec mode':

      Router#configure terminal

      Whatever you configure device in 'global configuration mode' or 'config mode' it is going to be applied to the device as a whole unit (e.g. hostname, default gateway on a switch etc.). Don't worry about details right now. I will explain them in due time.

      If you want to enter the context of the interface to add some parameters to it such as ip address, speed, duplex, description etc. , you must enter that interface from the global configuration mode like the one below:

      Router(config)#interface fastethernet0/1

      Watch your prompt to know in which context  your cursor is. If a particular command does not work it is either a typo, or perhaps you are in the wrong mode of operation (wrong context).

      If you do not know what interfaces your device has, type the following command in the enabled mode:

      Router#show ip interface brief

      Here's first 'gotcha'. All 'show' commands can only by typed in either user-exec mode or privileged-exec mode. If you are in the 'config' mode you must precede show command with the 'do' keyword as shown below:

      Router(config)#do show ip interface brief

      Now look at the whole navigation I just showed here:

      Router#configure terminal
      Router(config)#interface fastethernet0/1
      Router(config-if)#do show ip interface brief
      1. Entered the interface type (here: Fast Ethernet).
      2. Referenced the module number (here: 0)
      3. Referenced the port number in the module 0 (here: 1)
      Please, note that routers count ports starting from 0, switches start counting ports from 1.

      You'll learn other contexts as we go through numerous labs.


      You don't have to type in the full words of the commands and certain attributes that follow the commands. For instance, instead of typing:

      Router#configure terminal

      You can type:

      Router#conf t

      As long as the abbreviation uniquely describes which command you want to use, the system has no problem accepting it.

      Shortcuts And Keystrokes

      When you type enough of the characters that uniquely identify the command in a given context you can use 'tab' key and the system is going to complete the command on the screen (just like it happens in Linux terminal).

      I often use the following keystrokes while editing the commands:
      • CTRL-z - takes the cursor back to the 'enabled exec' mode from any other context (Router#)
      • CTRL-a - takes the cursor to the beginning of the line
      • CTRL-e - takes the cursor to the end of the line
      • CTRL-k - erases everything to the right of the cursor
      • CTRL-u - erases everything to the left of the cursor
      • Up Arrow or CTRL-P - displays previous command from the history buffer
      • Down Arrow or CTRL-N - displays next command from the history buffer
      System keeps the record of up to ten or twenty (default) commands you typed in. That depends on the system you use. You can increase/decrease the history buffer up to 256 commands.

      If you want to check the history buffer size, type in:

      Router#show terminal | include history

      I will describe this pipe character '|' and 'include' keyword in our practice lab later.

      Changing the buffer size can be accomplished with the following command in the 'enabled mode'

      Router#terminal history size 256

      There is another way of doing it, that you will practice in our lab section.

      The above command will increase the size of the history buffer to 256 commands.

      If you want to see the buffer (which commands were typed) use this command:

      Router#show history
        If you understand the content of this lesson, let's practice all you have read (and a bit more) in our first lab.

        LESSON 2 - LAB

        Next lesson is going to be about creating an initial configuration of our router and/or switch.


        CCNA Basics | Cisco Advanced | Linux Last Update: 19/02/2019 - eBGP Peering CCNA Lessons: 01 - Connecting to Cisco Cons...