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.

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

Introduction 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.

Note!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 LayersThe 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 are these layers.

Layer 5-7 - ApplicationThis 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 - TransportThis 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 - InternetUpon 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. 10.1.1.1) which are followed by a, so called, 'netmask' also consisting of four bytes with the dot used as the delimiter (e.g. 255.255.255.0). The whole IP address can look like this:10.1.1.1 255.255.255.0. 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.

NOTICE!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).

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.

NOTICE!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 LayerAll 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 LayerThe 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 = SignalingThe 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 LayerThe 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 LayerThe 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 LayerI'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.

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 possess 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.

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)

NOTICE!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: 192.168.1.13 255.255.255.0MAC Address: 00:24:e8:fa:07:1a

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

Step 1In 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 192.168.1.0/24. 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 192.168.1.1 for its MAC address (which, as of right now, is all 0s; see the below pic. 6).

Pic. 6 - ARP Request

NOTICE!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 3There is only one computer with its unique address of 192.168.1.1 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:00:50:bf:9c:45:6a

Pic. 7 - ARP Reply

Step 4The 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 (192.168.1.13) 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 initiating 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.  

NOTICE! 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 5The 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

NOTICE!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 6Finally, 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 flowing. You might find it useful to fully understand the content of this lesson. If you caught the idea, please proceed to the next lesson.

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 CableIn 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 CableIn 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)

NOTICE!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 HubIt 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.

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

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.

HUBA 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

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.

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-VisitedThis 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

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

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

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

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).

NOTICESwitches 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

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

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

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

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.

NOTICEAll 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

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.

Lesson 10 - Cisco Discovery Protocol In the previous lesson we have explored how switches build their mac address table (aka Content Addressable Memory). It is critical to understand those concepts in order to perform troubleshooting related to connectivity issues.

In this lesson we'll continue studying layer 2 technologies. Today's theme is Cisco Discovery Protocol. This protocol comes in handy in many situations (trust boundary for Cisco IP Phones, auto qos and others).

What is Cisco Discovery Protocol?CDP is Cisco proprietary layer 2 protocol. It is enabled by default on majority of Cisco devices including IP phones. It can work on any connections supporting SNAP (such as LANs, but also ATM and Frame-Relay). The only time you'll see the CDP turned off by default, is when you use frame-relay configured interfaces.

What does CDP do?

Every Cisco device using this protocol, reports information about itself by advertising special packets out of its all active interfaces. The important pieces of information it advertise include its:

Hostname Platform Ports where CDP packets are advertised IOS version IP address

CDP can help administrator discover Cisco devices connected and create a  topology diagram or prepare an inventory of the gear used. It can also be an additional tool in troubleshooting problems in the network. Working as a support technician, I found it useful numerous times.

Let's take a quick tour through the CLI (command line interface) and see what major commands CDP allows us to use and what they show.

I'm connected to my Cisco switch SW1 and in the privileged mode type in the following command:

Pic. 1

Using our best friend '?' we can see the CDP options. The last line '' stands for: 'carriage return'. A good, old-fashioned terminal lingo for 'press enter'. Let's try this first.

Pic. 2

Based on the output (Pic. 2) we see that CDP version 2 is enabled, the information packets (though technically should be called frames) are sent every 60 seconds. We also learn, that SW1 will keep CDP information it receives from its Cisco neighboring devices for 180 seconds (holdtime). Let's look at another CDP command:

Pic. 3

In the Pic. 3 we can see the traffic statistics such as CDP packets sent, received, any CDP encapsulation problems etc.

The below command (output in Pic. 4) will tell you which interfaces CDP is running on.SW1#show cdp interface    You can disable CDP on a specific interface or group of interfaces. For instance, if you do not want to run CDP on Fas0/1 interface, you could use the following command:SW1#configure terminalSW1(config)#interface Fas0/1SW1(config-if)#no cdp enable

If you want to disable CDP on a group of interfaces you can use 'interface range' command. For instance, disabling CDP on Fas0/1, Fas0/2, Fas0/5 and Fas0/8 would look like this:SW1#configure terminalSW1(config)#interface range fas0/1 - 2 , fas0/5 , fas0/8SW1(config-if-range)#no cdp enable

NOTICEIf you use the 'interface range' command, the consecutive ports can be specified with '-' but make sure your use 'space' before and after '-' (fas0/1 - 2). The same applies to non-consecutive ports (fas0/5 , fas0/8). There is 'space' before and after the comma character ','.

As you will see later, CDP discloses some vital information (e.g. IOS version), so for the security reasons you may decide to turn off CDP altogether. Be careful before you do that though, as some application

may rely on this protocol. Disabling CDP can cause cascading problems in your network. The command which disables CDP completely (on all interfaces) is:SW1#configure terminalSW1(config)#no cdp run

Pic. 4

Now, let's see what neighboring devices SW1 discovered by listening to their CDP packets (Pic. 5).

Pic. 5 

Dissecting the Pic. 5 output we learn the following:

SW1 received CDP packets from the device named 'R1' (hostname). This CDP packet was sent from R1's Fas0/0 interface (the last column 'Port ID'). SW1 received this CDP information packet on its Fas0/1 local interface ('Local Intrfce'). This leads us to a conclusion that R1's Fas0/0 interface is directly connected to SW1's Fas0/1

interface. R1 neighbor is a router as the capability list shows 'R S I' (R=router, S=switching capability,

I=IGMP support). R1 is 2611XM platform.

That's not all by any means. There is another command we can use to obtain more information about R1. Click at the Pic. 6

Pic. 6

It shows you information about IOS version running on R1, as well as its IP address 192.168.10.254 configured on Fas0/0 interface. Now you understand why you might consider turning off CDP on some interfaces. You do not want to show such details to a third party company (like your service provider), that connect to your devices.

Instead of using 'show cdp entry R1', you can also use the following command that displays detailed (similar to Pic. 6) output about ALL discovered neighbors :SW1#show cdp neighbor detail

In lesson 11, you will learn the commands related to switch mac-address-table which was covered in theory only (lesson 9). Also, we'll hone all our skills we have obtained so far. Things will begin to fall into place. At least that's my hope.

Lesson 11 - Layer 2 Connectivity Troubleshooting Part 1 The last two lessons I tried to explain the foundations related to layer 2 operation. I discussed very important switching process and CDP protocol which comes in handy at times. If you also have watched the video in the lesson 10, you got a glimpse of few commands explained in the theory earlier on.

In this lesson, we'll focus on practical application of the layer 1 and layer 2 concepts which could be helpful in troubleshooting networking issues.

Even though we're capable of creating lots of great things we're still human beings. And 'to err is human' adage is as conspicuous in the networking field as anywhere else. This means, that occasionally things won't work as expected. In such situations we need to be able to isolate and fix the problems quickly.

Reactive troubleshooting almost always uses the following work flow:

1. A problem is reported. 2. Data and facts are collected. 3. Data analysis must be performed. 4. Potential causes are eliminated. 5. Hypothesis is drawn. 6. Hypothesis is verified. 

In some situations the steps 3 and 4 could be omitted. But it depends on the nature of the problem reported, severity of issue, skills of the technician etc.

As we have yet to learn layer 2 technologies such as Vlans and Spannig-Tree Protocol which add complexity to troubleshooting process, let us, for now, focus on simple cases. This way we're going to build our troubleshooting skills step by step given the knowledge we posses.

Recall the process of moving data from one computer to another. Everything sent from the application layer goes down to the physical layer. That teaches us one important thing: if the layer 1 is not operational, nothing else will work!

So, we could start diagnosing the networking problems by checking the layer 1 connectivity first. Then, we could move on to the layer 2 and work our way up till we isolate the problem. This makes perfect sense. However, a lot of technicians use other method known as 'divide and conquer'.  In networking diagnostics that might be checking the layers in the middle. For instance using the 'ping' utility we can check the layer 1 through layer 3 status as a starting point. Of course, you already know how the 'ping' works, don't you? 'Ping' uses ICMP protocol which is a layer 3 messaging mechanism encapsulated directly in IP headers.

NOTICEPing utility is a layer 3 reachability checking mechanism. It sends a number of ICMP echo messages to the destination host. If the destination host receives echo messages, it sends ICMP echo reply messages back to the sender. Of course, assuming that there are no mechanisms implemented that would filter those messages along the path (like local firewall for instance), the sender should receive those replies and thus effectively checking layer 1 through layer 3 reachability. Thus, the path is verified in BOTH directions.

If you aim at the layer 3 reachability using 'ping' utility, you may get one of the two results:

1. You get the reply from the destination. This leads to a conclusion that all layers 1 through 3 are working properly. And the connectivity problems might be related to upper layers (layer 4 upward).

2. You do not get the reply from the destination. In that case, this step is not enough to determine the nature of the issue. In this case, you must perform some additional diagnostics.

Now, I am going to show you a few of such steps.

NOTICE The steps presented in this lesson are not the ALL possible diagnostics you can do. And they do not have to be done in this specific order. I am merely listing some logical steps which might be useful in order to 'nail down' the root cause of the problem.

Trouble Ticket 1Data transfer from PC1 toward PC2 is very slow (refer to Pic 1).

Pic. 1 - Simple Topology

 

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

As you see, without the topology diagram, it is much more challenging to do diagnostics. If we know the topology and the path between the source and destination devices in question, we can focus on all components that participate in the data transmission and isolate the issue.

First, let us determine what we know.

The transmission succeeds, but is slow. Verify that yourself. Do not assume it's true or properly tested by

the person who reported that. Most users cannot properly describe the nature of the problems.

So, you have done the tests and the transfer proves to be slow indeed.

Some questions you might ask:

Has this problem occurred recently? Is this a new client computer or destination server? Has any configuration/update/cable replacement/or any other changes been done on any devices

in the path before the problem manifested itself? Are other computers experiencing the same problem, or is this individual case? etc.

Further data and fact collection may depend on the answers to those questions. For the argument's sake let's assume, that the server is a brand new computer installed the day before the problem occurred. All clients sending files to the server suffer from slow data transfer. When you connected the same client to the server directly, the transfer is very fast (computer-to-server through cross over cable).

Given those facts, we're going to take a quick look at the status of the interface where our server computer is connected. The command that is very useful to check both the layer 1 and layer 2 status is:

SW2#show int f0/2 

Pic. 2 - show interface command

This output deserves some explanation.

FastEthernet is up,This is the status of the layer 1 connectivity (your cable seems to be attached right?).

line protocol is upThis is the status of the layer 2. It looks like the keepalive packets sent every 10 seconds are working back and forth (do not trust it entirely though; look at the trouble ticket 2 in the next lesson).

half-duplex, 100Mb/sDuplex negotiated is HALF duplex. Most network adapters used in the computers use AUTO negotiation. This means, that the NIC (Network Interface Card aka network adapter), sends special signals to the port of the switch trying to negotiate FULL duplex and the highest speed supported. Unfortunately, some NIC manufacturers do not follow the specification regarding this signaling. This causes some "misunderstanding" between the port of the switch and the NIC. Switch typically drops down the duplex from FULL to HALF. That causes the switch port to enable the Carrier Sense, Multiple Access with Collision Detection mechanism (CSMA/CD) which is used on SHARED not dedicated connections (for details look at the lesson 8).What we end up having is the NIC working in FULL duplex but the port of the switch runs HALF duplex. It 'thinks' it can either send or receive data but not do both at the same time. When server begins to 'push' data across the network, the port of the switch cannot send anything out towards the server. When it finally 'thinks' it can (medium free) and sends data towards the server, the latter begins to send data down towards the port as it is allowed in FULL duplex connections. The switch must stop immediately as the frames are experiencing collision. At least that is how the switch works under the circumstances. Then it waits till the carrier is free again (no data from the server down the port). This problem is known as: DUPLEX MISMATCH. That results in great number of collisions and late collisions recorded on the port of the switch like shown in the above output.

The solution to that problem could be the following actions:

1. Try to upgrade the NIC driver using your server/computer vendor's web site. 2. If the problem persists, you may try to hard code speed and duplex. You have to do this on both

ends of the connections. This disables the AUTO NEGOTIATION feature (do not listen to people who say you should do this on one end of the connection).

3. Sometimes, though very unlikely in our situation, the cable can cause that sort of behavior. Replacing it to the one that is proven to be good, might help. Again, typically we would see some other layer 1 errors (CRC errors, carrier loss).

4. Replace the NIC on the server to the one that you are sure is working well.

Hard Coding Speed and Duplex

SW2#configure terminalSW2(config)#interface fastethernet0/2SW2(config-if)#speed fullSW2(config-if)#duplex full

As for the computer, you have to refer to the manual of your operating system  how to set speed and duplex on the NIC manually. Perhaps google this. Google are the best!

In the next lessons, we will resolve two more connectivity issues given the skills we obtained in previous lessons.

Lesson 12 - Layer 2 Connectivity Troubleshooting Part 2 In the previous lesson I attempted to show you how to go about a performance problems we might experience due to the duplex mismatch. It was our first trouble ticket in the series on layer 2 problems.

In this lesson I am going to create another issue to show you how your current skills can be practically useful in diagnosing network connectivity problems.

NOTICE The steps presented in this lesson are not the ALL possible diagnostics you can do. And they do not have to be done in this specific order. I am merely listing some logical steps which might be useful in order to 'nail down' the root cause of the problem.

Trouble Ticket 2Some client computers have problems accessing FTP server located in the same network 192.168.1.0/24. This behavior is very intermittent.

We need to collect a bit more data related to this problem. A good starting point might be to take down the following pieces of information:

FTP ServerIP address  = 192.168.1.4MAC address = 00:10:5a:d3:e4:e0

FTP Client1 (with no connectivity to FTP server)IP address = 192.168.1.2MAC address = 00:10:4f:b0:b2:fc

Here is one way of doing basic diagnostics.

Step 1We want to make sure we have layer 1-3 connectivity between the Client1 and the server first (remember 'divide and conquer' method from the previous lesson?).

jr@mandala:~$ ping 192.168.1.4PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.64 bytes from 192.168.1.4: icmp_seq=1 ttl=64 time=0.372 ms64 bytes from 192.168.1.4: icmp_seq=2 ttl=64 time=0.349 ms64 bytes from 192.168.1.4: icmp_seq=3 ttl=64 time=0.371 ms64 bytes from 192.168.1.4: icmp_seq=4 ttl=64 time=0.374 ms

It seems we have layer 3 connectivity working just fine.

Here's an interesting question for you. How do you know, you have received the replies from the FTP server in question (192.168.1.4)?

Now, you may have very confused expression on you face as in 'what do you mean?'. Have I not just gotten the reply from it?

Well, let me show you something to address this question.

Step 2In order to be absolutely sure I got the reply from the FTP server (192.168.1.4) I need to verify my computer's ARP cache (Client1). Recall, that every time a host sends the packets, it encapsulates them in layer 2 frames (here Ethernet ones). In order to do that, the Client must have a valid destination MAC address (00:10:5a:d3:e4:e0) mapped to its IP address (192.168.1.4). If this mapping entry is not found in the APR cache, the Client1 will send ARP request to learn MAC address of 192.168.1.4. Knowing it let's check the ARP cache after we have sent ping packets. Here's what we find in (Pic. 1):

Pic. 1 - ARP Cache Entries

Pay attention to the highlighted entry. Is the MAC address mapped to our FTP server's IP address correct? 

NO! 

This MAC address does not belong to the server. FTP server's MAC address is: 00:10:4f:b0:b2:fc.

That test proved that getting echo replies to our echo packets (ping) must also be verified in the sender's ARP cache.

So, which device does this MAC address 00:10:0f:a3:3b:e6 belong to? And how on earth did it end up in our Client's ARP cache?

Well, in order to answer the second question, the reasons for this wrong mapping might be different. There could be the device with the duplicate address (same as the FTP server). Then, when the clients send ARP request for the MAC address of the server, this 'rouge' device (not the legitimate FTP server), also responds to the query. And if its answers arrives later than from the legitimate server, the override the legitimate MAC address mapping in the ARP cache. If some other clients get the reply for their ARP query from the 'rouge' device first and then from the FTP server, they create the mapping correctly. That would explain why some computers can still FTP to the server and others can't. Another reason for this wrong mac-to-ip mappings might be ARP poisoning attack in the network (eg. using Ettercap tool).

As for the answer to the first question, if this is not an ARP poisoning attack, you can use your knowledge from the lesson 9 about switching which helps you understand CAM table creation. Then, send uninterrupted ping towards the 'rouge' device and try to trace the mac addresses from switch to switch to find out where the device with duplicate IP address is located. MAC address table should help you find it relatively quickly.

There might be one more question I would like to clarify. Why the duplicate address was not detected by the 'rouge' device? Answer to that question may surprise you. The duplicate address detection uses so called 'gratuitous arp'. This is an unsolicited advertising of the MAC address upon computer startup. If some computers use the same MAC or IP, the newly computer cannot use its IP in the network. Unfortunately, some operating systems may not use this mechanism. They 'trust' what the operator does. If she or he wants this address, there will be no protest on their part.

I hope you are now beginning to see how much you already know!

