lab day2

8/3/2019 lab day2

http://slidepdf.com/reader/full/lab-day2 1/8

1

Master of Engineering inInternetworking

Part 2 Submission

Chapter # 4, 5, 6, 7

TCP/IP

Question Number Marks Obtained

Lab 4.5a

Lab 4.5b

Exercise 5.2

Lab 6.5

Lab 7.2

Lab 7.3

Name: Varun Sarangal

8/3/2019 lab day2


2

Day 2 Submission

Lab 4.5a: Clear the ARP cache and using tcpdump show a normal ARP exchange. Do not

forget to annotate your submission with comments showing the purpose of the commands

(e.g., to clear the ARP cache, listen to message/packet exchange) and the resultingexchange of information. Note that the -e switch with tcpdump will show the hardwareaddresses.

Purpose of the Lab:

To observer an ICMP port unreadable message and to understand how the ICMP message isused to identify the problem.

Lab Setup:

1. On hostA1 delete the arp cache entries.

[student@hostA1 ~]$ sudo arp –ad

2. On hostA1 start the tcpdump to observe icmp or arp messages.

[student@hostA1 ~]$ sudo tcpdump -n -e -v icmp or arptcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes

Results:

18:10:52.625045 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.1.254 tell 10.1.1.1,length 28

18:10:52.625085 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.1.1.254 is-at 00:00:0a:00:01:fe,

length 28

18:10:52.625330 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.1.2 tell 10.1.1.1, length28

18:10:52.625579 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.1.1.2 is-at 00:00:0a:00:01:02, length28

Discussion:

In packet 1 sender hostA1 broadcast the signal on a network with the IP address of the

destination hostC1 called ARP request.In packet 2 destination hostC1 respond to sender with

ARP reply with its MAC.In packet 3, Now sender is known to the Mac address of the destinationhostC1, it ping the hostC1 with ipv4 packet containing ICMP message with echo request from

hostA1 to host c1.

8/3/2019 lab day2


3

Conclusion:

To establish a connection with a new host whose address is not in ARP cache we need the

hardware address.

Lab 4.5b: Clear the ARP cache and using tcpdump show ARP messages when trying totelnet to a non-existent host. Also observe the TCP timeout value.

Purpose of the Lab:

To check the telnet connection for a non-existent host.

Lab Setup:

1: On hostA1 set the tcpdump to observe the arp or ICMP packets.

[student@hostA1 ~]$ sudo tcpdump -n -e -v icmp or arptcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes

2: On same host telnet a non-existent host having ip address 10.1.2.8

Results:tcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes18:16:49.597947 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.1.254 tell 10.1.1.1,length 28

18:16:49.597990 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.1.1.254 is-at 00:00:0a:00:01:fe,length 28

18:17:05.416015 IP (tos 0x0, ttl 63, id 62183, offset 0, flags [DF], proto ICMP (1), length 72)10.1.5.2 > 10.1.1.1: ICMP host 10.1.2.8 unreachable, length 52

IP (tos 0x10, ttl 63, id 61448, offset 0, flags [DF], proto TCP (6), length 44)10.1.1.1.55030 > 10.1.2.8.9: Flags [S], cksum 0x22f6 (correct), seq 3510923777, win 17376,

options [mss 1460], length 0

18:17:11.613569 IP (tos 0x0, ttl 63, id 62184, offset 0, flags [DF], proto ICMP (1), length 72)

10.1.5.2 > 10.1.1.1: ICMP host 10.1.2.8 unreachable, length 52IP (tos 0x10, ttl 63, id 61449, offset 0, flags [DF], proto TCP (6), length 44)

10.1.1.1.55030 > 10.1.2.8.9: Flags [S], cksum 0x22f6 (correct), seq 3510923777, win 17376,options [mss 1460], length 0

8/3/2019 lab day2


4

Discussion: We can observe that there is no host present on network which we are trying to

telnet, so the sender keep on sending ARP request.

Conclusion: we can conclude that ARP request keep on broadcasting in network.

Exercises 5.2 Any reasonable submission is acceptable

Lab 6.5: Use tcpdump to show an exchange of messages that includes an unreachable portmessage. Briefly describe how you generated/caused the unreachable port message, show

the usage of commands/programs and also annotate the exchange of messages. Explain

how the ICMP message is used to identify the IP datagram which caused the error.

Lab Setup:

1. On hostA1 start tcpdump to observer UDP or ICMP.

#sudo tcpdump –n –v port 9999 or icmp

2. On host A1 send a UDP datagram to hostA2 port 9999

#sock –u hostA2 9999

[student@hostA1 ~]$ sock -u hostA2 9999

Results and Discussion:

Results:

[student@hostA1 ~]$ sudo tcpdump -n -v port 9999 or icmptcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes

17:03:51.733921 IP (tos 0x0, ttl 64, id 61381, offset 0, flags [none], proto UDP (17),

length 29)

10.1.1.1.26793 > 10.1.1.2.9999: UDP, length 1

This message shows that HostA1 with Ip address “10.1.1.1” and port “26793”

tried to make the connection with HostA2 on port “9999”.

8/3/2019 lab day2


5

17:03:51.734007 IP (tos 0x0, ttl 64, id 61373, offset 0, flags [none], proto ICMP (1), length56)

10.1.1.2 > 10.1.1.1: ICMP 10.1.1.2 udp port 9999 unreachable, length 36IP (tos 0x0, ttl 64, id 61381, offset 0, flags [none], proto UDP (17), length 29)

