Clear The Arp Cache

Published Date: 02 Nov 2017

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:Akash Luthra(B00589315)

Part 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 resulting exchange of information. Note that the -e switch with tcpdump will show the hardware addresses.

Purpose of the Lab:

The purpose of the lab is to show a normal ARP exchange.

Lab Setup:

Start tcpdump on hostC1.

sudo tcpdump -ne -vvv arp or icmp

Comment: This command captures arp and icmp Packets passing by Host C1. ‘–ne’ will not convert the IP addresses of the passing by arp and icmp packets into its host name , and also will print the link layer level headers and ‘–vvv’ will print the output the output verbosely.

Clear the ARP cache on hostC1.

sudo arp –ad

Comment: This command clears the ARP Cache memory . ’arp’ will access the arp cache memory and ‘-ad’ will delete the all the entries that are there in the cache.

On hostC1 send a single ping request to hostC2.

ping –c1 hostC2

Comment: This command deals with the pinging a particular host (in this case host C2) ensuring whether the host C2 is reachable from host C1 or not. ’-c1’ ensure that only one ping request should be send to the host C2.

Observe the tcpdump output.

Observe the ARP cache on hostC1 after the ping.

arp -a

Results and Discussion:

Results:

ARP cache before the experiment:

ARP Cache at HostC1:

hostC1.test.ca (10.1.3.1) at 00:00:0a:00:03:01 on e0 permanent [ethernet]

routerC.test.ca (10.1.3.254) at 00:00:0a:00:03:fe on e0 expires in 954 seconds [ethernet]

Comment: The above output is the result of the "arp –a" command which was executed on host C1 and it displays the IP and MAC addresses of the hosts prior to the conduct of the experiment.

Ping output:

64 bytes from 10.1.3.2: icmp_seq=0 ttl=64 time=0.560 ms

--- hostC2.test.ca ping statistics ---

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

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

Comment: Host C1 has been pinged from the host C1 and as we see that the host C2 is reachable from the host C1 in addition to this host C2’s IP and MAC address get added to the empty ARP Cache memory list of host C1. The Time shown in the output is the rrt(Round Trip Time) taken by the ping packet to travel to host C2 and back to host C1.

ARP cache after the ping:

hostC1.test.ca (10.1.3.1) at 00:00:0a:00:03:01 on e0 permanent [ethernet]

hostC2.test.ca (10.1.3.2) at 00:00:0a:00:03:02 on e0 expires in 1078 seconds [ethernet]

routerC.test.ca (10.1.3.254) at 00:00:0a:00:03:fe on e0 expires in 1026 seconds [ethernet]

Comment: Above is the listing of the ARP cache after the issue of ping command from host C1 to host C2. As we can see from the above output that apart from the listing of Host C’s IP and MAC address , the output is also displaying the IP and MAC addresses of the Host C2 and router C which is the gateway.

tcpdump output:

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

14:59:09.127554 00:00:0a:00:03:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806),

length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.3.254 tell

10.1.3.1, length 28

14:59:09.127602 00:00:0a:00:03:fe > 00:00:0a:00:03:01, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.3.254 is-at 00:00:0a:00:03:fe, length 28

15:00:01.207391 00:00:0a:00:03:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.3.2 tell 10.1.3.1, length 28

15:00:01.207770 00:00:0a:00:03:02 > 00:00:0a:00:03:01, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.3.2 is-at 00:00:0a:00:03:02, length 28

15:00:01.207771 00:00:0a:00:03:01 > 00:00:0a:00:03:02, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18332, offset 0, flags [none], proto ICMP (1), length 84).

> 10.1.3.2: ICMP echo request, id 24072, seq 0, length 64

(6) 15:00:01.207822 00:00:0a:00:03:02 > 00:00:0a:00:03:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18326, offset 0, flags [none], proto ICMP (1), length 84)

10.1.3.2 > 10.1.3.1: ICMP echo reply, id 24072, seq 0, length 64

^C

6 packets captured

22 packets received by filter

0 packets dropped by kernel

Comment:First an ARP Broadcast is send for the gateway’s address, upon receiving that another ARP Broadcast is sent for the destination’s physical address. Upon receiving the destination’s address its added to the ARP cache of the sender and a destination host is then pinged i.e an ICMP request is send to the destination. Preceded exchanges of the ARP request and reply were having the frame length of 42 bytes(14 bytes of Ethernet Header + 28 bytes of ARP Header and message). The request of ICMP request is further acknowledge with an ICMP reply. These ICMP request and reply were having the frame length of 98 bytes(14 bytes of Ethernet Header + 20 bytes of IP header + 8 bytes of ICMP header + 56 bytes of data as the IMCP message)

Discussion:

As we can see that for the sake of pinging a host there is was an exchange of 6 packets because the source host wasn’t even had the Ethernet address of the gateway in its ARP cache. In normal cases the there is an exchange of 4 packets only i.e source host asks for destination’s physical address and then ping it. The ARP request and reply composes of a frame length of 42 bytes (14 bytes of Ethernet Header + 28 bytes of ARP Header and message) and the ICMP request and reply composes of frame length of 98 bytes (14 bytes of Ethernet Header + 20 bytes of IP header + 8 bytes of ICMP header + 56 bytes of data as the IMCP message).

Conclusion:

We have observed a normal ARP exchange which results in a new ARP table entry.

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

Purpose of the Lab:

The purpose of the lab is to show ARP requests to a non-existent host and to observe the TCP timeout value.

Lab Setup:

Start tcpdump on hostC1.

sudo tcpdump -n port discard or arp

Comment: ‘tcpdump’ executes the packet capturing implementation from the host C1, ‘port discard or arp’ ensure the fact the only packet that are destined for the discard port or they arp should only be captured.

Show the ARP cache on hostC1.

arp -a

Comment: The above command will enlist all the entries that are there in the arp cache memory of host C1.

On hostC1 telnet to 10.1.3.5 (non-existent)

date; telnet 10.1.3.5 discard; date

Comment:’date’ will display the current date and time in a readable format and ‘telnet’ will try to establish a telnet connection from the host C1 to 10.1.3.5 which in actually does not exist.

Observe the tcpdump output.

Results and Discussion:

Results:

ARP cache before the experiment:

hostC1.test.ca (10.1.3.1) at 00:00:0a:00:03:01 on e0 permanent [ethernet]

hostC2.test.ca (10.1.3.2) at 00:00:0a:00:03:02 on e0 expires in 718 seconds [ethernet]

routerC.test.ca (10.1.3.254) at 00:00:0a:00:03:fe on e0 expires in 666 seconds [ethernet]

Comment: The above is the result of the ‘arp –a’ command which is enlisting the arp cache memory entries on the host C1.

telnet to a nonexistent host:

[student@hostC1 ~]$ date;telnet 10.1.3.5 discard; date

Tue Jan 22 14:41:53 AST 2013

Trying 10.1.3.5...

telnet: connect to address 10.1.3.5: Operation timed out

telnet: Unable to connect to remote host

Tue Jan 22 14:43:08 AST 2013

tcpdump output:

[student@hostC1 ~]$ sudo tcpdump -n port discard or arp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

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

14:41:53.160312 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:41:56.159482 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:41:59.358293 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:02.557514 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:05.756347 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:08.955366 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:15.153501 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:27.349574 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

14:42:51.542219 ARP, Request who-has 10.1.3.5 tell 10.1.3.1, length 28

^C

9 packets captured

27 packets received by filter

0 packets dropped by kernel

Comment: As we can see from the above output of the ‘tcpdump’ command that an arp request is being sent to that non-existant host 10.1.3.5. Upto starting 6 requests each request is being sent after an interval of 3 seconds but after that 7th request was sent after 6 seconds and 8th request after 12 seconds and last one was sent after an interval of 24 seonds. From the preceded explaination we an conclude that in the case when the source is not getting a for its ARP broadcast, it keep sending an ARP request in evey 3 seconds. But after that each request is send after twice the interval of the previous request. The Source givesup after 75 seconds.

ARP cache after the ping:

hostC1.test.ca (10.1.3.1) at 00:00:0a:00:03:01 on e0 permanent [ethernet]

hostC2.test.ca (10.1.3.2) at 00:00:0a:00:03:02 on e0 expires in 569 seconds [ethernet]

routerC.test.ca (10.1.3.254) at 00:00:0a:00:03:fe on e0 expires in 1005 seconds [ethernet]

Comment: ARP cache entries after the conduct of experiment.

Discussion:

As we can see that entries in the arp cache are unchanged before and after the issue of the telnet command because the telnet was issued in the name of an host which does not exist in reality that is why there was no scope of any upgradation of arp cache on host C1.

Conclusion:

We have observed ARP requests to a non-existent host. We also observed the "exponential backoff" used by TCP and the overall TCP timeout of 75 secconds.

Exercises 5.2 In the Scenario of the multiple RARP server in the network a condition might can occur where all the servers are responding to the RARP request simultaneously resulting in collision. The preceded mentioned condition can be avoided if the switch or the Hub to which all the hosts are connected in the network is implemented with some sufficient buffer memory at each of its interface. If each received packet will be made to buffer before being forwarded the probability of collision would suffer a serious fall.

Lab 6.5: Use tcpdump to show an exchange of messages that includes an unreachable port message. 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.

Purpose of the Lab:

The purpose of the lab is to observe an ICMP port unreachable message and to see how the ICMP message is used to identify the IP datagram which caused the error.

Lab Setup:

Start tcpdump on hostC1.

sudo tcpdump -N -vvv -s512 udp and port 32000 or icmp

Comment: ’tcpdump’ is being used here to capture the TCP/IP packets that conforms to the given conditions of ‘-N’ which states that qualification of the host domain shouldn’t be disclosed, ‘vvv’ states that the output should be very verbose, ’-s512’ states that the maximum packet size should be 512 bytes and in regards to the preceded the destined port number should be the one among UDP,ICMP or 32000.

On hostC1 send a single UDP datagram (UDP data size = 100 bytes) to a non-existent port on hostA1.

sock -i -u -n1 -w 100 hostA1 32000

Comment: ‘sock’ creates an end point communication socket with the following parameters:

-i: source data should be send via this socket

-u: ensures UDP encapsulation of the packet.

-n1:determines that number of packet to be sent should be 1.

-w: write the raw packet to file of 100 bytes.

hostA1 32000: Destination address with the port number.

Observe the tcpdump output.

Results and Discussion:

Results:

tcpdump output:

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

16:02:09.017858 IP (tos 0x0, ttl 64, id 21815, offset 0, flags [none], proto UDP (17), length 128)

hostC1.64670 > hostA2.32000: [udp sum ok] UDP, length 100

16:02:09.040128 IP (tos 0x0, ttl 62, id 21811, offset 0, flags [none], proto ICMP (1), length 56)

hostA2 > hostC1: ICMP hostA2 udp port 32000 unreachable, length 36

IP (tos 0x0, ttl 62, id 21815, offset 0, flags [none], proto UDP (17), length 128)

hostC1.64670 > hostA2.32000: UDP, length 100

^C

2 packets captured

36 packets received by filter

0 packets dropped by kernel

Comment: Displays the results of the tcpdump command applied at host C1. Output shows the UDP packet sent to host A1 at port 32000 from host C1 followed by an ICMP host unreachable error message which states that the port to whom a packet was sent with information IP (tos 0x0, ttl 62, id 21815, offset 0, flags [none], proto UDP (17), length 128) in the IP header to host A1 destined for the port 32000 is unreachable.

Discussion:

An ICMP error message is generated in response to an error generated by a packet destined for a port in a host which has not been allotted to any user process. This error message travels back to the source of the packet generator to notify the user process at source which generated that packet about the unreachability of the destination port.

Conclusion:

We have observed an ICMP port unreachable message and we have shown how the ICMP message is used to identify which IP datagram caused the error

Lab 7.2: Show the result of performing a ping on our network. As usual, show relevant portions 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:

The purpose of the lab is to observe an ICMP echo request/reply and to see how the round trip times are calculated.

Lab Setup:

Start tcpdump on hostC1.

sudo tcpdump –n –vv icmp

Comment: This command execute the process of capturing the packets that passes by the host C1 with the instructions that in the output IP addresses should not be converted to their respective host names(-n), the output should be verbose(-vv) and displays only the ICMP packets.

On hostC1 send 5 pings to hostA1

ping –c5 hostA1

Comment: This command pings host A1 5 times.

Observe the tcpdump output.

Results and Discussion:

Results:

Send 5 pings to hostA1:

PING hostA1.test.ca (10.1.1.1): 56 data bytes

64 bytes from 10.1.1.1: icmp_seq=0 ttl=62 time=23.376 ms

64 bytes from 10.1.1.1: icmp_seq=1 ttl=62 time=22.493 ms

64 bytes from 10.1.1.1: icmp_seq=2 ttl=62 time=22.538 ms

64 bytes from 10.1.1.1: icmp_seq=3 ttl=62 time=22.482 ms

64 bytes from 10.1.1.1: icmp_seq=4 ttl=62 time=22.475 ms

--- hostA1.test.ca ping statistics ---

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

round-trip min/avg/max/stddev = 22.475/22.673/23.376/0.352 ms

Comment: Host A1 has been pinged 5 times from the host C1 to check the reachability of hostA1 from hostC1. The output shows the minimum, average and maximum time that can be taken by a packet from hostC1 destined for hostA1.

tcpdump output:

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

16:11:45.919073 IP (tos 0x0, ttl 64, id 21822, offset 0, flags [none], proto ICMP (1), length 84)

10.1.3.1 > 10.1.1.1: ICMP echo request, id 38409, seq 0, length 64

16:11:45.942357 IP (tos 0x0, ttl 62, id 21814, offset 0, flags [none], proto ICMP (1), length 84)

10.1.1.1 > 10.1.3.1: ICMP echo reply, id 38409, seq 0, length 64