In my next lesson you are going to analyze the third trouble ticket for layer 2 connectivity. This is going to be the last troubleshooting lesson. The upcoming lessons will describe other tools and interesting

technologies such as VLANs, Spanning-Tree Protocol. Once we finish with foundations related to layer 2, we'll start discussing layer 3 technologies and concepts such as IP addressing, subnetting, routing etc.

Lesson 13 - Layer 2 Connectivity Troubleshooting Part 3 This lesson is the last one in the series on how to troubleshoot connectivity issues at the layer 2 of OSI model. Bear in mind, that these do not involve layer 2 technologies such as VLANs or Spanning-Tree Protocol, since we have not talked about those yet.

NOTICE The steps presented in this lesson are not the ALL possible diagnostics you can do. And they do not have to be done in this specific order. I am merely listing some logical steps which might be useful in order to 'nail down' the root cause of the problem.

Trouble Ticket 3New installation as per Pic. 1 shows lack of connectivity between the two computers. Initial diagnostics performed revealed the following facts:

Switches are connected via fibre optics cable and the ports show proper status (interface is up, line protocol is up).

Computers have proper addresses and subnet masks assigned. Cables connecting computers with switches have been tested and proved to be working correctly. Computers reply to echo requests packets (firewalls disabled).

The technician who set up this new network calls you for help.

Pic. 1 - New design with connectivity problem

Icons designed by: Andrzej Szoblik

Dealing with this trouble ticket we are going to collect the tools we used in the previous lessons trying to resolve this issue.

Step 1

First let's try to 'divide and conquer' (concept mentioned in lesson 11) by sending ping packets from PC1 to PC2. Before we do that though, we need to purge the existing ARP cache on PC1 and PC2 to have a fresh information. We do that by opening Command Line Interface window and typing: arp -d host-address (linux), or arp -d (MS Windows).Test results:

The pings timed out. No reply from PC2.

Step 2Since the ARP cache entries age out relatively quickly (depending on which operating system you use), we need to quickly check what they contain Alternatively we can send large series of ping packets.Test results:

PC1 does NOT contain expected mac-to-ip mapping. We expected to see192.168.1.2 at 00:1e:4f:b0:b2:fc. It is not there, though.

PC2 DOES contain the the right mac-to-ip mapping. It shows the following:192.168.1.1 at 00:50:bf:9c:45:6a.

These are very interesting results, don't you think? Before we take the next step let's gather what we know so far.

Since the ping was initiated by PC1, it sent its ARP request broadcast message and that query must have been delivered to PC2. We can conclude that, based on the fact that we have cleared PC2's ARP cache in step 1, and it has the proper mapping now. PC2 did receive ARP request from PC1 and learned what MAC and IP address it uses. 

Step 3We could omit that step, but we're curious if PC2 replies to the ARP request from PC1. We launch our 'wireshark' tool on PC2, ping again from PC1 to PC2 and capture all packets on PC2. What we discover in this packet trace is that PC2 has replied to ARP request with proper ARP reply unicast message back to PC1.

Step 4Clearly, something between the computers (switches) does not work properly. It seems that we have some sort of unidirectional communication. What we need to establish is, where this unidirectional communication is taking place. We login to the SW1 and SW2 and issue the following commands ('x' here stands for switch number in Pic. 1):

SWx#show mac address-table interface f0/1SWx#show mac address-table interface f0/24

Test results:

SW1 learns source MAC address of PC1 (00:50:bf:9c:45:6a) on its Fa0/1 interface. This is expected.

SW1 does NOT learn MAC address of PC2 (00:1e:4f:b0:b2:fc) on its Fa0/24 interface. This is unexpected. It should learn it from the ARP reply sent by PC2.

SW2 learns source MAC address of PC2 (00:1e:4f:b0:b2:fc) on its Fa0/1 interface. This is expected.

SW2 learns source MAC address of PC1 (00:50:bf:9c:45:6a) on its Fa0/24 interface. This is expected.

This way, we have discovered that SW1 has unidirectional link towards SW2 (SW2 sends frames towards SW1 but the latter does not seem to receive those). Probably, the fiber optics connection does not work properly (grease, dirt, a strand is broken etc.).

One more time, this lesson illustrates how useful the commands and knowledge described in the previous posts, can be in real life scenarios. 

In my next post, I will show you how to log system messages so they can be analyzed later. System messages are invaluable pieces information in the process of troubleshooting networking issues.

Lesson 14 - NTP and Syslog Services My previous three posts were a humble attempt to show you some real life networking issues and how to go about them using the skills described so far.

In this lesson I would like to present two services that are extremely important in management of your switches and routers: Network Time Protocol, and Syslog Services. Even though you will not find them in CCNA curriculum, it is good idea to know what is their role and how to quickly configure them on your devices.

System MessagesIf you work as a network admin, it is critical that you collect and analyze system messages sent by switches and routers. IOS can send those important messages to the console port 0 by default. You can store them in the switch or router's memory but they will be purged if you have power outage or reboot your device. Also, memory will store as many of them, and then it will begin to overwrite the oldest ones. We need to redirect them to an external server. One of the popular services used to collect system messages is called: Syslog Server. If you are Window user you must probably pay for such server software (although KIWI server used to be freeware, but I don't know if it still free software). Unix and Linux have this service installed by default. All you have to do is to set it up correctly, so it accepts messages from external clients.

If you want to check how to do it using Ubuntu Linux distribution, please refer to my small Ubuntu notepad at: http://ubuntu-garage.blogspot.com/2010/09/ubuntu-syslog-server.html

System messages have the different levels of severity as shown below.

0 - Emergency - System-unusable messages1 - Alert - Take immediate action2 - Critical - Critical condition3 - Error - error message4 - Warning - warning message5 - Notice - normal but significant condition6 - Informational - information message7 - Debug - debug messages and log FTP commands and WWW URLs

As you see, the lower the number the higher severity the level is. I'm sure I don't have to tell you that the levels 0-3 will need your special attention, do I?

System Logging Message takes the following format:

timestamp%<facility>-<severity>-<mnemonic>: <message-text>

Take a look at such message as sent by IOS (Pic. 1)

Pic. 1 - IOS Syslog Message Example.

Network Time Protocol (NTP)All messages should carry a time stamp. The time of an event allows administrator to see when things went hairy and correlate them with other events that might follow. The problem is that Cisco devices do not keep the date and time like computers do. In order for them to keep the track of time you must either manually set the clock with 'clock' command or synchronize their time with some external sources. The first method is not recommended as after reboot, a router or switch loses its time. That is why the second method is recommended using NTP protocol.

It is not my intention to give you an in-depth description of NTP and syslog services. Instead, I would like to draw your attention to those services and show you how to set it up quickly.

NTP server information:

NTP Server IP = 10.1.1.1NTP Password = S3cr3t!!!NTP MD5 Key = 1

Step 1Create MD5 key 1 to authenticate with the NTP server.

R1(config)#ntp authentication-key 1 md5 S3cr3t!!!

Step 2Enable authentication for NTP.

R1(config)#ntp authenticate

Step 3Tell the router which key our router trusts (we have only one but may use more in the future). We do not want to accidentally synchronize the time with same 'fake' server.

R1(config)#ntp trusted-key 1

Step 4Finally, configure IP address of the NTP server and specify which key to use for authentication.

R1(config)#ntp server 10.1.1.1 key 1

In case you did not use authentication (not recommended), you would be typing in the step 4 line without the 'key 1' argument.

Verification

Notice!It is recommended that you initially set the clock manually before you allow NTP synchronization. Big time gap between your router and the NTP server clocks, will make synchronization extremely long process.

Step 1 - Check the status of NTP

R1#show ntp status

Clock is synchronized, stratum 5, reference is 10.1.1.1nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18reference time is D04096A6.9715EE2B (14:03:18.590 UTC Sun Sep 19 2010)clock offset is -7.9613 msec, root delay is 3.83 msecroot dispersion is 14.74 msec, peer dispersion is 6.74 msecR1#

Step 2 (optional) - Check NTP association.

R1#show ntp association

      address         ref clock     st  when  poll reach  delay  offset    disp*~10.1.1.1         127.127.7.1       4     9    64  377     5.6    4.22    13.4 * master (synced), # master (unsynced), + selected, - candidate, ~ configuredR1#

Step 3 (optional) - Check NTP association details.

R1#show ntp association detail

10.1.1.1 configured, authenticated, our_master, sane, valid, stratum 4ref ID 127.127.7.1, time D04097CC.0209500C (14:08:12.007 UTC Sun Sep 19 2010)our mode client, peer mode server, our poll intvl 64, peer poll intvl 64root delay 0.00 msec, root disp 0.03, reach 377, sync dist 10.239delay 7.72 msec, offset 5.1799 msec, dispersion 6.35precision 2**24, version 3org time D04097E6.97A012CA (14:08:38.592 UTC Sun Sep 19 2010)rcv time D04097E6.98D73524 (14:08:38.597 UTC Sun Sep 19 2010)xmt time D04097E6.905799B4 (14:08:38.563 UTC Sun Sep 19 2010)filtdelay =    33.02    7.72   15.73   22.32    5.65   27.62   23.62   15.66filtoffset =   11.77    5.18   13.89   23.08    4.22    7.94   12.65    3.32filterror =     0.02    0.99    1.97    2.94    3.92    4.90    5.87    6.85

Syslog Server Configuration

Syslog Server Information:IP address = 192.168.1.2Facility = Local7

R1 Configuration:

R1(config)#logging host 192.168.1.2 R1(config)#logging facility local7

From now on, all system messages are going to be sent to syslog server with ip address 192.168.1.2.

In my next lesson, I'm going to introduce another layer 2 technology: Virtual LANs (VLANs).

Lesson 15 - VLANs Overview At this stage you should be familiar with the concepts related to TCP/IP traffic flow and switch operation. You should also feel confident about how to diagnose basic layer 2 connectivity issues. For the details please review my previous posts. In this one, I am going to extend your understanding of layer 2 technologies by introducing Virtual LANs (VLANs).

Before I introduce our main topic let's define the problem which VLANS address first. This way, it's going to be easier to understand them.

Problem With SwitchingAs you remember from previous lessons, each port of a switch creates its own collision domain (for details look at lesson 9 in this tutorial). In addition to that a switch can use FULL DUPLEX connectivity when connecting other devices to its ports (computers, printers, switches, routers). That allows the ports to SEND and RECEIVE streams of bits at the SAME time. This is due to the special design of a switch. Thus, the efficiency of transmission is radically increased when compared to its older cousin a hub using half-duplex connections (sending or receiving but not both at the same time).

However, switches still maintain ONE BROADCAST DOMAIN. This means that in some situations they flood frames out of all active interfaces except the one that receives the frame. The flooding occurs if either of these are true:

1. The destination MAC address of the arriving frame is unknown. 2. The destination MAC address of the arriving frame is broadcast. 3. The destination MAC address of the arriving frame is multicast. 4. A switch reaches its limit of MAC addresses learned on a port. Then all other MAC addresses can

no longer be learned.

Pic. 1 - Switches maintain one broadcast domain (bottom left computer sends broadcast).

Icons designed by: Andrzej Szoblik

In a flat network like the one depicted above (Pic. 1), imagine a thousand computers sending broadcast traffic (e.g. ARP requests). They will be propagated everywhere as per rules described earlier. Imagine another situation in which a broken NIC (Network Interface Card =  Network Adapter) sends thousands of broadcast frames per second. Those will be flooded to all hosts interrupting them as they need to process broadcast frames. In those situations not only do we interrupt all hosts by sending frames to them, but also saturate links with garbage data unnecessarily. Why would my computer have to listen to broadcast traffic sent by HR server if I work in IT department? I do not use HR server's resources at all. Exactly!

VLANs Are Broadcast DomainsVirtual LANs are the method of creating multiple broadcast domains of smaller size in a switching infrastructure. They are commonly used solution to the above mentioned problems. By configuring VLANs on the switches you create multiple broadcast domains which are treated as separate, isolated LANs which CANNOT communicate with one another by default. This allows us to contain the broadcast/multicast/unicast traffic WITHIN a boundary of a given VLAN. 

Pic. 2 - VLANs Are Broadcast Domains

Icons designed by: Andrzej Szoblik

If you consider traffic in the Pic. 2, the computers in red transmit their bits onto the wire, switches will send those only to computers that are in the same VLAN, that is red in this case. For instance, if the bottom right red computer sends layer 2 broadcast (destination MAC address = FFFF.FFFF.FFFF), only computers in red VLAN are going to receive this transmission. Computers located in turquoise VLAN will NOT receive those frames anymore. This way we can segment the traffic between different hosts based on criteria such as groups of interests (workgroups), type of traffic (e.g. VoIP), type of the application used, user location, etc. So, the major benefits of using VLANs are: 

1. Broadcast/multicast traffic propagation is limited to a given VLAN (broadcast domain) where it originated.

2. Security is increased, as hosts located in different VLANs CANNOT communicate at all. The only way for them to communicate is to allocate different network/subnet addresses for VLANs and use a layer 3 device (router) to move the packets between them. The routers offer some control as to who can transmit to whom (ACLs, firewalls etc.). How to accomplish routing between VLANs I will explain in my next post.

I hope the above description sheds enough light on what VLANs are used for. Now, is the time to look at some details regarding their configuration.

VLAN Port TypesIn order to segment the traffic, the hosts generating it must be assigned to the appropriate VLAN since all ports of the switch are members of VLAN 1 by default. The process of configuring that usually involves three major steps:

1. Configuring VLAN number in the switch database (optionally name of the VLAN and/or other parameters).

2. Assigning hosts to VLANs defined in step 1. There are two ways of doing that: either MAC address can be assigned to a VLAN (dynamic method), or port of the switch can be assigned to a VLAN (manual method).

3. Configuring VLAN Trunk connections between the switches. Even though, this step is optional, the majority of designs out there will need it.

The above mentioned configuration steps define two different port types VLANs can use:

1. Access Port - this type of port can be member of ONE VLAN ONLY. If a static port-to-vlan configuration is used, the port interprets all incoming frames as belonging to this specific VLAN. In case of using mac-address-to-vlan configuration the port will determine VLAN number (ID) for transmission based on the MAC address which is mapped to a specific VLAN.

2. Trunk Port - which by default belongs to ALL VLANS (1-4094). In other words, this port is capable of sending and receiving a traffic coming from different VLANs.

When is the trunk (multi VLAN) port required?

The below picture (Pic. 3) illustrates the need for it.

Pic. 3 - VLAN Port Types

Icons designed by: Andrzej Szoblik

The grey rectangles symbolize two switches. The colors, represents different ports assigned to different VLANs. Of course, VLANs in practice use numbers, not colors, to distinguish between themselves. When any bottom computer sends broadcast (or unicast towards another computer in the same VLAN/color connected to the upper switch), the port connecting the two switches must be trunk (multi-vlan port). In such situation w must allow all VLAN members to communicate with their peers in the same VLAN, irrespective where they are located. Both switches have yellow, red and blue members here! And according to the rules, red computers must be able to talk to all red computers located on the same and all other switches as well (yellow-to-yellow, and blue-to-blue).They are members of the same Virtual LAN after all.

In such design, in which members of the same logical network (VLAN) or broadcast domain are connected to different physical switches, the connection between them must be a trunk. Trunk ports run a special protocol called IEEE 802.1q (Cisco have also their own protocol called ISL, details of which are beyond the scope of this tutorial). This protocol is responsible for 'tagging' the frames (injecting extra information into their headers), while sending them out the trunk port.

Why?

Let me explain. Look carefully at the Pic. 3 and imagine that the computer connected  to yellow VLAN is sending broadcast towards all computers that are in the same, yellow, VLAN. The port between the switches is trunk, and as such allows ALL VLANs in and out. But the problem is that the receiving port on the upper switch gets the Ethernet frame on the port working as trunk as well. So, this port is also a MULTI-VLAN port! How does this upper, receiving, switch know which VLAN the frame is coming from? Well, it does NOT know whether the VLAN sending this broadcast was yellow, red or blue. This is where the sending (bottom) switch, using the trunk as outbound port, is going to inject extra 4 bytes into the Ethernet frame while transmitting it out. The tag will contain VLAN ID (number) of the sender. This way, the broadcast frame will have an extra information allowing the receiving switch (upper one) to recognize which VLAN it is coming from and forward this broadcast to ALL computers in the same VLAN (here yellow VLAN).

NOTICE!The TAG  is stripped off on the outbound ports configured as ACCESS ones. The tag is useful only on trunk ports.

Before we finish this VLAN overview lesson, let me show you what information this TAG contains.

Pic. 4 - 802.1q TAG

The 802.1q tag is injected between the source MAC address and the type field in the Ethernet II header (pic. 4). It consist of two fields taking two bytes each:

1. First two byte field contains a signature of 802.1q protocol using value of 0x8100. 2. Second two byte field  contains:

PRI - Class of Service 3 bits used by QoS,  Canonical bit for token ring support,  VLAN ID value that takes up 12 the least significant bits in the tag.

