CSC 175 Assignment and Lab Due one Week from lab date ----------------------- INDIVIDUAL HOMEWORK: read sections 3.2, 3.3 and 4.1 of the text, do the following exercises: Chapter 3: 33, 48, 55, 56 (56 has answers in back of book). 72, 73, 74. ----------------------- Routing Workshop This lab focuses on the IP protocol and local routing. You need to understand how the routing table works as well as the principal components of the IP header, especially the components that pertain to fragmentation. You will be using the following linux commands: ip link (set up/down, set mtu) e.g. ip linke set mtu 1000 dev enp9s0 - lowers max packet size from 1500 ip route add/del/change sets ip table. e.g. ip route add 10.4.64.0/18 dev eth1 ip route add 0.0.0.0/0 via 10.4.90.1 (must be next-hop) ip addr add/del CIDR network addresses. e.g ip addr add 10.4.64.1 dev eth1 ip addr add 192.168.0.1/24 dev ens1 #also adds dev route to ens1 ip rule (allows source address routing) ping: icmp echo request/reply with various options wireshark/tshark for monitoring packets The "iproute2 utility manual" explains the ip link/addr/route commands and the advanced routing howto explains ip rule. PRELAB CHECKLIST: Before starting the lab, make sure you have the following setup: a. original network setup. make sure you have the correct ip address, default route through deepdish, 10.1.0.98, and the correct contents of /etc/resolv.conf (should have 10.1.0.98 has nameserver). Also make sure that the interface that connects to Hofstra's network is deactivated (delete all addresses and do 'ip link set down dev eno1'). b. Make sure your firewall is turned off: (iptables -F to be sure) c. Make sure your system is configured for routing ******* echo 1 > /proc/sys/net/ipv4/ip_forward d. Do not ignore icmp ping broadcasts: echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts e. Make sure your https server is up and running f. Read the man page for ping. Understand how to use the -n, -s size, -R, -t and -M do (do NOT fragment) options. ****** You are REQUIRED to record the sequence of commands you used to effect each setup. Specifically, for each part of the assignment, record what you did to complete it in addition to answering the questions that are posed. Read the assignment carefully so as not to miss anything. ****** For this assignment, do not use names such as "thincrust". Use IP addresses directly. PART 1: Basic Experiments with Subnetting and Routing 1. Your initial ip setting has address 10.1.0.x/16 assigned to your "ens1", interface with local connection to 10.1.0.0/16 dev ens1 and default route via 10.1.0.98. Do not touch this setting (or you'll loose connectivity with the outside). For this lab, you are to active interface "enp9s0" (ip link set up dev enp9s0). This interface is connected to the same Ethernet switch as ens1 so physically you will see all other machines in our intranet. Some of your workstations may have only one of 'ens1' or 'enp9s0' working, in which case you will have to do this experiment using just one interface. 2 You eventually want to give enp9s0 the ip address 10.2.0.x, where 10.1.0.x is your ens1 address. However, first you have to figure out the network part of this address. We're going to divide the class into two small subnets: 10.2.0.0/29 and 10.2.0.8/29 a. Figure out which subnet your ip (10.2.0.x) belongs to. b. Add a dev enp9s0 route to your subnet (ip route add ...). The route should not be for anything wider than this specific subnet! c. Now assign the address 10.2.0.x to enp9s0 (ip addr add ...) d. At this point, try the following: ip route add 10.3.0.0/16 via 10.2.0.98 If you succeeded then you FAILED! EXPLAIN WHY. (it's not because there's no 10.3 network). 2. a. If deepdish (10.2.0.98) is also to be placed in a subnet with a 29 bit mask, what would it be? b. Add a route to deepdish's 29bit subnet. c. Try again to add a route to 10.3.0.0/16 via 10.2.0.98. Now it should work. EXPLAIN why. d. Add a route to the OTHER subnet (10.2.0.0/29 or 10.2.0.8/29) via 10.2.0.98. Ping somebody on the other subnet to verify that it works. Use ping -R to trace the route and make sure it went through 10.2.0.98. 3. Now we're one big happy family again? Well, not quite: there's something that's not done efficiently. Clear your ARP cache with "ip neigh flush all". Ping some host on the OTHER subnet. What do you see in your arp cache? EXPLAIN what's happening. Figure out the TIGHTEST subnet that all our hosts, including deepdish belongs to, and modify your routing table so that each host on the 10.2 supernet can be reached directly, without using a router. But remember, when looking up a routing table, the entry that represents the tightest (smallest) subnet has precedence. ====================================================================== PLEASE DO NOT CONTINUE TO THE NEXT PART UNTIL INSTRUCTED: ====================================================================== PART 2: Around The Ring We Go... Clear your routing table entries for the 10.2 network (ip route del ..). This clears the settings you made for part 1, but enp9s0 should still have address 10.2.0.x. 1. This time we're now going to create a virtual "ring" with our hosts. Each group will set their route to the 10.2 supernet (that contains everybody including 10.2.0.98) to be their right neighbor: 10.2.0.1 -> 10.2.0.3 -> 4 -> 5 -> 6 -> 8 -> 9 -> 12 -> 10.2.0.1 10.2.0.3 (thincrust) is under my control and I will configure it. Remember, in order to name a router (default or otherwise), you need to first describe how to find it (over what interface). That is, remember to add the network before the router to the routing table. You must configure your machine to route all outgoing IP packets to 10.2 to your right neighbor as listed above. You should be able to ping -R everyone on the ring BUT NOT OUTSIDE THE RING. Try pinging 10.2.0.98: this host is in the 10.2 network but it is not part of the ring. So if you got a response then you DID NOT DO THIS PART CORRECTLY. HA HA HA HA HA HA HA HA HA... That's me laughing at you because you didn't do the above part correctly. To understand why, examine your routing table, arp cache, and ping a host on the ring more than one "hop" away from you with the -R option, which shows you the route that the ping packet took. It's not what you expected, is it? See, it's a bit more subtle than it may appear, so STOP AND THINK!! Hint: use ip route change ... WHEN YOU'VE SET YOUR ROUTING TABLE ACCORDINGLY, let the prof know. We know that the entire ring is correctly configured if you can ping -R your upstream (left) neighbor with the desired effects (you can also use "traceroute" - first do apt-get install traceroute). 2. This part of the assignment asks you to change the mtu of your ring interface, and use wireshark to discover some more details about ip routing. You can use ip link and ping -s as instruments. Determine the following, AND DESCRIBE HOW YOU DETERMINED IT!!! i. When an ip packet is a fragment of a larger packet, what is the value of the 16-bit "total length" field of the packet? Is it the the length of the current fragment, or the length of the overall logical packet? Use tshark. ii. A packet could become fragmented multiple times. For example, a 2000 byte packet may be fragmented into two 1000 byte packets when going through a 1500 mtu link, but then these packets can become fragmented again when going through, say, 500 mtu links. Cooperating with another group (make friends), construct a situation where double fragmentation occurs. Is it possible to tell if a packet has been fragmented twice? Are there any special difficulties when reassembling fragments that has been fragmented multiple times? (hint: pay attention to what happens to the identifier). 3. This part of the assignment asks you to do "path mtu discovery". Ping the host that's farthest away from you on the ring (your left neighbor). Using the appropriate values for the -s and -M options of ping, along with wireshark/tshark if you want, you should be able to determine the MTU of the ring - that is, the largest packet that can traverse the ring without fragmentation. Your answer should be accurate to within 64 bytes. Were you also able to determine *which* host had the smallest mtu? How? Remember to explain in detail what you did. ================== PART 3: 1. IPv6 Most of the basic concepts and commands concerning addressing and routing also applies to ipv6. ip -6 addr, ip -6 route, ping -6. You should already have a "link local" (useless) ipv6 address associated with your enp9s0 interface that starts with (hex) fe80. Do 'ip -6 addr add' the same address (/64) but with fe80 replaced with fc80. Do ping -6 fc80::2e0:4cff:fe68:7620 (this is thincrust's ipv6) to verify that it worked. 2. Source Address Routing So far, the decision as to how to route a packet is made solely on the destination ip address of the packet. This is the norm, and is used by not only every router but also every end-host on the Internet. However, advanced routers can define more sophisticated routing policies. On linux it is also possible to decide how to route a packet based on its source ip address. Read chapter 4 of the "advanced routing howto" document to learn how to create additional routing policies via "ip rule". Create a new routing table, then route all packets coming from the smaller net 10.2.1.0/24 through 10.2.0.3. ******************* On your own after the lab *********************** Write down the steps you took to effect this, then reset your network connection to the original (hopefully without rebooting!). 2. Creating tunnels. You can attempt to create a gre or ssh tunnel between your "secret" server and some other machine externally, being aware that some networks will block gre traffic.