16:11:47.625860 IP (tos 0x0, ttl 64, id 21823, offset 0, flags [none], proto ICMP (1), length 84)

10.1.3.1 > 10.1.1.1: ICMP echo request, id 38409, seq 1, length 64

16:11:47.648326 IP (tos 0x0, ttl 62, id 21815, offset 0, flags [none], proto ICMP (1), length 84)

10.1.1.1 > 10.1.3.1: ICMP echo reply, id 38409, seq 1, length 64

16:11:49.333891 IP (tos 0x0, ttl 64, id 21824, offset 0, flags [none], proto ICMP (1), length 84)

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

16:11:49.356394 IP (tos 0x0, ttl 62, id 21816, offset 0, flags [none], proto ICMP (1), length 84)

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

16:11:51.031155 IP (tos 0x0, ttl 64, id 21825, offset 0, flags [none], proto ICMP (1), length 84)

10.1.3.1 > 10.1.1.1: ICMP echo request, id 38409, seq 3, length 64

16:11:51.053605 IP (tos 0x0, ttl 62, id 21817, offset 0, flags [none], proto ICMP (1), length 84)

10.1.1.1 > 10.1.3.1: ICMP echo reply, id 38409, seq 3, length 64

16:11:52.743065 IP (tos 0x0, ttl 64, id 21826, offset 0, flags [none], proto ICMP (1), length 84)

10.1.3.1 > 10.1.1.1: ICMP echo request, id 38409, seq 4, length 64

16:11:52.765512 IP (tos 0x0, ttl 62, id 21818, offset 0, flags [none], proto ICMP (1), length 84)

10.1.1.1 > 10.1.3.1: ICMP echo reply, id 38409, seq 4, length 64

^C

10 packets captured

16 packets received by filter

0 packets dropped by kernel

Comment: The ‘tcpdump’ output shows how the packet flow from an individual host are in a perfect order of sequence number. Each Time when the source which initiated the action of pinging host A1 sends an ICMP request message, it is accompanied by an ICMP reply message in return from the host A1.

Discussion:

As we can see each time when an ICMP request message is sent to hostA1 by hostC1 the sender(in this case host C1) records the time when that ICMP request is sent and again records the time when in-return ICMP reply is received. Further to compute the Round trip time(rrt), send time is subtracted from the received time each time when an exchange of ICMP Request is time sent.

Conclusion:

We have observed how the ping program works including how the RTT is calculated.

Lab 7.3: Show the result of a ping with Record Route Option through at least 3 routers on our 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 options portion of the IP header. Show how our tcpdump indicates the pointer position.

Purpose of the Lab:

The purpose of the lab is to observe how ping -R is implemented using the Record Route IP header option.

Lab Setup:

Start tcpdump on hostA1.

sudo tcpdump –n –vvv icmp

Comment:’tcpdump’ is initiating the execution of packet filtering process which conforms to the following conditions:

-n: IP addresses should not be converted to their respective host names.

-vvv: Output should be very verbose.

Icmp: only ICMP packets should be displayed in the output.

On hostA1 send 1 ping with the record route option to hostD1

ping –c1 –R hostD1.

Comment:A ping request is being send to host D1 from host A1 with the record route set as true.

Observe the tcpdump output.

Results and Discussion:

Results:

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=24.317 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)

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 = 24.317/24.317/24.317/0.000 ms

Comment: As the result of setting record route, we can see those outbound interfaces via which the ping request has passed by.

tcpdump output:

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

16:17:52.138133 IP (tos 0x0, ttl 64, id 21822, offset 0, flags [none], proto ICMP (1), length 124, options (RR 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.0,EOL))

10.1.1.1 > 10.1.4.1: ICMP echo request, id 9738, seq 0, length 64

16:17:52.162329 IP (tos 0x0, ttl 61, id 21816, offset 0, flags [none], proto ICMP (1), length 124, options (RR 10.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))

10.1.4.1 > 10.1.1.1: ICMP echo reply, id 9738, seq 0, length 64

^C

2 packets captured

28 packets received by filter

0 packets dropped by kernel

Comment: As we can see that the option field in the ICMP request sent was empty, but the Option field in the ICMP reply which we received is filled with 7 IP addresses. These IP addresses are the outbound interface addresses that the ICMP packet encountered during its tenure from hostA1 to hostD1 and then back to hostA1.

Discussion:

The ptr pointer is generally marked by (#) sign in the output (pointing to the next empty location reserved for the IP address). Ptr field has a minimum value of 4 which initially points to the first IP address. After 7 IP addresses which were encountered by the ICMP packet, the value of the ptr would have become 32.

Conclusion:

We have observed how the ping program with the –R option uses the Record Route IP header option to record the outgoing interfaces of the routers in the path from source to destination.