802.1q Native VLANThere is one more thing I need to touch upon that is related to the 802.1q trunk port. That is the concept of Native Vlan. The designers of the protocol decided to send frames coming from so called 'native VLAN' out the trunk as UNTAGGED. In other words this frame does not have any tag inserted into the Ethernet header. So, frame coming from 'native VLAN' is a regular Ethernet frame. As long as the switches agree on the trunk link which VLAN is their 'native VLAN' for this trunk, a frame arriving on the trunk port without the tag is assumed to be coming from the same native VLAN the sender was transmitting. The default  'native VLAN' is VLAN 1, since this one cannot be removed from the switch. Probably the reason VLAN 1 is the 'native VLAN' by default is becuase switches originate frames such CDP, VTP, STP from this VLAN and there is no need to tag them as they are switch-to-switch communication only.

NOTICE!As of the time of writing this tutorial, all ports of Cisco switches belong to VLAN 1 by default which is also the (untagged) 'native vlan'. That VLAN is not going to tag frames on trunk-to-trunk connections.

I am sure you realize what can happen if the two ports connecting switches use different VLAN ID for their 'native VLAN'. Yes, that can cause leaking frames between VLANs. And this is a serious security issue. So keep the same 'native VLAN' on trunk paired ports between switches.

In my next post we will look at the same concepts from the command line perspective. I will also introduce VTP protocol as well as Inter-VLAN routing.

Lesson 26 - Binary World The routing world awaits. But before we plunge into its depths, it is imperative that we become fluent with conversions between decimal and binary numeral systems. Why? Because all electronic devices such as our beloved computers and routers use binary numbers. On the other hand, we humans tend to use decimal notations almost all the time.

Believe it or not but the binary numeral system is easier to understand than the decimal one. But our problem is that we have been using the decimal notation for so long that looking at anything different feels very awkward.

It is good to know that all numeral systems (binary, octal, decimal, hexadecimal, the-one-you-may-want-to-create) are based on the same foundations. There are two major components of a numeral system: the base and the exponent.

Pic. 1 - Numeral System Components - The Formula.

I almost hear your thought: 'Eh... what?' Fear not. It's easy to understand if you remember the math at the elementary level.

The base in the above formula is determined based on how many digits (or characters) we use to denote the number. Consider the decimal system. We have exactly 10 digits to express the volume: 0,1,2,3,4,5,6,7,8,9. So, the in decimal numeral system the base = 10 (ten digits available). What happens when we have more of something than 9?

It is simple we engage a new column of numbers on the left and zero the number on the right: 10. This way we get ten. The first column denotes the number of 10s and the next column, denotes the units. As soon as we run out of numbers in the unit columns, we increase the number in the columns of tens. For instance: 17, 18, 19... 20.

What happens when we run out of the number of the column of tens? We add one more column on the left, which is the columns of 100s and zero all other columns on the right. For instance: 97, 98, 99... 100.

We know that in the four column number: 1048 the first column (1) on the left denotes thousands, the next to the right (0) denotes hundreds, the one next to it (4) denotes tens, and the last one (8) describes units. The column in each and every numeral system has the weight.

Check the picture below to see this in more detail.

Pic. 2 - Decimal Numbers - Formula.

Using the formula you calculate the numbers in decimal as shown in the next picture (pic. 3). Each number in the column must be multiplied by the corresponding weight of the column. These in turn, must be added together to give you the number. Pic. 3 shows that in more detail. Make sure that you understand it before you proceed with your reading.

Pic. 3 - Example of Decimal Numbers According to the Formula.

In exact same way we create others such as the binary numeral system. Here, our base is going to use only two digits: 1 or 0 called bits. Thus, our base = 2 (only two digits available). Since, we most often

cluster 8 bits together to form a byte, our colums and weights are going to look as in the picture below (pic. 4).

Pic. 4 - Binary Numbers - Formula.

NOTICE!Cisco expects their engineers to be able to do the binary-to-decimal and decimal-to-binary conversions WITHOUT using a calculator (using a paper and pen only).

Binary-to-Decimal ConversionIn order to convert the binary number to its decimal equivalent, you must follow the exact same rules explained for decimal system. You multiply the number in the column by its weight in every columns. The products of these multiplications must be added together.Take a look at the example in the pic. 5.

Pic. 5 - Examples of Binary-to-Decimal Conversion.

In order to practice those try to quickly convert the following binary to decimal (DO NOT USE A CALCULATOR):Ex1: 11011010 (calculated above)Ex2: 10011101 (calculated above)Ex3: 11001011Ex4: 00100101Ex5: 01010101Ex6: 11111010Ex7: 01101101.

It should not take you more than a few seconds per example. Check your results using a calculator.

When it comes to opposite conversion it is a bit more difficult, but still at the elementary math level.

Decimal-to-Binary ConversionThe best way to learn how to do the conversion is actually do it and analyse every step of the way.

Example1: the decimal value of 172, to be converted into the binary.

The following table is going to come in handy.

Pic. 6 - Decimal-to-Binary Conversion.

Step 1Find the closest weight value in the binary table that does NOT exceed the value you convert.

In the example1, the closest weight is: 128. The weight of the next column (here, non-existent column 9) would exceed the value of 172, since the weight of it is 256.

Step 2In our handy table, write in ‘1’ in the column you have chosen.

Pic. 7 - Decimal-to-Binary Conversion.

Step 3From the initial decimal number take away the weight you have used (the ‘1’ you put in the table takes away the weight from the number you are converting).

In the example1, the decimal number we have is: 172 and the weight we just used by putting a ‘1’ in our table is: 128. So, our calculation looks like the one below:

172 – 128 = 44

Step 4Check if the number you have left (in our example the value left is: 44) is larger or smaller than the weight of the next column on the right-hand side in our table.

a) If the number you have left is larger than the weight in the next column to the right, put in ‘1’ in the next

column and subtract its weight from the number you have left.

b) If the number you have left is smaller than the weight in the next column to the right, put in ‘0’ in the next column and perform the same check against the next column (step 4a). You have to do it until the check in step 4a is true.

In the example1, the value we have left is: 44. We check it against the weight in the next column on the right. The number (44) is smaller than the weight in the next column to the right (64). Since 44 < 64, we follow the instructions in the step 4b.

Pic. 8 - Decimal-to-Binary Conversion.

The next check against step 4a is true! Since 44 > 32, we put in a ‘1’ in the next column and take away the weight (32) from the number we have left (44).

Pic. 9 - Decimal-to-Binary Conversion.

44 – 32 = 12

We go back to the step 4.

The number we are left with (12) is smaller than the weight of the next column to the right (16). Since 12 < 16, we proceed to the step 4b.

Pic. 10 - Decimal-to-Binary Conversion.

The next check against step 4a is true! Because 12 > 8 we put in a ‘1’ in the next available column on the right and take away its weight (8) from the number we are left with now (12).

Pic. 11 - Decimal-to-Binary Conversion.

12 - 8 = 4The difference is: 4. I hope you already know what is going to happen. Step 4a is true, so we put in a ‘1’ in the column and take away the weight from the number.

Pic. 12 - Decimal-to-Binary Conversion.

4 - 4 = 0 

The difference now reaches 0, so we fill in the remaining columns with 0.

Pic. 13 - Decimal-to-Binary Conversion.

In order to practice those try to quickly convert the following binary to decimal (DO NOT USE A CALCULATOR):Ex1: 172 (calculated above)Ex2: 67Ex3: 124Ex4: 168Ex5: 215Ex6: 237

It should not take you more than a few seconds per example. Check your results using a calculator.

Understanding and fluency with the conversion is the pre-requisite to calculating IP subnets, maximizing the addresses per subnets etc.

In my next post, we will take a look at IP address and play with subnet calculations.

Lesson 27 - IPv4 Address Dissected - Part 1 If you already feel comfortable with binary-to-decimal and decimal-to-binary conversions you're up to this post's challenge: learning more about IP version 4 address (IPv4). If you need to brush upon the numeral conversions, check my previous post.

In one of the earlier posts on TCP/IP traffic flow, I briefly described the importance of the addresses. In order for devices to communicate they must be uniquely identified in the network after all. There are typically three such identifiers we use to distinguish between devices:

1. Names - These are used by humans. Applications use addresses not names. Hence, DNS services out there (DNS service is used to resolve names-to-ip, and ip-to-names).

2. Layer 3 addresses - logical and hierarchical unique identifiers of devices in the network. All layer 3 protocols such as IPX, Apple-Talk, IP etc. use different forms of layer 3 addresses. 

3. Layer 2 addresses - flat and most often fixed identifiers of devices (see lesson 6).

DNS NamesNames are used to simplify communication between devices for people. Instead of typing something like this in your web browser: http://72.163.4.161/, which will open the Cisco web server's main page, you prefer to type something like that: http://www.cisco.com/, don't you? If you do the latter, before your web browser sends the request to the Cisco's web server, it will need to ask your local DNS server about the IP address that is associated with the name www.cisco.com. 

Layer 2 addresses Since the communication between computers is loosely based on well known OSI model (TCP/IP model is based on it which I described in lesson 4), all upper layers are ultimately encapsulated in a layer 2 header which uses flat form of the address. Such addresses are Ethernet MAC addresses, Frame-Relay DLCI numbers, ATM VCI/VPI pair of numbers etc. What these are depends on what layer 2 technology you use.

Layer 3 addressesLayer 3 addresses are logical and hierarchical. This post is about IP addresses, but keep in mind that in the past we used to use other routed protocols as well (such as Apple-Talk, IPX and others). These other protocols also used layer 3 addresses that were logical and hierarchical.

IP address (which in OSI terminology is an example of layer 3 address ) is logical. This means, that you can easily change it either manually or using dynamic address assignment (DHCP) service. Consider your private laptop that you use at home. It, most likely, gets an IP address from the DHCP server configured on your broadband router. Then, the following day you take it to work with you. The moment you hook it up to your corporate network its current IP address will be replaced by a new one provided by the corporate DHCP server. It is almost for sure going to be different than IP address your computer uses at home. So the word: logical, describes the volatile nature of the address. The same device can use a different layer 3 address (identifier in the network) depending which network it resides on.

IP address is hierarchical. It is a bit similar to a telephone number as it has a structure. In telephony we use similar concept of hierarchy. Consider this phone number:001 201 555 1234.

The structure of this phone number has the hierarchy which looks as follows:00 - the number identifying an international call1 - the prefix denoting country. Here: it is USA.201 - number denoting the state in the US. Here: it is New Jersey.555 - number of the telephone exchange in New Jersey (here it is a fictitious one)1234 - number of the subscriber connected to this fictitious exchange. 

The reason I show you this, is that what seems to be a simple and flat 13-digit phone number, in fact has a hierarchy built in it. The numbers carry special meaning. The same is true about layer 3 addresses in computer networks.

IP address structure consists of two components:

1. Network or subnet address (identifier). 2. Host address (identifier) in the network or subnet.

Let us dissect both components using your computer's IP address as an example. Open the command line window and type in the following command:

in Microsoft Windows:c:\ipconfig

in Linux/Unix/Mac OS:$ifconfig eth0

Look at my computer's address below.

Pic. 1 - Output of 'ifconfig eth0' command.

Can you find MAC address, IP address and Netmask in the above output?

MAC address: 00:1e:4f:b0:b2:fcIP address: 192.168.1.2Netmask: 255.255.255.0

An IP address uses four numbers and dots as the delimiter. Each number is a one byte number which means that it must be in the range of 0 through 255 using decimal notation.

IP address uses another four byte number that follows it called: network mask (aka netmask). It is the netmask that creates the hierarchy in the IP address. It separates the bits in the address to tell us which ones denote the address of the network/subnet and which ones denote the host address in the network/subnet. In order to see that, check my IP address in the pic. 2 below. The first three bytes (24 bits) denote the address of the network, and the remaining byte (8 bits) denotes the host address in the network.

Pic. 2 - IP address in decimal notation.

In order to actually see the hierarchy presented in pic. 2, let us convert the IP address into binary first.

Pic. 3 - IP address decimal-to-binary conversion.

Now, convert the decimal netmask we use in the example (255.255.255.0) into its binary equivalent. What is it going to be?

 Pic. 4 - Network mask decimal-to-binary conversion.

Network mask bits correspond to the IP address bits. The bits in the IP address which are masked by the network mask bits (1s) denote the network portion of the address. The bits in the IP address that are not masked (corresponding bits in the netmask are 0s), are denoting the host address in the network. Let us combine the IP address bits with the netmask bits to see the hierarchy now.

Pic. 5 - IP address and the network mask create hierarchy.

Clearly, the first three bytes (192.168.1) in the IP address are masked (255.255.255). Those twenty four bits are the NETWORK bits, the remaining eight bits in the address (2) are not masked (netmask bits are all 0) and become the HOST bits in the address.

The hierarchy in my computer's IP address could be depicted like this:

Pic. 6 - IP address Hierarchy.

There is a bit more we need to know about IP addresses.

In my next post I will continue on explaining what IP address classes are and how they are used today. Also, I will describe the concept of network and subnet and the difference between them. I will finish IP address description by telling you about certain reservations in the IP address range we must be aware of. This and the next post will be the pre-requisites for the upcoming lesson about calculating subnets.

Lesson 28 - IPv4 Address Dissected - Part 2 In my previous post I have talked about the hierarchy in IPv4 address. It is the network mask that tell us which bits form a network address and which ones denote the host in the network. But there is more to it ...

You already know that IP address and its network mask create a unique layer 3 identifier of a host. This allows devices to communicate. When a computer sends a packet, it will put the address of the recipient in the IP header as the destination. It also puts its own address (sender), so the recipient knows who sent the packet and to whom a reply should be sent.

After reading my previous post it may seem clear what a network and a host in the network are. But you may still ask: "What is a network anyway?". As strange as it sounds, the answer to the question may not be as simple as one might think.

We tend to divide our networks into multiple pieces that are uniquely identified with the network portion of the address (masked by network mask bits set to 1). Individual hosts placed in those networks will also have unique host portion of the IP address (network mask bits set to 0). They are unique in their network.

Why do we break down the company's infrastructure into multiple chunks called networks?

There are many reasons we do it.  Larger networks are harder to maintain and become very inefficient as the hosts receive too many broadcast transmissions (broadcast=one packet to everyone). Also, it is easier to control traffic and tighten the security when dealing with multiple networks rather than doing so in one single organism. So, we separate hosts using layer 3 devices called routers and address them uniquely, thus creating multiple interconnected networks. The routers that connect networks become the gateways between them allowing unicast communication (one-to-one). At the same time they do not allow broadcast traffic (one-to-everyone) to go through. They also are equipped with many mechanisms to control the traffic traversing through them.

How we divide our system into multiple networks may be depended on numerous factors. For instance, a network in the building can be divided based on the floors. First floor is the first network, second floor is the second network etc. Other division could be made based on the departments in the corporation. HR is going to be one network, Legal Dept. another etc. Either way, computers will belong to one of these networks, but all of them together will still belong to the same company.

So, what is a network? A network is a group of devices that share the same network portion of the address. That portion is dictated by the length of the network mask. These bits mask the corresponding bits in the address. But this you already know. However, there are a few more things you need to know.

Consider this picture.

Pic. 1 - IP Networks.

Icons designed by: Andrzej Szoblik

What do we see in the picture?

In the middle sits a layer 3 device called a router (R1). I will devote a whole post on what it is and what its functions are. Meanwhile, let's carry on with our description.

The router (R1) connects two different networks. It becomes the gateway between them. This means it allows communication between them (unicast by default). The two networks in the picture have the following addresses:

1. The network on the left-hand side has the address of 192.168.1.0/24. 2. The network on the right-hand side has the address of 192.168.2.0/24.

The switches (SW1 and SW2) are transparent in terms of layer 3 communication. Remember? They are layer 2 devices, and do not have a clue what IP addresses are.

Finally we have two computers. PC1 belongs to the network 192.168.1.0/24, PC2 belongs to the network 192.168.2.0/24. Both have the same host identifier in the last byte of their IP address: 1. But their network portion of IP address is different. As a result of that the belong to two different networks. Just like two Mr. Smiths who live in two different houses on two different streets of the same town.

PC1: 192.168.1.1/24PC2: 192.168.2.1/24

Have you noticed that the third octed (from the left) has different number? That makes the network portions of these two addresses unique.

What does this /24 mean in the address?

As you already know the netmask separates a network from a host portion of the address. Both IP addresses and their network mask are presented in the decimal notation with the length of network mask

(/24). Yes, the shortcut /24 means, that the network mask is twenty four bits in length. This in turn, means that the first twenty four bits of the IP address is the network portion. The remaing eight bits are the host address in the network. Check it out below.

Pic. 2 - PC1 address with the netmask 24 bits (/24).

Looking at the binary, we see that /24 = 255.255.255.0.If we convert 255.255.255.0 into binary we get twenty four 1s in the network mask, giving us three bytes of the network address. The remaining eight bits in the network mask are all 0s. This way, the last byte (8 bits) becomes the host identifier int the network 192.168.1.0.

Interestingly enough, many moons ago, there were no networks mask in use. So, how on Earth, did the devices know which bits of IP address were network bits and which were the host bits? The designers of IP addresses divided IP addresses into five different classes. The first byte of any IP address (on the left) determined which class an IP belonged to and how many bits of the address were network bits. Today, this is known as the first octet rule.

