100 likes | 257 Views
ARP Under Abnormal Conditions. Experiment with the browser (1). arp -n # see what it there Open a browser on your personal workstation browse to 10.10.1.5 browse to 10.10.1.97 Did both pages fail exactly the same way? arp –n. Experiment with the browser (2).
E N D
Experiment with the browser (1) arp -n # see what it there • Open a browser on your personal workstation • browse to 10.10.1.5 • browse to 10.10.1.97 • Did both pages fail exactly the same way? arp –n
Experiment with the browser (2) sudo tcpdump –n –e –i eth0 not host 10.10.1.5 • Open a browser on your personal workstation • browse to 10.10.1.97 • browse to 10.10.1.5 • What does tcpdump tell you about each failure?
Experiment with the browser [ANS] • 10.10.1.5 is a DHCP server. It is not running a webserver. • The workstation sends an ARP request and gets a reply • The workstation sends a GET request to server port 80 and is refused a connection • The browser fails immediately • 10.10.1.97 is not a valid IP – no machine running • The workstation sends several ARP requests, waiting after each one, and never gets a reply. It never sends a GET request. • The browser waits for several seconds and eventually reports a failure
Good IP, bad MAC • Let’s see what happens if we create an entry in the ARP table with the proper IP for your webserver, but a bad MAC address • Window A: sudo tcpdump -n –e –i eth0 not host 10.10.1.5 • Window B: sudo arp –s 10.10.1.10 11.22.33.44.55.66 ping 10.10.1.10 • This fails to connect, but how does it fail? • What messages are sent/received?
Bad IP, good MAC • Let’s see what happens if we create an entry in the ARP table with the proper MAC for your webserver, but a bad IP address • Window A: Use command-line tools to find the MAC for the webserver: ping –c 1 10.10.1.10 arp –n # copy the good MAC for the webserver sudo arp –s 10.10.1.96 <paste the good MAC here> • Window B: sudo tcpdump -n –e –i eth0 not host 10.10.1.5 • Window A: Use command-line tools to send to the webserver: ping 10.10.1.96 wget 10.10.1.96
Dualing IP addresses • Let’s see what happens with two identical IP addresses on the network. Do the following: • Clone your webserver. Name the new machine colorweb-clone • Power on both webservers. • Record the MAC addresses of the webservers and one client • Clear your arp cache • In window A: sudo tcpdump –n –e –i eth0 not host 10.10.1.5 • In window B: ping –c 1 10.10.1.10 • Wait for 7 packets and stop tcpdump Explain your findings
Dualing MAC addresses (1) • Let’s see what happens with two identical MAC addresses on the network. Do the following: • Make the following changes in colorweb-clone: • sudo nano /etc/network/interfaces • # Change the IP address to 10.10.1.11 • Add this line above the ‘address’ to hard-wire the MAC; use your web server’s MAC: hwaddress 00:50:56:83:09:4e • Save and exit • sudo /etc/init.d/networking restart • Verify the MAC and IP for both webservers (same MAC, different IP) • Do the following in your personal workstaion: ping –c 1 10.10.1.10 ping –c 1 10.10.1.11 arp –n # Verify that both machines show up in the ARP table
Dualing MAC addresses (2) • (con’t) • In window A: sudo tcpdump –n –e –i eth0 not host 10.10.1.5 • In window B: ping –c 1 10.10.1.10 • # Wait a few seconds • In window B: ping –c 1 10.10.1.11 Explain your findings
Dualing MAC and dualing IP addresses • Make the following changes in colorweb-clone: • sudo nano /etc/network/interfaces • # Change the IP address to 10.10.1.10 • Leave the hard-wored MAC in place • Save and exit • sudo /etc/init.d/networking restart • Do the following in your personal workstaion: • In window A: sudo tcpdump –n –e –i eth0 not host 10.10.1.5 • In window B: ping –c 1 10.10.1.10 Explain your findings