10.1.1.1.26793 > 10.1.1.2.9999: UDP, length 1

This message shows that HostA1 was unable to make the connection with HostA2on port 9999. And the ICMP error message is received by HostA1.

Conclusion: From the observation we can conclude that unreachable host message will be in

ICMP message containing IP header.

Lab 7.2: Show the result of performing a ping on our network. As usual, show relevantportions of the tcpdump output in each of the cases. Send only 5 ping requests to keep the

output short. Explain how the round trip times (RTT) are computed.

Purpose of the Lab:

Observer the operation of ping.

Lab Setup:

1. On hostA1 start start tcpdump to obseve ICMPSudo tcpdump –n –v icmp

2. On hostA1send 5 ping requests to hostC1

Ping –c5 hostC1

Results:

Tcpdump output :

[student@hostA1 ~]$ sudo tcpdump -n -v icmp

tcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes


10.1.1.1 > 10.1.3.1: ICMP echo request, id 52241, seq 0, length 6417:46:53.393294 IP (tos 0x0, ttl 62, id 61397, offset 0, flags [none], proto ICMP (1), length

84)

8/3/2019 lab day2


6

10.1.3.1 > 10.1.1.1: ICMP echo reply, id 52241, seq 0, length 6417:46:54.371235 IP (tos 0x0, ttl 64, id 61409, offset 0, flags [none], proto ICMP (1), length

84)10.1.1.1 > 10.1.3.1: ICMP echo request, id 52241, seq 1, length 64


10.1.3.1 > 10.1.1.1: ICMP echo reply, id 52241, seq 1, length 6417:46:55.371672 IP (tos 0x0, ttl 64, id 61410, offset 0, flags [none], proto ICMP (1), length84)

10.1.1.1 > 10.1.3.1: ICMP echo request, id 52241, seq 2, length 64


10.1.3.1 > 10.1.1.1: ICMP echo reply, id 52241, seq 2, length 64


10.1.1.1 > 10.1.3.1: ICMP echo request, id 52241, seq 3, length 6417:46:56.395384 IP (tos 0x0, ttl 62, id 61400, offset 0, flags [none], proto ICMP (1), length

84)10.1.3.1 > 10.1.1.1: ICMP echo reply, id 52241, seq 3, length 64





Ping output:

PING hostc1.test.ca (10.1.3.1): 56 data bytes

64 bytes from 10.1.3.1: icmp_seq=0 ttl=62 time=23.067 ms64 bytes from 10.1.3.1: icmp_seq=1 ttl=62 time=22.140 ms

64 bytes from 10.1.3.1: icmp_seq=2 ttl=62 time=22.275 ms64 bytes from 10.1.3.1: icmp_seq=3 ttl=62 time=22.578 ms

64 bytes from 10.1.3.1: icmp_seq=4 ttl=62 time=22.784 ms

--- hostc1.test.ca ping statistics ---

5 packets transmitted, 5 packets received, 0.0% packet lossround-trip min/avg/max/stddev = 22.140/22.569/23.067/0.336 ms

Discussion:

RTT is in option and RED color highlight represents the RTT of 5 times ping.

Conclusion:

RTT is calculated on the basis of 5 times of echo requests and echo replies.

8/3/2019 lab day2


7

Lab 7.3: Show the result of a ping with Record Route Option through at least 3 routers onour network. Send only 1 ping request to keep the output short. Use the -vvv switch of

tcpdump to see the IP header options. Show how the tcpdump output indicates the optionsportion of the IP header. Show how our tcpdump indicates the pointer position.

Purpose of the Lab:

To show the output using record route option and indicating the pointer option in tcpdump

Lab Setup:

1. On hostA1 start tcpdump to observer icmp

[student@hostA1 ~]$ sudo tcpdump -n -vvv icmp

2. [student@hostA1 ~]$ ping -c1 -R hostD1

Results and Discussion:

Results:

Tcpdump output :

tcpdump: listening on e0, link-type EN10MB (Ethernet), capture size 96 bytes

18:27:22.687061 IP (tos 0x0, ttl 64, id 61475, offset 0, flags [none], proto ICMP (1), length 124, options (RR0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0,EOL))


18:27:22.709570 IP (tos 0x0, ttl 61, id 61413, offset 0, flags [none], proto ICMP (1), length 124, options (RR10.1.6.1, 10.1.3.254, 10.1.4.254, 10.1.4.1, 10.1.3.3, 10.1.6.2, 10.1.1.254, 0.0.0.0 0.0.0.0,EOL))


Ping output

PING hostD1.test.ca (10.1.4.1): 56 data bytes

64 bytes from 10.1.4.1: icmp_seq=0 ttl=61 time=44.387 ms

RR: routerA.test.ca (10.1.6.1)

routerC.test.ca (10.1.3.254)

routerD.test.ca (10.1.4.254)

hostD1.test.ca (10.1.4.1)

routerD.test.ca (10.1.3.3)

8/3/2019 lab day2


8

routerC.test.ca (10.1.6.2)

routerA.test.ca (10.1.1.254)

hostA1.test.ca (10.1.1.1)

--- hostD1.test.ca ping statistics ---

1 packets transmitted, 1 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 44.387/44.387/44.387/0.000 ms

Discussion:

The route towards the destination hostD1 and backtracks to the sender hostA1 via same route.

Conclusion:

Echo request is generated towards the host D1 via different routers and echo reply is responded

back through the same route.

lab day2

Documents