IP Address ClassesThe value of the first byte in the IP address determines its class (the first byte on the left-hand side).

Class A - values 0 through 127 Class B - values 128 through 191 Class C - values 192 through 223 Class D - (multicast) - values 224 through 239 Class E - (experimental) - values 240 through 255

This stems from the fact that some assumptions have been made regarding the most significant bits in the first octet (byte). The below table shows (in red) these bit reservations. They are fixed in the class and cannot be changed.

Pic. 3 - IP Address Classes.

As the result of such reservations in class A, class B and class C, one two and three bits respectively, the decimal values of the first octet are as follows (pic. 4).

Pic. 4 - IP Adress Classes and First Octet Rule.

This way, devices could easily determine which class of IP address the deal with by looking at its first byte (Pic. 4). Knowing which class the IP address belonged to help them determine which bits described network address, and which bits denoted a host in the network (Pic. 3 highlighted in green).

Fast forward to the present day. We still use the concept of IP address classes. And as such we refer to the so called: natural network mask (length).

Class A - Natural network mask length = 8 bits (/8) or, 255.0.0.0 Class B - Natural network mask length = 16 bits (/16) or, 255.255.0.0

Class C - Natural network mask length = 24bits (/24) or, 255.255.255.0

I would like to finish this post with one last observation. If your IP address uses the natural network mask length given the class (A, B, or C), we call this address a network address.

If your IP address uses the network mask length longer than the natural network mask used by this class, we call this IP address a subnet.

In my next post, I will show you how you can create subnets and how to calculate those given the host requirements.

Lesson 29 - IPv4 Subnetting - The Rules Now, that we have already learned a few things such as conversions between binary and decimal, how to recognize classes of IP addresses based on the 'first octet rule', and what is the purpose of the network mask, we can tackle IP subnetting.A natural (default) network mask is used with class C of IP addresses quite often. But it is very uncommon to use class A and class B IP addresses with their natural netmask. They are often sub-netted (broken down into multiple smaller networks). This is accomplished by increasing the length of the default (natural) network mask.

 Incidently, the network IP addresses that use their natural (default) network mask are called Classful Networks.

But why do we create subnets to begin with?

There are many reasons why we decide to use subnets rather than classful networks. But the most important is that we want to use IP addresses efficiently since they are a scarce resource these days.

Imagine that you have a huge network to support. It uses class B network address: 172.16.0.0/16. Since the number of bits in the host portion of this address is 16 (the last two bytes are not masked), we can place 65534 hosts in a single network. Even if you used 2000 hosts still it is too much to keep them in one broadcast domain. Can you imagine that many computers sending and receiving broadcasts such as ARP requests? Well, I can imagine that, but it does not mean its efficient. In fact, broadcast traffic would pretty much kill this network. Even with thousand computers that would be way too much broadcast traffic to receive.

If we divide this huge network into multiple subnets with fewer hosts per subnet, we improve the efficiency of the system. A router will connect those subnets to allow unicast communication, but broadcasts will not be propagated between subnets as routers do not forward them. For instance: 172.16.1.0/24 subnet allows only 254 hosts in it. The broadcast will be propagated between this number of hosts rather than among one or two thousands of hosts.

Another reason for using subnets is about relates to public IP addresses that are leased to customers. ISPs do not easily give out whole classes of IP addresses (classful) to companies but rather portions of these (subnets).

Other reasons may be related to security of your hosts. Network divided into chunks with routers as gateways, give you more control as to who can 'talk' to whom.

I use terms such as broadcast or unicast. If you are not sure what these terms mean, let me present brief definitions.

Transmissions:

Unicast - a single source host sending to a single destination host.Example: Src=192.168.1.1, Dst=192.168.1.2

Broadcast - a single source host sending to all hosts in the network/subnet. Example: Src=192.168.1.1, Dst=192.168.1.255 (more on this address later in the post)

Multicast - a single host sending to a single group of hosts (IP class D)Example: Src=192.168.1.1, Dst=224.10.10.10.

There are three things I would like you to remember before we delve into subnetting.

Rule 1

1. If the host bits in a given IP address are all set to '0', this is the network or subnet address. 2. If the host bits in a given IP address are all set to '1', this is the broadcast address (all hosts in

the subnet/network are destination).

Rule 2The formula used to calculate the number of available subnets given the specific length of network mask.

Pic. 1 - Number of Subnet Calculation  - Formula.

Rule 3The formula used to calculate the number of available hosts per subnet or network given the specific network mask.

Pic. 2 - Number of Hosts Per Network/ Subnet - Formula.

Before we start using the above rules, let me show you a few examples of network, subnet and broadcast addresses based on what we have discussed in the last three posts including this one. If you do not remember the 'first octet rule', which determines the class and the default network mask of an IP address, use the following table as the reference. The number ranges of the first byte determine the classes as shown in pic. 3.

Pic. 3 - Classful Address Table.

Pic. 4 - Network (classful) Addresses and Subnet Addresses (classless).

In order to determine the number of subnet bits to use them as the exponent in the above formula (pic. 1), you must first know what is the default network mask of the IP address according to its class (pic. 3). Then, you must count the bits that were added to this default network mask. These bits allow a number of subnets to be created as per formula in pic. 1. Check out the below example.

Pic. 5 - Number of Subnet Bits (Example).

In the example (pic. 5), IP address belongs to class C since the first byte value is 192 (compare it with pic. 3). Class C uses first three bytes (24 bits) to denote the network portion of the address. Today we can say

that its default network mask has the length of 24 bits (255.255.255.0). Since our network mask length is /28, we have extended the default network mask by 4 bits (bits in the green color). Thus, we get 4 subnet bits that must be used in our formula presented in pic. 1.

Pic. 6 - Number of Subnets Available - Calculation.

Using the same example: 192.168.1.0/28, how many host addresses per subnet can we use?

Pic. 5 shows us that with /28 we have 4 bits left for host (total number of bits = 32). In order to calculate the available number of host addresses we must resort to formula presented in pic. 2.

Pic. 7 - Number of Hosts Available - Calculation.

Make sure you understand how the three rules presented here work. In my next post, I'm going to show you how to use them to calculate the subnets based on different criteria such as:

Number of subnets per IP address Number of hosts required in the subnet Number of desired host per subnet - Variable Length Subnet Masking (VLSM)

Lesson 30 - IPv4 Subnetting - Practice In the previous post, I showed you three major rules used in calculating subnets. This knowledge can only be verified in practice though. Let me show you a few examples related to subnet calculations. I hope that looking at this topic from different angles is going to help you understand the concept better and feel confident when planning your IP addressing scheme. The first four questions are merely appetizers for a bigger dish: VLSM.

I am going to refer to my previous post's rules while answering the questions (rule 1, rule 2 and rule 3).

If you still do not remember the weights of all bits, you may consider using this little aid presented below (pic. 1) while calculating subnets, and converting binary network masks into decimal values.

Pic. 1- Subnet Calculation Aid.

This tool is useful before you remember all the weights from left to right and right to left.

Pic. 2 - Example of Subnet Binary-to-Decimal Conversion.

Question 1Given the prefix 192.168.1.0/24, what should be the length of subnet mask allowing up to 9 subnets?

Answer 1The address belongs to the class C and uses its default network mask. That leaves us with 8 bits to play with (the last byte). Before we change anything, our address and network mask converted into the binary notation look like shown below (pic. 3).

Pic. 3 - 192.168.1.0/24 in Binary.

In order to create 9 subnets we must extend the existing length of the network mask by 4 bits which allows up to 16 subnets (use calculation aid in pic. 1). If I tried to extend it by 3 bits only, the maximum subnets allowed would be only 8 subnets (rule 2 in lesson 29). So, I must use 4 bits and the result is: 192.168.1.0/28 (192.168.1.0 255.255.255.240).

Pic. 4 - The Answer to Question 1

Question 2

Given the host address 192.168.1.177/29, what are the subnet and broadcast addresses?

Answer 2In order to determine the subnet and broadcast address of the subnet of this host address, we must look at the length of the network mask first. It is 29 bits (24+5). This tells us that the last byte of the address has 5 bits masked (subnet bits) and 3 bits unmasked (host bits). It is a good idea to look at the the last byte of the address (177) with its network mask using binary notation. Pic. 5 below shows you this clearly.

Pic. 5 - 192.168.1.177/29 in Binary.

Since we must determine the the subnet in which the host resides (177 = 10110001), the host portion of the prefix (host bits reside in the last byte) must all be set to '0'. The byte value with the host zeroed is the address of the subnet (rule 1 pkt.1 in lesson 29). This is the result:

Pic. 6 - Host Bits Zeroed = Subnet Address.

The second part of the question relates to the broadcast address of the subnet. As you remember, in order to obtain the broadcast address, you must put '1' on all host bits of the subnet/network. The subnet has already been determined (pic. 6), so let's put '1' on all bits of the host portion:.10110111.10110000 = 176 <- subnet address..00000111 = 7 <- host bits set to '1'

In decimal it is: 176 + 7 = 183The broadcast address is: 183.

The below picture illustrates it using binary numbers.

Pic. 7 - Host Bits Set to '1' = Broadcast Address.

Question 3Given the  prefix 172.16.0.0/17, how many subnets can you create?

Answer3This is a bit tricky isn't it? In order to answer this question, you don't need any calculator, paper or pen. You must trust the rule 2 in lesson 29. The address and its network mask (called prefix) converted into binary look like presented below:

Pic. 8 - The Number of Subnets for 172.16.0.0/17

As you see the number of bits we have extended the class B address is: 1. So, the number of subnets we can create with it is: 2 subnets, since this subnet bit can be either 1 or 0.

Pic. 9 - Questions 3 Answer

Question 4What length of network mask would be the most optimal for router's point-to-point connection?

Answer 4The key to this question is to understand that point-to-point connection needs only 2 host addresses (two points that are connected together). Knowing this, the rest is a piece of cake. We use rule 3 in lesson 29 to determine the length of the network mask that allows 2 host addresses. Check out the picture 10.

Pic. 10 - Calculating Point-to-Point Connection Host Addresses.

If you count ones above the optimal network mask for point-to-point connection is /30. The decimal value is: 255.255.255.252.

Question 5 - Variable Length Subnet Masking (VLSM)It's time for a big one. Given the topology (pic. 11), calculate IP addresses for each subnet trying to optimize them according the host address requirements. The IP address you should use to create subnets is: 192.168.1.0/24. The number of host addresses in the subnets are as follows:Subnet 1 = 46 host addressesSubnet 2 = 16 host addressesSubnet 3 = 10 host addressesSubnet 4 = 2 host addressesSubnet 5 = 2 host addresses

Pic. 11 - VLSM Topology.

Icons designed by: Andrzej Szoblik

As always, if you know the rules and the method, it is going to be easy thing to do. The rules have been discussed in lesson 29, so let me go about this kind of task now.

NOTICE!If your design looks similar to mine (optimizing addresses to the number of host required) you must start the calculation with the largest number of host addresses requirement and work your way down to the least number of host addresses.

This is one of the many methods available. It helps quickly calculate all subnet ranges without using calculator (pen and a piece of paper should do).

Step 1Determine the length of the network mask for each subnet in question. Keep in mind we focus in on the last byte of IP address 192.168.1.0 (8 bits).The first three bytes do not change!

Subnet 1 = 46 Host Addresses

In order to allocate 46 addresses we must use 6 host bits. Why? 5 bits will not be enough as 2 raised to the power of 5 is 32. Also, we must decrement two addresses for subnet and broadcast addresses. So using 5 bits would give you only 30 host addresses. Here we go with 6 bits then:

Pic. 12 - Subnet 1 in Binary.

Subnet 2 = 16 Host Addresses

We must repeat the same math for the remaining subnets.  How many host bits to allocate for 16 hosts (subnet 2)? We must use 5 bits. In case we wanted to use only 4 host bits, the maximum number of hosts is 14 (16 - 2).

Pic. 13 - Subnet 2 in Binary

Subnet 3 = 10 Host Addresses

We continue using the same logic.Pic. 14 - Subnet 3 in Binary.

 Subnet 4 and 5 = 2 Host Addresses Each

On point-to-point links only 2 host addresses area needed. The most optimal network mask is /30 (30 bits).

Pic. 15 - Subnet 4 and 5 in Binary.

Step 2Now, that we know the length of network mask for each subnet, we can start calculating the IP address ranges. 

The subnet 1 address is: 192.168.1.0/26.

The value of the lowest bit in the network mask is going to be our increment used to calculate the next available subnet address. With /26 the increment value is 64 (pic. 16). So, if we add the increment to the last byte, we get the number of our next available subnet address:

192.168.1.0 + 64 = 192.168.1.64.

From there, this next subnet address (value) - 1 is the broadcast of our current subnet:192.168.1.64 - 1 = 192.168.1.63 (current broadcast address)

Current subnet value + 1 = the first host address:192.168.1.0 + 1 = 192.168.1.1 (first host address of current subnet)

Current broadcast address - 1 = the last host's address:192.168.1.63 - 1 = 192.168.1.62 (last host address of current subnet).

Look at the below pictures which illustrate this method.

Pic. 16 - Subnet 1 - IP addresses

Pic. 17 - Subnet 2 - IP addresses

Pic. 18 - Subnet 3 - IP addresses

 Pic. 19 - Subnet 4 - IP addresses

Pic. 20 - Subnet 5 - IP addresses

Now, we're ready to start talking about routing. In my next post, I will talk about a router, its functions,and basic operation. From there, we'll start exploring routing protocols.

Lesson 31 - What is a Router? We take a lot of things for granted. When it comes to technologies it is not necessarily the best idea. The point is to understand. That is why I am going to start my routing section with fundamentals. Knowing them will allow you to learn more advanced topics on your own later. Make sure you are familiar with my previous posts related to binary numbers and IP addressing before you read this and upcoming ones.

Probably the most appropriate question to start with would be ...

What is a router?A router is a specialized computer which can connect multiple networks to allow exchange of packets between them. Since a router uses IP header information (layer 3 protocol data unit), to transmit the packets between networks, this ability makes it a layer 3 device. Like switches, routers build a special database which serves as the source of information on what to do with incoming packets. This database is formally called Routing Information Base (RIB). But most often people call it a routing table. How a router constructs a routing table and maintains information in it, will be the topics of quite a few upcoming posts.

A router is in many ways similar to a regular PC. It has RAM and ROM memory chips as well as CPU and motherboard etc. But instead of using hard drive, it uses a flash memory to store files such as the operating system (IOS). Also, what makes it distinct, the operating system and hardware are optimized for fast packet transmissions. Typically the router uses at least two interfaces but more often than not, it has a greater number of them. Cisco operating system is called Internetwork Operating System (IOS). The same name is given to OS used by many Cisco Catalyst switches. Although some of them may also use CatOS.

There is a great variety of interfaces routers can use. For instance, they can connect few Ethernet networks together, but also Ethernet with Wide Area Networks (WANs) such as ATM, Frame-Relay, X.25, ISDN, Broadband etc.

Router FunctionsIn order for the routers to connect multiple layer 3 networks together, they must be able to do the following:

Learn which networks/subnets are available In case there are multiple paths, choose the the best one Keep (routing table) must be up-to-date Translate layer 2 headers (disparate network connections) Keep loop-free paths Make forwarding decisions based on layer 3 headers

Routing is primarily based on hop-by-hop paradigm. This means that if there are multiple routers in the path, a router must find the outbound interface and forward the packet to a next hop router. A router could not care less as to what happens to the packet after it has been expedited.

In order to find the outgoing interface an IP destination address of a packet and a routing table are used. The process whereby destination IP address is the key information to find the outbound interface for a packet is called destination-based routing. However, it is possible to influence that decision making process and choose other criteria such as source of IP transmission, size of the packet, importance of the packet in relation to others or some other parameters rather than destination IP address. When used it is referred to as the traffic engineering. For now though, I am going to focus in on the default behavior.

Before I describe the router's principles of operation, I must make sure we are on the same page with the fundamentals related to the traffic flow.

Let's recall what happens with the packets sent between computers residing in different networks. I will

use a simple topology (pic. 1) to review a few facts. Please, get familiar with the picture below first. Pay a special attention to the three headers depicted and numbers in green circles. The numbers refer to the steps below. Of course, this is only a ten thousand foot view of what happens here. Before we jump into the deep water we need to warm up a bit by looking at the process from a high perspective.

Pic. 1 - Traffic Flow and Layer 2/layer 3 Encapsulation/Dencapsulation

Icons designed by: Andrzej Szoblik

The numbers in green circles mark the important points of the traffic sent from PC1 (left hand side) to the PC2 (on the right side of the picture).

In the explanation presented below I assume that SW1 and SW2 have populated their CAM tables (learned all MAC addresses on the appropriate ports). Here's how it goes.

Step1 PC1 sends a packet destined to PC2. Since, PC1 has the IP address 192.168.1.1/24, it realizes that the first 24 bits of the destination IP address are different than its own (source: 192.168.1.1, destination: 192.168.3.1). Conclusion: PC2 is NOT in the same layer 3 network, so default gateway (192.168.1.254) must be used to forward the packet to PC2. Knowing it, the IP header is going to use:

Src IP = 192.168.1.1 Dst IP = 192.168.3.1 TTL = 32 (ttl is set by the application, here I use 32 as an example)

IP packet is encapsulation in Ethernet (layer 2) header in order to be put onto the wire. Ethernet header contains source MAC address of the sender, and destination MAC address of R1's F1/0 interface obtained from the computer's arp cache (if not found in the arp cache, arp request is sent):

Src MAC: 0000.1111.1111 Dst MAC: 0000.2222.2222

Step 2SW1 receives the frame on its port F0/1. It locates the outbound port (f0/2) for destination 0000.2222.2222. It sends the frame out towards F1/0 port of R1. Neither of layer 2 or layer 3 headers presented in the pic. 1 change during this transmission (parameters depicted).

Step 3R1 receives frame on F1/0 port. Layer 2 header is inspected by R1. Since the destination MAC address (0000.2222.2222) is the address of F1/0, R1 concludes it is the destination for the frame. Layer 2 header is removed and the content of the message (packet) is processed by the router. R1 processes IP header, reads the destination IP address (192.168.3.1) and compares it with the entries in its routing table trying to find the longest match. More on this in the upcoming post. Once the best path has been found, the routing table points to the outbound interface (F1/1) and the next-hop router's IP address (192.168.2.2) that should be used to expedite the packet.

Step 4The packet is moved to F1/1 port and the TTL number is decremented by 1 (now TTL=31). Then, the packet is encapsulated in the layer 2 header.The following source and destination MAC addresses are used now:

Scr MAC: 0000.3333.3333 Dst MAC: 0000.44444.4444

The destination MAC address is obtained from R1's arp cache. If R1 does not know the MAC address for 192.168.2.2 (next-hop router), arp request is sent asking for its MAC address.

