INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE CÓMPUTO

COMPUTERS NETWORKS

Practice 1 – settings IP’s and MSR

By:

Erick Jesus Romero Martinez

Profesor:
M. en C. NIDIA ASUNCIÓN CORTEZ DUARTE

September 2013
 Index

Content
Introduction:.............................................................................................................. 3

The ICMP Protocol........................................................................................................................... 3

The ARP Protocol............................................................................................................................. 5
Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs) ........................... 6

Problem: ................................................................................................................... 9

Hypothesis: ............................................................................................................... 9

Software (libraries, packages, tools): ............................................................................ 9

Procedure: ................................................................................................................. 9

Results (Data): ......................................................................................................... 23

Conclusions:............................................................................................................ 23
Introduction:

The ICMP Protocol

The Internet Control Message Protocol (ICMP), is a very popular protocol and actually part
of an Internet Protocol (IP) implementation. Because IP wasn't designed to be absolutely
reliable, ICMP came into the scene to provide feedback on problems which existed in the
communication environment.

ICMP is one of the most useful protocols provided to troubleshoot network problems like
DNS resolutions, routing, connectivity and a lot more, however caution must be taken
because you can easily end up spending half a day trying to figure out why you're not
getting a 'ping reply' ('echo reply' is the correct term) from a web server when in fact its
firewall is configured not to reply to 'pings' for security reasons! This usually leads most
engineers to the incorrect conclusion that the remote host might be down.

The Protocol

ICMP is defined in RFC (Request For Comments) 792. Looking at its position in the OSI
model we can see that it's sitting in the Network layer (layer 3) alongside IP. There are no
ports used with ICMP, this is because of where the protocol sits in the OSI model. Ports are
only used for protocols which work at the Session layer and above:

The ICMP protocol uses

different 'messages' to identify
the purpose of an ICMP
packet, for example, an 'echo'
(ping) is one type of ICMP
message.

I am going to break down the

different message descriptions
as they have been defined by
the RFC792.

There is a lot of information to

cover in ICMP so I have
broken it down to multiple
pages rather than sticking
everything into one huge page
that would bore you!

Also, I haven't included all the messages which ICMP supports, rather I selected a few of
the more common ones that you're likely to come across. You can always refer to the
RFC792 to get the details on all messages.
We will start with a visual example of where the ICMP header and information are put in a
packet, to help you understand better what we are dealing with

The structure is pretty simple, not a lot involved, but the contents of the ICMP header will
change depending on the message it contains. For example, the header information for an
'echo' (ping) message (this is the correct term) is different to that of a 'destination
unreachable' message, also a function of ICMP.

NOTE: If you were to run a packet sniffer on your LAN and catch a "ping" packet to see
what it looks like, you would get more than I am showing here. There will be an extra
header, the datalink header, which is not shown here because that header will change (or
more likely be removed) as the packet moves from your LAN to the Internet, but the 2
headers you see in this picture will certainly remain the same until they reach their
destination.

The table below shows all the ICMP messages the protocol supports. The messages that are
in the green colour are the ones covered. Please click on the ICMP message you wish to
read about:
 The ARP Protocol

Address Resolution Protocol (ARP) resides in the bottom half of the Network layer. It can
be considered a mechanism for mapping addresses between the Network logical addresses
and MAC (Media Access Control) layer physical addresses. For example: the Network
layer protocol IP is not aware of 48 bit MAC addresses such as Ethernet. Likewise the
MAC layer protocol such as Ethernet is not aware of 32 bit IP addresses. ARP provides the
mechanism to map MAC addresses to IP addresses in a temporary memory space called the
ARP cache.

The ARP cache is a dynamic cache and the information is stored only for 120 seconds.
After which it is discarded. In this manner, the ARP cache remains small. The ARP cache
can be viewed by using the "ARP -a" command at a command prompt. This should display
the current ARP cache. If nothing is displayed, then most likely your computer hasn't
communicated on the network for the past 120 seconds. Ping another device on the network
and see if the ARP cache has changed.

The basic operation of ARP is as follows. When the IP layer wants to communicate with
another device on the network, it checks the ARP cache to see if there is a match with an
Ethernet address. If there is no matching entry in the ARP cache, an ARP broadcast
datagram is sent out that basically says "Does anybody know whose Ethernet address
belongs to this IP address?". The receiving station that has the IP address, responds with an
ARP datagram that says "This is my IP address and here is my Ethernet address". The ARP
cache is updated and the original IP layer information is then passed on to the MAC layer
for processing.
Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)

Protocols are what describe the rules that control horizontal communication, that is,
conversations between processes that run at corresponding layers within the OSI Reference
Model. At every layer (except layer one) these communications ultimately take the form of
some sort of message that is sent between corresponding software elements on two or more
devices. Since these messages are the mechanism for communicating information between
protocols, they are most generally called protocol data units (PDUs). Each PDU has a
specific format that implements the features and requirements of the protocol.

Layer Services and Data Encapsulation

As we’ve already discussed in our look at protocols, the communication between layers
higher than layer one is logical; the only hardware connection is at the physical layer. Thus,
in order for a protocol to communicate, it must pass down its PDU to the next lower layer
for transmission. We’ve also already seen that using OSI terminology, lower layers are said
to provide services to the layers immediately above them. One of the services each layer
provides is this function: to handle and manage data received from the layer above.