Step 5R2 receives the frame on F1/0 port. It performs the same job R1 has done. It reads the destination MAC address. Since it is the recipient (0000.4444.4444), it dumps the layer 2 frame and processes IP header. It performs layer 3 lookup in its routing table and finds the outbound interface for destination 192.168.3.1. In our example it turns out that the destination network is connected directly to F1/1 interface. In such case, R2 checks arp cache for MAC address of the destination (192.168.3.1) if one is not found, arp request is sent (who's 192.16.8.3.1 ?, I need you MAC address!).

Step 6The packet is moved to F1/1 interface and before it gets encapsulated, the TTL number is decremented by 1 (TTL=30). The packet is encapsulated in an Ethernet frame header using the following addresses:

Src MAC: 0000.5555.55555 Dst MAC: 0000.6666.66666

The frame is sent out F1/1 interface.

Step 7SW2 receives the frame and finds the outbound interface for the MAC address: 0000.6666.6666 int its MAC address table. It is port is F0/2.

Step 8The frame is sent out F0/2 towards PC2. Fields in the layer 2 and layer 3’s headers remain the same.

The above is just a quick review in case you've forgotten that.

The interesting bit for us now is the router's process of finding the outgoing interface and layer 2 addresses of the next hop device. I'm going to elaborate on this in my next post. Now, let me quickly present the routing table components that are essential in this traffic flow.

Pic. 2 - Routing Table Components.

Components of Routing Table:

C and S - point how a router obtained the information (C = connected, S=static route) 192.168.3.0/24 - Example of prefix (destination network/subnet) [1/0] - square brackets show two numbers. First (1) is Administrative Distance, second (0) is

Metric via 192.168.2. - the next-hop-router address

How router populates the routing table, what these terms in red mean and how router uses these parameters to pick the longest match and as a result of that the best path, are going to be the main topics of my next post.

Lesson 32 - Route Selection Process Demystified It is imperative to know how a router selects the best path to some destination network/subnets if it has more than one to choose from. At least if you are serious about learning the routing principles. In this post I'm going to show you the algorithm a router uses to discriminate between multiple paths to the same destination.

A router can learn the routes to remote networks and subnets using manual instructions or by means of configuring routing protocols. This way routers learn how to reach destination networks/subnets dynamically. This post's primary focus is about Interior Gateway Protocols (IGPs) such as: RIP, OSPF, EIGRP. The only Exterior Gateway Protocol (EGP) we use nowadays is called BGP. It uses a bit more complex decision making process and is beyond the scope of this tutorial. In the future I am going to talk about it in more detail in the workbooks I plan to post in the future.

First things first. There are three terms I need to define in order to explain the process of selecting the best route. These are:

1. The Longest Match Rule 2. Administrative Distance 3. Metric

The Longest Match RuleIn the previous post I showed you an example of routing table with a brief explanation about what each column in the output represented. Pic. 1 is the graphic equivalent of it.

When a router receives a packet, while processing the header, it is the DESTINATION IP address that is compared with the entries in the routing table in order to determine the next step. This next step is to find the egress (outbound) interface and the address of the next device to send the packet to. This form of routing is known as the destination-based routing. The process of comparing the destination IP with the prefixes int the routing table is done bit by bit (yes, routers see IP addresses in the binary notation). The entry that has the longest number of network bits that match the IP destination address is always the best match (best path). This is always the FIRST thing a router checks.

If there is ONLY ONE best match, a router has a simple task to do. It moves the packet to the outbound interface (egress) and encapsulates the packet in the layer 2 header according to the technology/protocol that is used on the outbound interface (Ethernet, PPP, HDCL, Frame-Relay etc.). Then, the frame is converted to bits and placed onto the wire/fiber optic cable.

NOTICE!If the outbound interface is a multi-access interface (such as Ethernet, Frame-Relay, ATM etc.), the router must know the layer 2 identifier of the next-hop device (layer 3 to layer 2 address resolution). For instance, in case the outbound interface is Ethernet, the MAC address of the next-hop device must be in the router's arp cache (if not found, the arp query is sent). In case, the egress interface is of a point-to-point type (subinterface point-to-point or protocol such as PPP, HDLC etc. is used), there is NO layer 3 to layer 2 resolution being performed. The packet is simply encapsulated in layer 2 frame sent out that interface.

Let's consider the example depicted in pic. 1.

Pic. 1 - The Longest Match Rule.

In this example the router receives an IP packet. The DESTINATION Address in the packet is 172.31.1.33. The router is going to compare this address (bit by bit), with the prefixes (address/network-mask) in the routing table presented, trying to find the closest match (the number of bits that are the same). The entry that is the best match will give the router instructions as to what is the address of the next-hop device (here another router) and the outbound interface.

Let's play the router's game and compare all the entries with the DESTINATION IP address of the packet.

There are three candidate entries pointing to three different next-hop routers and three different outbound interfaces (pic. 1). The pic. 2 shows these numbers in the binary notation.

Pic. 2 - Destination IP Address Comparison.

Clearly, when converted into binary, the first entry shows the best match . The number of identical bits between the packet's destination address and router's knowledge about the subnet is 28 identical bits (highlighted in red). The second entry has only 24 identical bits, and the third one, only 16 bits match the destination IP address (class B network address). That is why the egress interface for the packet towards 172.31.1.33 is FastEthernet0/0 (pic. 1).

So far, we have only dealt with the situation in which there is a SINGLE best match. What if there are

more than one entries (paths available) in the routing table with the EXACT same longest match?

There are two other parameters a router uses to break the tie:

1. Administrative Distance 2. Metric

Administrative DistanceThere are the situations that your router(s) may use more than one source of information. Not that you create such situation on purpose. You are better off using one protocol (e.g. OSPF), but reality bites and sometimes you have to support more than one routing protocol in the same routing domain. In such situations your router may receive the same prefix(es) from different sources. As a result of that multiple sources (RIP, OSPF, EIGRP etc.) provider the router with the EXACT same prefix (address/network-mask).

In order to deal with situations like this, Cisco have created a ranking which assign the protocols (sources of information) different levels of "trustworthiness" (if that's a word). This level of "believability" is expressed with the arbitrarily allocated value that is given to different sources of information. This parameter is called: Administrative Distance (or just 'distance'). The LOWER the value of AD is, the more trusted the source of information is going to be.

Consider the pic. 3. The router receives EXACT same prefix (192.168.1.0/24) from two different sources: RIP and OSPF. Since this is going to cause an issue as to which one is better, AD is going to break the tie. OSPF is more trusted than RIP as it has lower value of Administrative Distance assigned to it (110) compared to RIP's (120).

There are many reasons why RIP is less trusted source than OSPF, but explaining it in detail is beyond of the scope of this post. Needless to say, if you do not like Cisco arbitrarily set values, there are ways of changing them. The commands are different for different protocols, and when we get to advanced topics (hopefully), I'm going to show them to you.

Pic. 3 - Advertisement Come from Different Sources (Protocols).

Icons designed by: Andrzej Szoblik

I have included a few AD values for the most often used protocols to get you going. For more information on that go to Cisco web site. Of course the best way of finding the values is to use my favorite search engine: google ;).

MetricAnother situations that might put a router in a difficult position regarding which path is the best occurs when there are multiple longest match entries in the routing table, coming from the same source. Or more accurately speaking, there are multiple best matches (EXACT prefixes) having the same value of Administrative Distance (AD).

In such situations, the tie-breaker is going to be the LOWEST value of the METRIC.

A metric is the value calculated for each prefix and expresses, for the lack of better word, how far the destination is. The lower the value, the more preferred the path is.

Keep in mind, that the type of metric routing protocols use (the way they calculate it) is different between them and totally INCOMPATIBLE. They use different ways and factors to calculate their metric.

Just to give you a few examples, RIP uses the concept of hop-count. The number (metric) tells the router how many routers the packet must traverse before it reaches the destination.

OSPF on the other hand, uses the cost as its metric. It is calculated based on the bandwidth of the interfaces (links) in the path. This way, its metric is far more sophisticated and more suitable for our networks compared to RIP.

As you see it is not the coincidence that OSPF is more trusted source of information compared to RIP.

Consider the following example (pic. 4).

Pic. 4 - An Example of Metric Types.

Icons designed by: Andrzej Szoblik

If in your design you decided to use RIP in the above topology, the router A, would choose the best path towards 10.2.2.0/24 through router B. This is because the metric used by RIP takes into consideration the number of routers the packet has to traverse, and nothing else. The path through router B is better (1 hop), as opposed to the path through routers C, D, B (3 hops). RIP does not factor in the bandwidth of the links in the path.

If you chose to use OSPF instead, the number of hops (routers the packet is going to go through) is irrelevant. OSPF makes forwarding decisions based on the bandwidth available in the paths. This way, OSPF prefers path through routers C, D, B, rather than through router B (much faster links available).

More on the topic of metrics in the upcoming posts. Now, that you have learned about the factors that help routers determine the best path, you are ready to take a look at the algorithm.

1. Prefer the path with the longest match entry in the routing table (irrespective of the metric or AD). 2. In case there are multiple best matches available, check the AD value (if they come from the

same source). Choose the source of information with the lowest AD.  3. If the best match prefixes (more than one) come from the source with the same AD, choose the

lowest metric number.

The same order of operation is presented in the pic. 5.

NOTICE!When considering Border Gateway Protocol, its metric is very complex (not a single number like all Interior Gateway Protocols tend to use). As a result of that, the rules of finding the best route are also more complex and are beyond the scope of this post.

Pic. 5 - Route Selection Process.

Traffic Sharing One last scenario. What if a router receives more than one exact longest match prefixes that have the same values of AD and the metric?

All of them are the best candidates and the router performs load sharing (load balancing) using all of the egress interfaces that are the best. Of course, whether it is per-packet, or per flow load-balancing depends on the switching engine configuration of your router.

I hope you have caught the idea by now. Check yourself by answering the following question. You will find the answers for all scenarios presented at the bottom of this post.

Practical QuestionThe IP packet has the destination address of 10.1.1.17. The third column on the left is the prefix learned. Which entry in the routing table (number in first column) is going to be the best in the following scenarios? Which outbound interface is going to be used?

Pic. 6 - Scenario 1.

 Pic. 7 - Scenario 2.

Pic. 8 - Scenario 3.

Pic. 9 - Scenario 4

Pic. 10 - Scenario 5

The answers to the question (all scenarios)Scenario 1Entry 2 is the correct answer. The egress interface is F0/0.The router looks for the longest match in the routing table first. Entry 2 learned from RIP has the longest number of bits that are identical with the destination IP (it is the most specific). The remaining sources (OSPF and EIGRP) have fewer bits that match the destination address (they are less specific). The fact that they are more trusted does not apply here since the longest match is always preferred.

Scenario 2Entry 1 is the correct answer. The egress interface is S0/1.Just like in the scenario 1, the router looks for a longest match in the routing table first.Entries 4 and 5 have 8 bits and 16 bits in common with the destination address respectively. Entries 2 and 3 have 24 bits in common. The longest match is the entry 1 having 28 networking bits that are identical with the IP address 10.1.1.17. You can check it by converting the last byte into the binary notation.

Scenario 3Entry 2 is the correct answer. The egress interface is F0/0.We can safely rule out the Entries 1 and 4 due to the length of network mask (not the best matches). We're left with Entries 2 and 3. Both have the same number of bits that are identical bits with the destination address (24). Both prefixes come from the same source (OSPF) and as a result of that have the same Administrative Distance value = 120. The tie breaker is going to be the metric value. Entry 2 has a cost of 30 and entry 4 has cost of 40. The lowest is the preferred one.

Scenario 4Entry 2 is the correct answer. The egress interface is S0/0.All five entries have the same length of prefix mask, so after longest match rule check we have five candidates.  However, entries 4 and 5 come from OSPF and have higher AD (120) than the first three entries coming from EIGRP routing protocol (90). The lower AD here is preferred. We can rule 4 and 5 out now. Again, all three of them left, have the same AD (90). The tie-breaker is the value of metric again.

Scenario 5Entries 1 through 3 are the correct answer. The egress interfaces are S0/0, S0/1, and S0/2. The router is going to perform load balancing (traffic sharing).We can rule out entries 4 and 5 like in the scenario 4. The remaining entries 1 through 3 come from EIGRP (AD=90) and their metrics are the same.

Lesson 33 - Static Routing In the previous post I attempted to explain how a router selects the best route if there are multiple paths available. In this lesson, I'm going to show you how you can use static routes effectively in two different topologies (the second one uses backup links). You'll see how basic knowledge on route selection can come in handy if you plan on using primary and backup connections.

All Cisco routers have the routing capability turned ON by default. The command responsible for this is:

router(config)#ip routing

This allows a router to create and use the routing table the moment we enable and configure at least two interfaces.

NOTICE!Some subnets and networks are simulated by means of creating and configuring virtual interfaces (Loopback) in my topology.

Pic. 1 - Routing Topology 1

Directly Connected NetworksIn the topology used (pic. 1), the routers have been assigned IP addresses and the interfaces are up. Since the routing process is enabled (ip routing) the directly connected subnets/networks show in the routing table immediately. Look at R1's routing table:

Pic. 2 - Directly Connected Networks.

The problem is with the destinations that are NOT connected directly to a router (remote). A router does not know anything about these by default. There are two ways of "teaching" a router about remote networks or subnets:

1. Applying static routing (manual method) 2. Applying dynamic routing (a routing protocol that distributes information automatically)

Static RoutingThere are pros and cons of using manual method. In complex scenarios (with redundant connections), more often than not, we use dynamic routing protocols. But there are situations in which static routing is good or perhaps the best solution.

Consider our example. R4 and R5 are connected to so called stub networks. A stub network has only one way in and out (one path). Some routers used in such designs are relatively cheap and may not even have enough hardware resources to run a dynamic routing protocol (such as OSPF or EIGRP). Then, installing static routes is the only option possible. Also, imagine your broadband router (your home network is also the stub-like if you're connected to one ISP). This router does not have the paths to each and every destination on the Internet. It uses a form of static route instead known as: default route. More on the default route later in the post.

Let's look at the syntax which allows us to instruct a router about remote networks and subnets manually.

Pic. 3 - Static Route Command Version 1.

Let's read what this command does. 

"IP route towards class C network 192.168.1.0/24 can be reached by sending packets to a next-hop router out the serial0/2 interface."

The last parameter used shows the router which interface should be used to send the packets out. If you configure the outbound interface instead of the IP address of the next-hop router in the path, this connection must be point-to-point (not multiaccess).

In case, the router's egress (outbound) interface is multiaccess link (Ethernet, Frame-Relay, ATM etc.), we must NEVER use local interface but IP address of the next-hop router instead. If you do not follow this recommendation, the router will try to resolve the layer 3 to layer 2 address for every destination out that interface. This leads to serious inefficiency and shows little understanding of routing operation of a person who used it.

If the router must send the packet to the next router in order to get to the destination (egress interface is multiaccess), the 'ip route' command should look like the example below (pic. 4).

Pic. 4 - Static Route Command Version 2.

Let's configure our routers so they can reach all networks int the topology used (pic. 1).

NOTICE!The routing works in both directions. This means that the router receiving packet to its directly connected network/subnet must know the returning path to the sender of the packet (source).

Configuration on R1

Step 1Reachability towards 172.31.2.0/24. The next-hop router is R2. The outbound interface is multiaccess link (F1/0). The order of statements does not matter. Configuring the remaining routers I will use a more logical approach than on R1.

R1#configure terminalR1(config)#ip route 172.31.2.0 255.255.255.0 172.31.123.2

R1(config)#

Step 2Reachability towards 172.31.3.0/28 and 172.31.16.0/28. The same egress interface (F1/0).

R1(config)#ip route 172.31.3.0 255.255.255.240 172.31.123.3R1(config)#ip route 172.31.3.16 255.255.255.240 172.31.123.3

R1(config)#

Step 3Reachability towards 192.168.4.0/24. The egress interface is point-to-point (S0/2 running HDLC protocol). I can use either the next-hop IP address or the local interface s0/2.

R1(config)#ip route 192.168.4.0 255.255.255.0 s0/2R1(config)#

Step 4In order to reach Branch2 network 192.168.5.0/24, R1 must use R2 as the gateway. Even though R2 does not know how to get there now, I will configure it and then configure R2 to reach all networks and subnets (including 192.168.5.0/24).

R1(config)#ip route 192.168.5.0 255.255.255.0 172.31.123.2R1(config)#

Step 5Reachability to the point-to-point subnet between R2 and R5 (172.31.25.0/24).

R1(config)#ip route 172.31.25.0 255.255.255.0 172.31.123.2R1(config)#

Now, let's see what the routing table reveals:

Pic. 5 - Routing Table of R1.

 

Before I proceed with the configuration of the other routers let's consider a few things.

Look at the R1's routing table and the topology carefully, and try to answer the following questions before you test the reachability using 'ping'. If you have problems answering the questions 1, the remaining ones (2-4) should give you a few hints.

Question 1How many IP addresses presented in the topology (pic. 1) will respond to ping from R1 after you have configured static routes so far (only R1 is configured with static routes; all other routers have IP addresses and interfaces enabled)?

Question 2R1 sends ping (echo request) towards 192.168.4.1. What is going to be the source IP address of this request?

Question 3R1 sends ping (echo request) towards 172.31.25.2. Is R1 going to receive reply (echo reply)? Why?

Question 4R1 sends ping (echo request) towards 172.31.25.5. Is R1 going to receive reply (echo reply)? Why?

If you have answered them, check if you were right. The answers are as follows.

Answer 1There are 11 IP addresses to respond to the ping sent by R1. These are:

172.31.1.1 - reason: directly connected subnet (Loopback 1). 172.31.123.1 through 3 - reason: directly connected subnet (F1/0). 172.31.3.1 and 172.31.3.17 - reason: source IP address is the 172.31.123.1. It's the egress

interface to reach these two addresses (via F1/0). R3 knows how to get back to R1's F1/0 interface (R3's F1/0 is connected to 172.31.123.0/24 too).

172.31.2.1 and 172.31.25.2 - reason: R1 will use F1/0 (egress interface) to reach these IP addresses according to our 'ip route' statements. The source IP address is going to be the address of F1/0. R2 knows its way back to 172.31.123.0/24 subnet (directly connected to F1/0).

172.31.14.1, 172.31.14.4 and 192.168.4.1 - reason: R4 knows how to get back to the source IP address R1 uses for these destination. R1 uses 172.31.14.1 as the source IP address. This source (subnet 172.31.14.0/24) is shared between R1 and R4 on their Serial0/2 interfaces.

The reason I ask this question is to draw your attention to two important facts:

A router is going to find the best match in the routing table for each destination. If not found, of course the packet is dropped. If found though, a router will not change the source and destination addresses in packets TRAVERSING it. If the packet is ORIGINATED by the router (here: ping), the source of IP address used is going to be the address of its egress (outbound) interface by default.

Sending a packet out is one job, but the destination will try to send a response back to the source. The remote router which is going to respond, must know how to reach the source of the transmission as well (valid path back to the source in its routing table).

Answer 2Ping from R1 towards 192.168.4.1 is going to use 172.31.14.1 as its source address since according to the routing table Serial0/2 is the outbound interface.

Destination 192.168.4.1 shows the following detailed output on R1:

Pic. 6 - R1's Route Towards 192.168.4.1.

The route shows that the longest match for 192.168.4.1 is: 192.168.4.0/24. This routing table entry points to Serial0/2 as an egress interface.

Answer 3R1 sends the ping (echo request) packet towards 172.31.25.2. Like explained in the answer 2, the source IP address for this echo request is going to be the address of the outbound interface (FastEthernet1/0). R2 knows how to reply back to 172.31.123.1 since R2 is directly connected to the subnet 172.31.123.0/24 with its FastEthernet1/0 interface.

Answer 4R1 sends the ping (echo request) packet towards 172.31.25.5. It is NOT going to get the reply from R5. The reason is that R5 does not know how to reply back to the source (172.31.123.1). It has not been configured to reach remote subnets and networks yet.

I hope you have found this little quiz entertaining and informative enough.

Would you know how to configure R2 and R3 using R1's configuration as an example? Give it a try. If you can't do it yet, just follow the configuration presented below.

Configuration on R2

Step 1Reachability to networks/subnets via R1.

R2#configure terminalR2(config)#ip route 172.31.1.0 255.255.255.0 172.31.123.1

R2(config)#ip route 172.31.14.0 255.255.255.0 172.31.123.1

R2(config)#ip route 192.168.4.0 255.255.255.0 172.31.123.1

R2(config)#

Step 2Reachability to networks/subnets via R3.

R2(config)#ip route 172.31.3.0 255.255.255.240 172.31.123.3

R2(config)#ip route 172.31.3.16 255.255.255.240 172.31.123.3

R2(config)#

Step 3Reachability to network via R5.

R2(config)#ip route 192.168.5.0 255.255.255.0 s0/2R2(config)#

Configuration on R3

Step 1Reachability to networks/subnets via R1.

R3#configure terminalR3(config)#ip route 172.31.1.0 255.255.255.0 172.31.123.1

R3(config)#ip route 172.31.14.0 255.255.255.0 172.31.123.1

R3(config)#ip route 192.168.4.0 255.255.255.0 172.31.123.1

Step 2Reachability to networks/subnets via R2.

R3(config)#ip route 172.31.2.0 255.255.255.0 172.31.123.2R3(config)#ip route 172.31.25.0 255.255.255.0 172.31.123.2

R3(config)#ip route 192.168.5.0 255.255.255.0 172.31.123.2

R3(config)#

As for the routers R4 and R5 they connect stub networks. In order to simplify the configuration on these and reduce the number of entries on them, I am going to use a special type of static route called: the default route.

Pic. 7 - Default Route Example.

The destination IP address 0.0.0.0 (unknown) represents all destination which cannot be found in the routing table. This address uses the network mask of all zeros (0.0.0.0). As long as the router does not have the best match in the routing table for a given destination ('subnet not in table') the default route is going to be used instead. It is the 'gateway of last resort'. Like previously explained, on point-to-point links you can use the outbound interface instead of the address of the next-hop router.

Applying default routes is going to be easy.

Configuration on R4Step 1Packets for all unknown destinations send via R1.

R4(config)#ip route 0.0.0.0 0.0.0.0 s0/2R4(config)#

Configuration on R5

Step 1Packets for all unknown destinations send via R2.

R5(config)#ip route 0.0.0.0 0.0.0.0 s0/2R5(config)#

Simple test will prove the default route operation:

Pic. 8 - Default Route Test.

Even though the routing table does not have the route towards 192.168.5.1, the packets are delivered using the default route (via R1 which knows how to get there).

Look what the routing table shows when default route has been added (pic. 9).

Pic. 9 - Routing Table with Default Route.

Static Routing with Primary and Backup LinksIn order to spice things up, I am going to configure two additional connections from HQ to our branches using Frame-Relay. These redundant paths must be used as the backup links. They should be used in the case of losing main path via Serial0/2 interfaces (down).

Pic. 10 - Routing Topology with Redundant Paths.

Please, disregard my configuration of Frame-Relay links for now. I'm going to address WAN protocols in the upcoming posts. I only need the extra connectivity to show you how to handle the primary and backup scenario using static routing.

Frame-Relay Configuration is going to look like this in order to reflect the topology in the pic. 10.

Circuit Between R1 and R5

R1 Configuration:

R1(config)#interface serial0/0R1(config-if)#encapsulation frame-relayR1(config-if)#no frame-relay inverse-arpR1(config-if)#ip address 172.31.15.1 255.255.255.0R1(config-if)#frame-relay map ip 172.31.15.5 105 broadcastR1(config-if)#no shutdownR1(config-if)#

R5 Configuration:

R5(config)#interface serial0/0R5(config-if)#encapsulation frame-relayR5(config-if)#no frame-relay inverse-arpR5(config-if)#ip address 172.31.15.5 255.255.255.0R5(config-if)#frame-relay map ip 172.31.15.1 501 broadcastR5(config-if)#no shutdownR5(config-if)#

Circuit Between R2 and R4

R2 Configuration:

R2(config)#interface serial0/0R2(config-if)#encapsulation frame-relayR2(config-if)#no frame-relay inverse-arpR2(config-if)#ip address 172.31.24.2 255.255.255.0R2(config-if)#frame-relay map ip 172.31.24.4 204 broadcastR2(config-if)#no shutdownR2(config-if)#

R4 Configuration:

R4(config)#interface serial0/0R4(config-if)#encapsulation frame-relay R4(config-if)#no frame-relay inverse-arpR4(config-if)#ip address 172.31.24.4 255.255.255.0

R4(config-if)#frame-relay map ip 172.31.24.2 402 broadcastR4(config-if)#no shutdownR4(config-if)#

Now let's get back to the business. If I add two static route entries using the newly created paths, the metric of each of them is going to be identical with the metric used by the primary link (Serial0/2). This way, load balancing (traffic sharing) is going to be used since two equal cost paths exist. Our design stipulates that Frame-Relay circuits should be used as the backup links only (Serial0/2 down).

In order to accomplish this, I should change either the metric or administrative distance of the backup path. Unfortunately, we cannot change the metric (no command available) on static routes, but we can easily increase the value of administrative distance to make the backup path less preferred. The default AD for static routes is 1, so I will make the backup route less trusted by using the value of, say, 3.

Backup Link Between R1 and R5

R1 Configuration:

R1(config)#ip route 192.168.5.0 255.255.255.0 172.31.15.5 3R1(config)#

R5 Configuration:

R5(config)#ip route 0.0.0.0 0.0.0.0 172.31.15.1 3R5(config)#

  

Backup Link Between R2 and  R4

R2 Configuration:

R2(config)#ip route 192.168.4.0 255.255.255.0 172.31.24.4 3R2(config)#

R4 Configuration:

R4(config)#ip route 0.0.0.0 0.0.0.0 172.31.24.2 3R4(config)#

This way, the primary link (via Serial0/2) is preferred due to the lower administrative distance (AD=1). Look at R4 now:

Pic. 11 - R4's Routing Table with Primary Link UP.

In case the primary link goes down, the extra ip route (using Frame-Relay link) kicks in like shown in the pic. 12.

Pic. 12. - R4's Routing Table with Primary Link DOWN.

In the few upcoming posts, I will focus in on dynamic routing protocols.

Lesson 34 - Dynamic Routing Protocols Introduction If you have read the previous post, you must have noticed that using a static routing method tends to be a bit cumbersome in larger implementations. Using one of the dynamic routing protocols feels like an easier solution in these scenarios.

In this post I will briefly explain the general concepts behind dynamic routing protocols. Then, we can jump to implementation fundamentals.

One way of classifying dynamic routing protocols is based on where they are used. This criterion allows us to distinguish between two major solutions:

1. Interior Gateway Protocols  (IGP)  2. Exterior Gateway Protocols (EGP)

Common Interior Gateway Protocols are: 

Routing Information Protocol (RIP),  Open Shortest Path First (OSPF),  Enhanced Interior Gateway Protocol (EIGRP, Cisco proprietary protocol),  Intermediate System to Intermediate System (IS-IS).

Exterior Gateway Protocols (currently there is only one in use)

Border Gateway Protocol  (BGP)

IGPs are designed to work in private networks. EGPs are used to provide paths in the public network (Internet). 

We can also classify routing protocols based on the algorithm they use to distribute and maintain information (routing table). There are three major algorithms supported by Cisco routers:

1. Distance Vector (DV, aka Bellman-Ford) – example of protocol: RIP. 2. Link-State – example of protocols: OSPF, IS-IS. 3. Advanced Distance Vector – protocols: EIGRP (also BGP is partly distance vector protocol).

Understanding the algorithms helps us determine the proper solution for a given design. There is no one best routing protocol out there, but there could be the best one in a specific design.

In this post I am going to focus in on the first algorithm listed above.

Distance Vector Algorithm Characteristics

This method is sometimes referred to as ‘routing by rumor’. The main characteristics of this approach are:

Routers do not know the topology of the network. They only know which is the outbound interface and the next-hop router’s IP address (vector) as well as the metric value which describes how far the destination is (distance).

Routers advertise their full routing table periodically. This method of route distribution creates two problems: routing loops and counting to infinity. Special techniques were created to solve these issues (details later in the post).

Routers perform automatic summarization if they are connected to different classful (A, B, C) networks.

No VLSM support. All network masks must be identical if the subnets of a major class are used in the network (RIPv1). RIPv2 is classless (VLSM supported using ‘no auto-summary’ command).

Routers are slow to converge. It takes a lot of time to invalidate lost routes and pick the new path if one is available as well as to synchronize their routing information.

Routers use simple metric. The metric number tells a router how many routers the packet has to traverse in order to reach the destination. In modern networks bandwidth of the path is much more important than how many hops will be used.

The above characteristics do not encourage us to use this kind of solution in our modern networks. But knowing the DV rules help us appreciate protocols such as OSPF or EIGRP which are more likely to be used in our designs.

Let’s see how things work when DV algorithm is used. As an example, I will use RIP protocol hoping to explain the principles of operation and how the two design issues have been solved (routing loop and counting to infinity).

Distance Vector Principles of Operation

Consider this simple topology. Without getting into configuration (syntax) details let’s have a quick discussion on how information is distributed using DV algorithm. Initially, the routers recognize only connected subnets. They are populated in the routing table as soon as IP addresses and network masks are configured and they are activated (no shutdown).

Pic. 1 - Connected Subnets.

Icons designed by: Andrzej Szoblik

Let’s assume that we have enabled RIPv2 protocol in the topology presented above (pic. 1). This version of RIP allows the routers to announce both the subnet IP addresses and the network masks (we’ll put it into practice in the next post). 

The RIP process must be activated in the ‘config’ mode. Then we need to instruct it which interfaces should be activated in the RIP domain. This is configured in the ‘config-router’ mode (‘network’ statement).  The routers begin to ‘chat’ and advertise their routing tables every 30 seconds.

Pretend that R1’s timer of sending the advertisement has just kicked in (pic. 2). R1 is advertising its routing table out of the RIP-enabled interfaces (in my example all interfaces of all routers are in the RIP domain). This way, R2 learns about 10.1.1.0/24 subnet. So from R2’s perspective, R1 router becomes the gateway towards 10.1.1.0/24. 

Now, a word about the metric being advertised. 

Metric used in DV reflects how many routers the packet has to traverse to reach the destination network/subnet (so called 'hop-count'). R1’s routing table’s entries (subnets: 10.1.1.0/24 and 10.1.12.0/24) show the metric of ‘0’ hops (pic. 1) since they are directly connected to F0/0 and F0/1 interfaces respectively (they are local to R1). While advertising them to the neighbors (pic. 2), R1 adds 1 hop (itself) to the existing metric found in the routing table.

NOTICE!Bear in mind, that algorithm prompts the router to send the full routing table. Current implementation changes that behavior (split-horizon) but more on this later in the post.

Pic. 2 – R1’s RIP advertisements.

Icons designed by: Andrzej Szoblik

R2 accepts the advertisement about 10.1.1.0/24. It puts this information in the RIP’s database and then it creates the entry in the routing table (purple color). Pay a close attention to what has just happened (pic. 2). The update arrives on R2’s F0/0 interface (RIP-enabled), sourced by the IP address of 10.1.12.1. This way, R2 considers its F0/0 the egress (outbound) interface towards the subnet advertised by R1. The IP address of the sender (10.1.12.1) becomes the next-hop IP address towards the subnet 10.1.1.0/24

Next, let’s imagine R2’s timer has expired and it is sending its routing table out F0/0 and F0/1. Please take a closer look at the picture 3 which shows this process in the graphical form. Just like previously R1

router has done, R2 is sending its routing table adding itself as an additional hop added to the existing metric (existing metric +1).

Pic. 3 – R2’s RIP advertisement.

Icons designed by: Andrzej Szoblik

Now, R1 and R3 accept the advertisement from R2 and register the information sent in their RIP databases (the interfaces process the update as they RIP-enabled). Appropriate entries in the routing tables also show the egress interfaces and the metric expressed in the number of ‘hops’ (how many routers the packet will have to traverse to reach the destination subnet). Also, the IP address of the gateway (the sender IP address) is registered. Again, take a look at pic.3 which shows the new entries (in purple).

Now is the time for R3 to send its own advertisement. Using the same logic you should be able to tell what is going to happen. Take a look at pic. 4 to see what is going to be advertised and what is going to be learned.

The advertisement sent out R3’s F0/0 interface is useless in our topology because there is no other router listening to it. In my next post, I will show you how to prevent a router from doing it. Advertisement sent out F0/1 interface contains information about R3’s directly connected subnet 10.1.3.0/24. Since the existing metric in R3’s routing table for this subnet is ‘0’ (directly connected to F0/0), R3 will add itself as the hop and advertise it with the metric of ‘1’ (existing metric + 1). R2 is going to learn it on its F0/1 interface which becomes the outbound interface to reach the subnet 10.1.3.0/24. It is the interface to reach the advertising router’s IP address 10.1.23.3 after all.

Pic. 4 – R3’s RIP Advertisement.

Icons designed by: Andrzej Szoblik

Picture 4 shows this process.

This whole process of advertising the routing table out of all RIP-enabled interfaces occurs every 30 seconds but in fact, there is a jitter time introduced so this may vary between 25-30 seconds. When R2 advertising timer expires, it will pass the information contained in the its routing table on to R1. By doing this, R1 learns about all subnets R2 can reach, including 10.1.3.0/24 now (pic. 5).

Pic. 5 – R2’s RIP Advertisement.

Icons designed by: Andrzej Szoblik

The process of spreading the information explained using this method is referred to as the ‘routing by rumor’. The state in which all routers have stable information about all networks/subnets that can be reached is called the ‘convergence’. Do not confuse it with ‘convergent networks’ which allow all sort of packet transmissions (voice, video, and data).

Take a look at picture 6. It shows that all routers can reach all the subnets available in the RIP domain. Convergence has been accomplished since their routing table are synchronized and up-to-date.

Pic. 6 – Convergence Achieved.

Icons designed by: Andrzej Szoblik

The method of distributing information presented is prone to introduce two problems:

Routing Loops Counting to Infinity

Of course, they have been resolved by using different techniques which I am going to explain later in the post.

Let’s take a look at the downside of using distance vector algorithm.

Routing LoopsIn the picture 7, R1’s F0/0 interface. As soon as the IOS detects this fact, the entry in the routing table about 10.1.1.0/24 is immediately flushed (removed from the routing table completely).

Pic. 7 – R1’s F0/0 Interface Goes Down.

Icons designed by: Andrzej Szoblik

As per the DV algorithm R1 would still wait till its advertisement timer expires. So instead of sending this ‘update’ immediately after it has lost the subnet, it will wait till its timer says: ‘now you can advertise your routing table’. This behavior might create a loop between R1 and R2 as far as the 10.1.1.0/24 subnet is concerned. Consider this situation depicted below.

Pic 8 – R2’s Advertising Timer Expires.

Icons designed by: Andrzej Szoblik

R2 is advertising its full routing table out of all RIP-enabled interfaces. In this announcement, there is 10.1.1.0/24 subnet. The metric being advertised is: ‘2’ (the existing metric on R2 + 1). By now, you already know that the advertising router is going to add itself as the hop to the metric of the subnet/network it advertises.

Here is the issue. R1 is receiving 10.1.1/0/24 with the metric of 2 hops, the egress interface (the one the ad came on) is F0/1, and the next-hop-address is 10.1.12.2. Look at the pic. 8 and tell me (I can’t hear you though), what would you do if you were R1? Obviously, you would reject this information because by looking at the topology diagram, you already know that 10.1.1.0/24 is inaccessible (down) now, and the only way to reach it is through R1, right?

But the problem is, that routers using DV algorithm do NOT know the topology like explained in the characteristics section. In fact, R1 IS going to accept the information and treat R2 as the gateway towards 10.1.1.0/24 !!!

Wow! As ridiculous as it sounds, it is exactly what would happen according to the rules set by the designers of this algorithm. So R1’s routing table is going to look like shown in the picture 8. Take a look at it now again!

We have a loop between R1 and R2 regarding 10.1.1.0/24. If R2 receives the packets destined to 10.1.1.0/24 subnet, according to its knowledge (current routing table), it is going to send it out F0/0 interface towards R1. This one in turn, will use its F0/1 interface for the destination 10.1.1.0/24, sending it

back to R2. The packets will be looped until their TTL values are decremented reaching the value of TTL=0. Then, a router must drop the packet.

Counting To InfinityA routing loop is not going to be the only problem here. R1 is going to accept advertisements from R2 regarding 10.1.1.0/24 with the number of hops equal '2’. When R1 advertises its own routing table, it is going to add itself (as the hop) to the metric that already exists in the routing table. Look what is going to happen (pic. 9)

Pic. 9 – R1’s RIP Advertisement.

Icons designed by: Andrzej Szoblik

Initially, R2 is going to ignore the information about 10.1.1.0/24 from R1 containing the metric of ‘3’ hops since it has much better entry in the routing table (lower metric). However, it was R1 that initially sent the metric of ‘1’ hop. Now, the same R1 router keeps sending the metric of ‘3’ hops. The previous metric of ‘1’ is no longer refreshed. Since it uses the aging timer of 180 seconds (how long the information is valid), it finally accepts the entry with the metric of ‘3’ hops instead.

Then R2 begins to advertise the metric of 4 regarding 10.1.1.0/24 subnet out F0/0 and F0/1. You can predict what is going to happen. Remember, that entries must be refreshed every 30 seconds. If they are not refreshed, the ‘Invalidation Timer’ (180 seconds), allows to accept the entry with worse metric than previously. Take a look at the sequence of events in the picture 10.

Pic. 10 – Larger and Larger Metric Propagation.

Icons designed by: Andrzej Szoblik

It would last forever despite of the fact that 10.1.1.0/24 is not reachable at all!

The Distance Vector algorithm uses a few techniques to prevent these two problems from happening. Here they are:

Triggered Update (aka flash update) Route Poisoning Maximum Metric (RIP considers 16 hops as inaccessible) Poison Reverse Hold-Down Timer Split-Horizon

These methods deserve a few words of explanation.

Triggered Update

IOS uses this method to send the update immediately rather than wait for the advertisement timer to expire. However, there is no guarantee that some router in the chain is not going to send its own information before it receives this update. This might still lead to a situation where the two problems occur. So this method, as the only solution here, is not enough to make it work. Other methods must be used as well in order to avoid routing loops and counting to infinity.

Route Poisoning

Upon losing subnet/network reachability, a router is sending a triggered update. This update is going to include the maximum metric value (RIP=16 hops) which is considered as ‘subnet/network inaccessible’ (cannot be reached).

Maximum Metric (RIP=16)

If a RIP router receives an update about a network/subnet with the metric of 16 hops it is considered as inaccessible. This way, the advertising router is excluded from the list of gateways for the subnet/network advertised with the maximum metric.

Poison Reverse

Once a router receives the advertisement including the maximum metric, if it does not have an alternate path towards the subnet/network lost, it is going to send the same subnet/network prefix with the maximum metric (RIP=16) informing the other routers about it. This will also be sent back to the sender of this information it does not have an alternate path (this might be seen as violation of split-horizon, but remember the metric is the maximum value). Poisoning the path back to the advertising router is the way of informing it that the receiver of this information has no alternate path available either.

Hold-Down Timer

Upon receiving information from a neighbor that a subnet/network is inaccessible, the receiving router is going to enable a hold-down timer for 180 seconds. During this time, the receiving router keeps sending packet to the destination being inaccessible for some time rather than withdrawing the entry from its routing table. Why?

In the past, the routers did not have that much power and the media were unreliable. Interfaces were prone to flaps more often than in today’s reliable networks. An ‘interface flap’ is the condition when it goes down and up subsequently in a very short space of time (1-2 seconds perhaps). Under such circumstances, a router would advertise network as inaccessible and then as accessible again. Since it takes some CPU power to withdraw the entry and put it back in, the designers preferred to wait a bit longer to be absolutely sure (180 seconds by default) that the entry was supposed to be removed from the routing table. In case of an interface flapping, not only would the packets still be delivered but the CPU would not waste its ‘precious’ cycles on removing and putting the entry back in the routing table. 

Split-Horizon

This method prevents the loops from occurring in the scenario we have talked about. This technique prevents a router from sending information it learned back out the interface it was received on. Consider our first example. R2 sent information about 10.1.1.0/24 before R1 had had a chance to send the

maximum metric towards R2 (subnet down). Split-Horizon prevents R2 from sending information about 10.1.1.0/24 it learned on its F0/0 interface back out the same interface. As a result of that, R1 is never going to receive information it sent towards R2 (10.1.1.0/24) and believe R2 could be the gateway to 10.1.1.0/24. Thus, there is no loop

In my next post I’m going to show you how to enable RIP and how all these techniques work in practice.

Lesson 35 - Routing Information Protocol Part1 Now, that you have learned the principles regarding Distance Vector algorithm, it's time to look at the operation of the oldest distance vector routing protocol: RIP.

Routing Information Protocol is seldom used these days. It has been superseded by more sophisticated protocols (OSPF, EIGRP, IS-IS). However, Cisco still keeps it in the curriculum. All professionals up to the CCIE level (as of writing this post) need to know how it works. In order to enable RIP you must choose which version you want to run. By default, if you configure RIP the version used is version 1. You can change it to version 2 which is more preferred if one want to RIP to begin with. The below table summarizes the main feature of both versions.

Table 1- RIPv1 and RIPv2 Features.

Classful, Classless, and SummarizationRouters share their information (routing table) with their neighbors using advertisements. It is important to know that the shorter the routing table is, the less time a router needs to process the incoming packets in order to find the outbound (egress) interface and expedite them.

If your network design uses proper, consecutive IP scheme, a router can advertise fewer prefixes (routing entries) to their neighbors represented by so called summary routes. A summary route represents multiple more specific destinations. But the router which receives this summary route can still send packets towards the subnets that are being summarized. Consider the following picture (pic. 1).

Pic. 1 – Route Summarization.

Icons designed by: Andrzej Szoblik

In the pic. 1, there are four subnets located behind R1. Router R1 can advertise them ‘as they are’ towards R2. This way, R2 will populate its routing table with all four of them (10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24) with R1 as the gateway to these subnets. However, the subnet addresses behind R1 are designed to be represented by one summary route. This route is going to represent exactly these four subnets. So R1, instead of advertising the four of them, will announce only one address:

10.1.0.0/22

So the question is: how to summarize subnets/networks?

Assuming that IP addresses subnets/networks to be summarized are consecutive numbers when converted to binary, the rule to create the summary route presented in the pic.1 can be applied using three steps.

Step 1Convert all consecutive summary candidates into binary. List them from the lowest number to the highest like presented in pic.1.

10.1.0.0/24 = 00001010.00000001.00000000.0000000010.1.1.0/24 = 00001010.00000001.00000001.0000000010.1.2.0/24 = 00001010.00000001.00000010.0000000010.1.3.0/24 = 00001010.00000001.00000011.00000000

Step 2Find the number of bits that is identical and draw the line to see how many bits do not change.

10.1.0.0/24 = 00001010.00000001.00000000.0000000010.1.1.0/24 = 00001010.00000001.00000001.0000000010.1.2.0/24 = 00001010.00000001.00000010.00000000

10.1.3.0/24 = 00001010.00000001.00000011.00000000

22 bits do not change = the length of the network mask representing all four entries.

Step 3Advertise the address with the lowest number in the range using network mask length achieved in the step 2 (bits that never change give you the length of the network mask). The actual commands will be different depending which protocols you use. I will explain them in due time.

10.1.0.0/22 = 00001010.00000001.00000000.00000000Netmask     = 11111111.11111111.11111100.00000000 = 255.255.252.0

Optionally, you can check if the summary route covers exactly the prefixes. Notice that the two of the bits that change in the third octet will tell you how many addresses have been represented by the summary route (aka aggregate). Look at the bits that do change (in red).

10.1.0.0/24 = 00001010.00000001.00000000.0000000010.1.1.0/24 = 00001010.00000001.00000001.0000000010.1.2.0/24 = 00001010.00000001.00000010.0000000010.1.3.0/24 = 00001010.00000001.00000011.00000000

There are two bits that change in this range in the third byte. This number of bits with the exponent of 2, tells you how many subnets/networks are being summarized. Here: 2 to the power of 2 = 4. Exactly, four subnets have been summarized using prefix 10.1.0.0/22. So this prefix represents exactly the subnets in question.

Now, that you know how to summarize consecutive subnets/networks, let’s see what automatic summarization to the class boundary will look like if you use RIPv1 and have different classes of IP addresses in your desing. Consider the picture presented below (pic. 2).

Pic. 2 – RIPv1 Automatic Summarization to the Class Boundary.

Icons designed by: Andrzej Szoblik

The routers R1 and R3 are boundary routers between two different classes. They will advertise class A address (10.0.0.0) since RIPv1 does it by default if the outbound interface (the one to send the advertisement) belongs to different class than the subnet being advertised. This will inevitably create confusion as far as R2 is concerned. It will think that both R1 and R3 are gateways to the same class A network 10.0.0.0. As a result of that, the packets destined to the subnets 10.1.1.0 and 10.1.2.0 will not be delivered properly.

In RIPv2 you can disable this automatic summarization by using ‘no auto-summary’ keyword in the ‘config-router’ configuration context. This option makes RIPv2 classless routing protocol (it can advertise subnets of major classes). Classless routing protocols can advertise full prefix (IP address and the network mask) without summarizing it to the class like shown in the pic. 2.

RIPv1 ConfigurationIn order to configure RIP in our design, we need to perform two steps.

Step 1Enable RIPv1 protocol process in the global configuration context.

Step 2Using ‘network’ statement in ‘config-router’ context, instruct the router which interfaces should participate in the RIP process. RIP will run on these interfaces. In RIP protocol the ‘network’ statement has to be followed by the Class A, B, or C address which instructs the router which interfaces should be RIP-enabled.

NOTICE!The ‘network’ statement is one of the most misinterpreted keywords in Cisco IOS. RIP, OSPF, EIGRP use the ‘network’ statement to inform the router which interfaces should be enabled for the routing protocol. The ‘network’ statement does NOT advertise anything. Only when BGP protocol is used, the ‘network’ statement actually advertises the prefixes since BGP is an application using TCP (port 179) and is not run on the interfaces like all IGP protocols are.

Having said that, let’s enable RIPv1 in my design (pic. 3).

Pic. 3 – Topology Diagram.

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

R1 Configuration:R1#configurer terminal R1(config)#router ripR1(config-router)#network 172.31.0.0R1(config-router)#

R2 Configuration:R2#configurer terminal R2(config)#router ripR2(config-router)#network 172.31.0.0R2(config-router)#

R3 Configuration:R3#configurer terminal R3(config)#router ripR3(config-router)#network 172.31.0.0R3(config-router)#

R4 Configuration:R4#configurer terminal R4(config)#router ripR4(config-router)#network 172.31.0.0R4(config-router)#network 192.168.4.0 R4(config-router)#

R5 Configuration:R5#configurer terminal

R5(config)#router ripR5(config-router)#network 172.31.0.0R5(config-router)#network 192.168.5.0 R5(config-router)#

I suggest that you analyze the topology, configuration and information in this post. There will be few issues we will come across here using RIPv1 (one of them I have not discussed yet but it will rear its ugly head on R3).

I will explain these problems in my next post. I will also show you how to check the configuration of RIP ('show' and 'debug' commands). Also, I will enable RIPv2 to show you the differences in their operation, and how to optimize and verify its operation.

Lesson 36 - Routing Information Protocol Part2 In this post I'm going to reinforce all the theory discussed in the two previous posts. But I would like to make it more practical this time. This should help you understand RIPv1 better and hone your skills regarding its implementation. RIPv1 is a good prelude to learning RIPv2 as well since the verification commands are identical for both versions of the protocol. I will finish this lesson off by showing you one quick optimization technique used often with both versions of RIP.

Our topology diagram remains the same.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik

In my previous post I enabled RIP protocol on all the routers and interfaces in the topology presented. Now is the time to verify its operation.

The first RIP verification command I'd like to introduce is the powerful: 'show ip protocols'. It provides information about which dynamic routing protocols are enabled on a router, if any, also displaying specific information about them (here's RIPv1 information).

Pic. 2 - The 'show ip protocols' output on R1.

Get familiar with the output and pay a special attention to the highlighted pieces of information. The output shows us the following (pic.2):

Outgoing/incoming filter list - currently, there are no filters applied to updates being sent or received (more on ACLs which are used to do filtering in the upcoming posts).

Sending updates - RIP is advertising its routing table every 30 seconds and the next update is going to be sent in 16 seconds.

Invalid after - The routing entry is invalidated (can no longer be used) if it is not refreshed by neighbor(s) in 180 seconds.

hold down - If the router receives a 'route-poison' message from the neighbor(s), it still does not trust it entirely for another 180 seconds (it is possibly down). After that period of time it invalidates the prefix. Meanwhile, the router keeps sending packets to the destination marked as possibly down like everything is 'a-ok'.

flushed after  - The routing entry is removed from the routing table after 240 seconds if not refreshed by the neighbor(s).

Default version control - the router is advertising version 1 updates, but able to accept updates from both RIPv1 and RIPv2 enabled routers.

Automatic Summarization - Automatic summarization is enabled (more on this in 'RIP rules' section later in the post).

Maximum paths - currently the router can use up to 4 equal cost path (metric identical) to a given destination (configurable: up to 16 in most IOS versions as of writing this post).

Routing for networks - the router has interfaces in 172.31.0.0 class B networks. Routing Information Sources - neighboring router's addresses which the router heard from. The