At any particular layer N, a PDU is a complete message that implements the protocol at that
layer. However, when this “layer N PDU” is passed down to layer N-1, it becomes the data
that the layer N-1 protocol is supposed to service. Thus, the layer N protocol data unit
(PDU) is called the layer N-1 service data unit (SDU). The job of layer N-1 is to transport
this SDU, which it does in turn by placing the layer N SDU into its own PDU format,
preceding the SDU with its own headers and appending footers as necessary. This process
is called data encapsulation, because the entire contents of the higher-layer message are
encapsulated as the data payload of the message at the lower layer.

What does layer N-1 do with its PDU? It of course passes it down to the next lower layer,
where it is treated as a layer N-2 SDU. Layer N-2 creates a layer N-2 PDU containing the
layer N-1 SDU and layer N-2’s headers and footers. And the so the process continues, all
the way down to the physical layer. In the theoretical model, what you end up with is a
message at layer 1 that consists of application-layer data that is encapsulated with headers
and/or footers from each of layers 7 through 2 in turn, as shown in the next figure.

Each protocol creates a protocol data unit (PDU) for transmission that includes headers
required by that protocol and data to be transmitted. This data becomes the service data
unit (SDU) of the next layer below it. This diagram shows a layer 7 PDU consisting of a
layer 7 header (“L7H”) and application data. When this is passed to layer 6, it becomes a
layer 6 SDU. The layer 6 protocol prepends to it a layer 6 header (“L6H”) to create a layer
6 PDU, which is passed to layer 5. The encapsulation process continues all the way down
to layer 2, which creates a layer 2 PDU—in this case shown with both a header and a
footer—that is converted to bits and sent at layer 1.
 OSI Reference Model Data Encapsulation

Data Encapsulation in TCP/IP

The “N-1, N-2” stuff makes this seem more difficult than it really is, so let’s use a real-
world (simplified) example instead. The Transmission Control Protocol (TCP) operates at
layer 4 of the OSI model. It transmits messages called segments that contain data
encapsulated from higher-layer protocols. The layer below TCP is the Internet Protocol (IP)
at layer 3. It receives data from TCP and encapsulates it for transmission.

So, in the formal language of the OSI Reference Model, TCP segments are created as layer
4 PDUs. When passed to IP, they are treated as layer 3 SDUs. The IP software packages
these SDUs into messages called IP packets or IP datagrams, which are layer 3 PDUs.
These are in turn passed down to a layer 2 protocol, say Ethernet, which treats IP datagrams
as layer 2 SDUs, and packages them into layer 2 PDUs (Ethernet frames) which are sent on
layer 1. (Actually, in some technologies further encapsulation even occurs at layer one prior
to transmission.)

On the receiving device, the process of encapsulation is reversed. The Ethernet software
inspects the layer 2 PDU (Ethernet frame) and removes from it the layer 2 SDU (IP
datagram) which it passes up to IP as a layer 3 PDU. The IP layer removes the layer 3 SDU
(TCP segment) and passes it to TCP as a layer 4 PDU. TCP in turn continues the process,
going back up the protocol layer stack. The complete process is illustrated in the next
figure.

OSI Reference Model PDU and SDU Encapsulation

This example shows in more detail how OSI PDUs and SDUs are created and encapsulated.
A TCP segment (layer 4 PDU) becomes a layer 3 SDU, which is encapsulated into a layer 3
PDU through the addition of an IP header. This becomes the payload of an Ethernet frame,
which is a layer 2 PDU containing an Ethernet header, layer 2 SDU (the IP datagram) and
Ethernet footer. The receiving device extracts the IP datagram from the Ethernet header and
passes it to layer 3; the IP software extracts the TCP segment and passes it up to the TCP
software.
Problem:

How to connect two computers in a network?

Hypothesis:

We can connect two computers using a copper cross-over, also we need to make the
appropriate settings to connect. Other solution may be connected to a intermediary such as
a hub, switch, etc.

Software (libraries, packages, tools):

Was used Cisco Packet Tracer program, version 5.3.0.0088

Procedure:

First open the Cisco packet tracer program

On the option “End devices” selected two computers PC-PT.

Then select the button “Connections” and select a Copper Cross-Over.

Then select this cable, give double click in a PC 0 and select FastEthernet, do the same with
the PC 1.

The cable connects both PC’s.

Then you have to set the direction IP of each PC, give double click a PC, and select the
button Desktop, and the IP configuration.

We can’t select the IP 150.1.1.0 because this direction is for the sub red.
For the PC 0 we select the IP 150.1.1.1 with MSR /24.

For the PC 1 we select the IP 150.1.2.2 with MSR /24.

Simulations pressed the button and edit the simulation filters

Select only ARP and ICMP protocols

To verify that there is communication between the machines have to send a message from
PC 0 to PC 1

The message wasn’t sent because the IP's are different, the PC 0 has IP 150.1.1.1 and the
PC 1 has IP 150.1.2.2.
if we press the info box we can see the potential errors for not carrying out the
communication.

change the IP of PC 1
to send another you see the message, enter the ARP protocol which obtains the MAC
address of the other PC.
After obtaining the MAC address of the target PC, it follows the process with the ICMP
protocol to send the message.
To see the details of the PDU, we entered info, and then Outbound PDU Details to see which message was sent of segment.
As in the first message, do not know your MAC address of the other PC, so you run the ARP protocol, and we can see how it communicates.
To get the MAC address, the ICMP protocol begins transferring the message to the target PC
If you re-send another message, no longer runs the ARP protocol as previously and had
obtained the destination MAC.
 Two messages were sent or received and were successfully.

Results (Data):

We was held the connection of two computers in network using crossover cable and
making the settings correctly. We could exchange information between the two PC's.

Conclusions:

Could exchange information between two PC’s and we understood the operating ARP and ICMP
protocol to perform this process, the information needed to change the settings correct ip's and
PC's MSR.