time shows when was the last time R1 received the advertisement from its neighbors (e.g. neighbor 172.31.15.5 sent its update to R1 8 seconds ago). This timer should never show you more than 30 seconds under normal circumstances. If the last update from a neighbor arrived longer than 30 seconds ago, it means that the either the neighbor stopped sending its updates or they do not get through.

As you recall, the 'network' statement we used to enable RIP on the interfaces takes a classful IP address as its argument (like explained in the previous post). There is no other additional keyword available for RIP (others protocols use wildcard mask to accomplish this). In case your router has multiple interfaces configured as subnets of the same major network, they all are going to participate in the RIP domain.

For instance, if on R1 I wanted to enable RIP protocol on S0/2 interface only, with my addressing scheme it is not possible. All interfaces are subnets of the same class B major network (172.31.0.0) and will be automatically encompassed in RIP process. If you try to outsmart it and use the following classless statement, it will be accepted by IOS syntax rules but the resulting configuration is going to look like shown in pic. 3 anyway.

Configuration attempting to enable RIP on S0/2 only:

R1(config)#router ripR1(config)#network 172.31.14.0

Resulting is the following running configuration:

Pic. 3 - RIP's classless statement result.

Of course, it is possible to filter out what is going to be advertised or which updates are going to be accepted by the RIP process. This however is beyond the scope of this lesson as you do not know necessary tools to accomplish that yet.

Another command that you may find useful if you want to see what is currently in the RIP database is the following:

Pic. 4 - RIP Database.

 The best entries in the RIP database (normal route selection process applies) are going to populate the routing table. You already know the command 'show ip route' which displays the full routing table including connected and static routes as well. But you can also try to display RIP routing entries only rather than the whole routing table. Here's your command:

Pic. 5 - RIP Routing Table.

The routing table contains two class C network addresses advertised by R4 and R5 respectively:

192.168.4.0 192.168.5.0

Also, it tells us that the R1 has seven subnets of 172.31.0.0 class B network. Hang on a second! We can only see three of them listed in pic. 5:

172.31.25.0 172.31.24.0 172.31.2.0

Where are the remaining four subnets? Take a closer look at pic. 4 which shows the whole RIP database. Can you see the missing four subnets now? In case you can't spot them in pic. 4 look at the following one (pic. 6) which shows all seven of them. For clarity, I have removed class C networks and highlighted the subnets in question.

Pic. 6 - R1's RIP Subnets.

There are seven subnets of 172.31.0.0 class B network indeed! The RIP database shows them all, but the ones that are directly connected subnets, are not making their way to the routing table. Do you still remember why?

The reason is, of course, related to the route selection process already explained in the previous posts. The router knows them as directly connected subnets with the administrative distance of 1, and the same entries are now in the RIP database (as the 'network' statement encompasses them). Recall that RIP's administrative distance value is: 120. The directly connected networks are always the most preferred ones. That is why, we see them as connected rather than RIP generated entries.

Notice the two entries in the routing table: 172.31.24.0 and 172.31.25.0. They both have two equal cost paths (the same metric) which is correct according to our topology. In that case traffic-sharing (load balancing) is going to occur when packets are sent to these destinations. 

However, R1 has not learned 172.31.3.0/28 and 172.31.3.16/28 subnets that should be advertised by R3.

What is the explanation to this?

Let's do some diagnostics on R3 in order to find out what is going on. I'm going to start by checking that RIPv1 has been enabled properly on R3. I want to make sure that the loopback1, loopback2, and F1/0 interfaces participate in the RIP domain (the 'network' statement encompasses them). Here is the result of the test.

Pic. 7 - R3's RIP Information.

It seems that configuration is correct! So, let's take a closer look at what R3 is advertising to their neighbors. In order to see that, we must use 'debug ip rip' command.

WARNING!Extreme care must be taken when using any debug commands on the production equipment. After the diagnostics have been completed, the debug command(s) must be turned off immediately. All 'debug' commands are VERY dangerous if used on the production routers. They have enormous impact on the CPU and can potentially crash the device. They are typically used as the commands of the last resort during troubleshooting of a given technology when problem cannot be resolved without data they provide. So we tend to use them only in situations when we cannot do any more damage than there has already been done :-).

However, in the lab it is recommended to learn what information can be obtained using 'debug' commands. They help us gain a deeper understanding of a given technology and may be very helpful in troubleshooting.

Since I use the lab equipment (dynamips/dynagen emulator to be accurate), I can safely enable the following debug command to trace the RIP process without any damage to my gear. In practice, it is best if you redirect the output of the debug commands to RAM memory and then copy its content to a text editor for analysis. Here's how you can do this:

Step 1Make sure that CPU is not heavily utilized first. Enabling 'debug' commands can create high CPU utilization on the production equipment.

R3#show processes cpu

The first line shows the cpu utilization for the last five seconds, one minute and five minutes. If CPU is not very busy you can proceed to step 2.

Step 2Disable the time stamp service (optionally) to obtain a better output, disable logging to the console and redirect the output to the RAM memory instead.

R3#configure terminalR3(config)#no service timestampsR3(config)#no logging consoleR3(config)#logging bufferedR3(config)#end

Step 3Enable appropriate 'debug' command (here: rip process is being debugged)

R3#debug ip rip

Step 4Wait a period of time till output is sent to the RAM memory. Nothing will show on a screen as per step 2. Then disable debugging (here, the alias is used which disables debugging of all processes which is the fastest method). You can disable the specific one as well. In case of my debug this could be: 'undebug ip rip', or 'no debug ip rip'.

R3#u all

Step 5 Display the content of the debug from the memory buffer and copy it to a text editor for analysis.

R3#show logging

Step 6Bring back the previous settings (logging to the console and time stamps).

R3#configure terminalR3(config)#no logging bufferedR3(config)#logging consoleR3(config)#service timestampsR3(config)#end

For clarity's sake, I have broken the output of 'debug ip rip' into pieces so it is easier for us to analyze the information it provides. In practice, either you learn how to properly interpret the output the way it is presented to you by the system or you can rearrange the output in a text editor.

The first debug output (pic. 8) illustrates what R3 is advertising out its Loopback1 interface. It's worth mentioning, that RIPv1 uses broadcast address (255.255.255.255) to announce networks/subnets as explained in lesson 35. RIPv2 will use the multicast address 224.0.0.9.

Pic. 8 - R3's Update out Loopback 1.

Next output (pic. 9) shows what R3 is announcing out its Loopback2 interface. Both loopback interfaces are enabled in RIP so, naturally, the updates are sent out these interfaces. Take a look at the output and analyse both (pic. 8 and pic. 9) comparing them with the topology diagram (pic. 1).

Pic. 9 - R3's Update out Loopback 2.

Finally, what we have waited for is the answer to the question why R1 and R2 do not receive the subnets /28 from R3. Look at the below picture (pic. 10).

Pic. 10 - R3's update out F1/0.

Suprisingly, R3 does NOT advertise ANYTHING out towards R1 and R2 (out F1/0 interface). We understand, that R3 will not advertise out F1/0 what has been learned on this interface (split-horizon). But why does it not advertise both subnets configured on the loopback interfaces (172.31.3.0/28 and 172.31.3.16/28)?

The answer is the rules used in RIP in terms of sending and receiving updates.However, before I'll show you all the rules RIP uses, let's finish our diagnostics and look at what R3 is receiving from one of its neighbors R2 (pic. 11). Notice, that the update R3 receives from R2 does NOT contain network mask, only metric (hop-count) like explained in the previous lesson.

Pic. 11 - R2 Advertisement for R1 and R3.

RIPv1 Sending and Receiving Updates RulesNow, let me show you the update rules RIP uses which should clarify its behavior shown in this lesson.

Pic. 12 - RIP Rules for Sending Updates.

Clearly, according to pic.12, R3 will not advertise /28 subnets since the egress interface (F1/0) DOES belong to the same major B network, but the network mask on this interface is NOT the same as the subnets being advertised. Egress interface uses /24, whereas the subnet candidates for advertisement use /28.

The only way to resolve this issue is to either re-address the subnets according to what is allowed in RIPv1 or use RIPv2 instead.

As for the receiving updates in RIP protocol, the rules look as follows:

Pic. 13 - RIP Rules for Receiving Updates.

Passive Interface in RIP Protocol

You may have noticed that updates are sent out of all interfaces enabled for RIP. Otherwise routing would not work properly.

But what if there is no router listening to these advertisements? A router can be connected to networks with no other routers in them. They must be advertised out other interfaces still. In such situation it is a waste of the bandwidth to send RIP advertisements every 30 seconds if no router listens to them.

The solution is to use the 'passive-interface' command under the RIP process. When used with RIP protocol, the command will prevent a router from sending advertisements out the passive interface, but the subnet/network address of this interface is going to be included in the updates sent out other interfaces. Also, passive interface in RIP is capable of receiving updates and processing them.

Be careful with making the interface 'passive' while using other routing protocol than RIP. The behavior of the same command will be different. In OSPF or EIGRP routing protocols, the 'passive-interface' command prevents these protocols from sending 'hello' packets which has serious implications. More on that in the upcoming posts.

As an example, in order to stop sending advertisements out R3's loopback interfaces, the configuration will look like the one shown below:

R3#configure terminalR3(config)#router ripR3(config-router)#passive-interface loopback1R3(config-router)#passive-interface loopback2

This configuration optimizes RIP operation preventing it from sending its periodic advertisements out of both loopback interfaces.

Of course, in large systems using RIP is not a common solution. Those who have no other choice, would definitely choose RIPv2 rather than RIPv1. And this is going to be the topic of my next post which finalizes the discussion of RIP fundamentals.

Post Questions and AnswersAs per request (look at comments below), I decided to post the explanation for the two very interesting scenarios I received from some anonymous person (forgive me but I did not see your name in the post).

First take a look at the picture below.

Pic. 14 - RIPv1 Scenarios.

Example 1Notice that in RIPv1 auto-summarization to the class boundary is always in effect.Also, notice that the update does NOT contain a network mask.

R1 receives two RIPv1 updates:

10.0.0.0 from R2. 10.0.1.0 from R3.

The result is as per the rules explain above (pic. 13). R1 is going to have only one RIP prefix which is 10.0.1.0 in its routing table. This is because the rule for receiving update is asking the following question (pic. 13):

Do any subnets of the same major class exist in the routing table?

Yes! 10.0.1.0 subnet exists, that is why 10.0.0.0 which is less specific (major class) is IGNORED.

Example 2Notice that in RIPv1 auto-summarization to the class boundary is always in effect.Also, notice that the update does NOT contain a network mask.

R1 receives the SAME prefix on two different interfaces F1/0 (10.0.4.1) and S0/1 (10.0.3.1).If the metric is the same, R1 considers both paths: via F1/0 and S0/1 as equal cost paths and performs a load balance. I hope that clarifies these two corner case scenarios!

Lesson 37 - Routing Information Protocol Part3 First, I would like to thank all of you who took the time to read my posts and left some comment. Your feedback means a lot to me and helps me keep up with this little project of mine. I really appreciate it. Thanks a million folks!

In this post, I'm going to finish the RIP fundamentals by showing you RIPv2 in action. After reading this, you will see the major differences presented in the lesson 35 (table1) in practice. Also, I want to present the authentication of RIP packets which protects the RIP domain from being poisoned with false routes.

I'm going to use the same topology diagram as in previous lessons. Currently, the routers are running RIPv1. If you read my previous post, you saw the routing problems we ran into as RIPv1 does not advertise network masks along with IP addresses. The rules for sending and receiving updates are explained in lesson 36.

Pic. 1 - Topology Diagram.

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

As you remember, the subnets: 172.31.3.0/28 and 172.31.3.16/28 have not been advertised by RIPv1. There are a few solutions to this problem, but none of them can be resolved using RIPv1. The simplest solution is to use RIPv2 which is classless routing protocol.

Our current RIPv1 configuration looks like this (here: R1 given as and example).

Pic. 2 - R1's RIPv1 configuration

Now, let's enable RIPv2. Below is an example of R1's configuration. The two highlighted commands are now added on all routers in the topology.

R1 configuration:

R1#configure terminal

R1(config)#router rip

R1(config-router)#version 2

R1(config-router)#no auto-summary

R1(config-router)#network 172.31.0.0R1(config-router)#passive-interface loopback1

R1(config-router)#end

R1#

version 2 - Enables RIPv2. no auto-summary - Disables automatic summarization to a class boundary.

Technically, the 'no auto-summary' command is not necessary in this topology, but it will not do any

harm. If a router has interfaces configured with IP subnets belonging to different IP classes, this command becomes mandatory if you want to advertise these subnets with their original network masks.

If you display the running configuration of R1, it is going to look like the one below :

Pic. 3 - R1's RIPv2 Configuration.

Now, let's look at the output of 'show ip protocols' on R3. You can compare it with RIPv1 output in

the previous post (lesson 36).

Notice, the 'send and receive version'. Only RIPv2 updates will be sent and accepted now. Also, 'Automatic network summarization is not in effect' tells us that 'no auto-summary' command has

been used. Also, both loopback interfaces are listed as 'Passive interface(s)'.

Pic. 4 - RIPv2 Information on R3.

It is also a good idea to see RIPv2 advertisements. Again, be careful using 'debug' commands. For better output, I have also disabled the time stamps:

R3 Configuration:

R3#configure terminal

R3(config)#no service timestamps

R3(config)#end

WARNING! Extreme care must be taken when using any debug commands on the production equipment. After the diagnostics have been completed, the debug command(s) must be turned off immediately. All 'debug' commands are VERY dangerous if used on the production routers. They have enormous impact on the CPU and can potentially crash the device. They are typically used as the commands of the last resort during troubleshooting of a given technology when problem cannot be resolved without data they provide. So we tend to use them only in situations when we cannot do any more damage than there has already been done :-).

Pic. 5 - RIPv2 Debug Output on R3.

What are the major differences compared to RIPv1 output in the previous lesson?

1. Sending and receiving update using version 2. 2. Received networks/subnets via 0.0.0.0 mean that the advertising router (here: 172.31.123.2) is

the best gateway to the given destination.

3. Sending v2 update uses reserved multicast destination IP address 224.0.0.9 rather than broadcast.

Authentication of RIP PacketsAlmost all routing protocols allow to authenticate their packets. This is an extra security mechanism used to protect your routing domain. It is easy to install a routing protocol on a computer and poison the routing domain with illegitimate prefixes. This can disrupt the operation of the whole routing domain.

RIP offers two ways of authenticating their packets:

1. Simple Password (clear text) authentication. 2. MD5 based (one-way algorithm) authentication.

Here, I am going to show the more secure one based on well know hashing algorithm called Message Digest 5.

There are three major steps to configure authentication in RIP:

1. Configure a key chain - It allows to create multiple keys which can be changed automatically if the routers have the time synchronized. The name of the key chain does NOT have to be identical on all routers.

2. Configure at least one key-string (password) in the key chain - Key number MUST be identical on all routers in the RIP domain. Also, the password (key-string) used for authentication must be identical on all routers.

3. Apply the key chain - You must apply the key chain on the interfaces where RIP advertisements will be exchanged between the neighbors.

This configuration must be identical on all routers in the RIP domain. Here, I present the configuration on R3.

Step 1Create a key chain. The name of the key chain (here: RIP).

R3#configure terminal R3(config)#key chain RIPR3(config-keychain)#

Step 2Configure at least one key-string (password) in the key chain (must be identical on all routers). I do not use additional options allowing the key-string to timeout. The password used is valid forever.

R3(config-keychain)#key 1R3(config-keychain-key)#key-string secret123

R3(config-keychain-key)#exit

R3(config-keychain)#exit

R3(config)#

Step 3Apply the key chain on the appropriate interface(s). Here the packets must be authenticated between R1 and R2 routers so interface F1/0 will use the key chain.

R3(config)#interface f1/0R3(config-if)#ip rip authentication mode md5

R3(config-if)#ip rip authentication key-chain RIP

R3(config-if)#end

R3#

If you display information about RIP again, you will notice that authentication of RIP packets has been enabled.

Pic. 6 - RIPv2 Authentication.

If neighbors (R1 and R2) do not sign their packets using the same key number and key-string, R3 is going to reject their advertisements. Both R1 and R2 send their update without authentication. The result is that R3 must ignore them.

Check it out:

Pic. 7 - Invalid Authentication.

Once I have configured identical authentication on all routers, here is the debug output showing that R1 is sending RIP packets with proper authentication.

Pic. 8 - Authenticated RIPv2 Update from R1.

In the next post, I will start exploration of, arguably, the most commonly used routing protocol OSPF.