Here are the group assignments for lab

In this lab you will be configuring all interfaces on all four routers with the appropriate IP addresses. Then we will set up static routing. Then we will observe traffic flow on net0.

FUNCTION

1. Configure all the router interfaces (BR, R1, R2, R3) with appropriate IP addresses. Be sure to set the hostname (as appropriate) also.

2. Configure the BR and R2 and R3 such that only ssh access is allowed, and only from your groups network (10.XX.0.0/16) and the core station (10.91.0.254). To provide access security to a juniper router you will create firewall rules and apply them to the loopback interface. For now we will create a rule which will only allow ssh (tcp protocol 22) from 10.XX.0.0/16 and 10.91.0.254/32. We will create a "filter" in the firewall section. The filter will have three "terms". The filter and the terms have names that we specify (and try to make descriptive). The terms are processed in the order they are listed. Terms are each made up of two clauses, from and then. From is used to match while then is used to specify a action for the match.


	juniper@br> edit
	Entering configuration mode

	[edit]
	juniper@br# edit firewall 

	[edit firewall]
	juniper@br# edit filter ssh-allow 

	[edit firewall filter ssh-allow]
	juniper@br# edit term allow-ssh-from 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# set from source-address 10.XX.0.0/16 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# set from source-address 10.91.0.254 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# set from protocol tcp 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# set from destination-port 22 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# set then accept 

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br# show 
	from {
	    source-address {
		10.XX.0.0/16;
		10.91.0.254/32;
	    }
	    protocol tcp;
	    destination-port ssh;
	}
	then accept;

	[edit firewall filter ssh-allow term allow-ssh-from]
	juniper@br#  up 

	[edit firewall filter ssh-allow]
	juniper@br# edit term no-other-ssh 

	[edit firewall filter ssh-allow term no-other-ssh]
	juniper@br# set from protocol tcp destination-port ssh 

	[edit firewall filter ssh-allow term no-other-ssh]
	juniper@br# set then discard 

	[edit firewall filter ssh-allow term no-other-ssh]
	juniper@br# show 
	from {
	    protocol tcp;
	    destination-port ssh;
	}
	then {
	    discard;
	}

	[edit firewall filter ssh-allow term no-other-ssh]
	juniper@br# up 

	[edit firewall filter ssh-allow]
	juniper@br# edit term accept-all-other 

	[edit firewall filter ssh-allow term accept-all-other]
	juniper@br# set then accept 

	[edit firewall filter ssh-allow term accept-all-other]
	juniper@br# up 

	[edit firewall filter ssh-allow]
	juniper@br# show 
	term allow-ssh-from {
	    from {
		source-address {
		    10.XX.0.0/16;
		    10.91.0.254/32;
		}
		protocol tcp;
		destination-port ssh;
	    }
	    then accept;
	}
	term no-other-ssh {
	    from {
		protocol tcp;
		destination-port ssh;
	    }
	    then {
		discard;
	    }
	}
	term accept-all-other {
	    then accept;
	}

	[edit firewall filter ssh-allow]
	juniper@br# commit confirmed 3 
	commit confirmed will be automatically rolled back in 3 minutes unless confirmed
	commit complete

	[edit firewall filter ssh-allow]
	juniper@br# commit 
	commit complete

	[edit firewall filter ssh-allow]
	juniper@br# 

Now we apply the filter to packets inbound on the loopback device.

	[edit firewall filter ssh-allow]
	juniper@br# up 

	[edit firewall]
	juniper@br# up 

	[edit]
	juniper@br#  edit interfaces 

	[edit interfaces]
	juniper@br# edit lo0 

	[edit interfaces lo0]
	juniper@br# set unit 0 family inet filter input ssh-allow 

	[edit interfaces lo0]
	juniper@br# show 
	description Loopback;
	unit 0 {
	    description "Loopback interface";
	    family inet {
		filter {
		    input ssh-allow;
		}
		address 127.0.0.1/32;
	    }
	}

	[edit interfaces lo0]
	juniper@br# commit confirmed 3 
	commit confirmed will be automatically rolled back in 3 minutes unless confirmed
	commit complete

	[edit interfaces lo0]
	juniper@br# commit and-quit 
	commit complete
	Exiting configuration mode

	juniper@br>

We also want to limit who can access the two cisco routers. We want to make sure that all access *must* be through the ssh protocol and that only certain IP addresses can make connections. We want to allow access from within our networks /16 (10.XX.0.0/16) and from the host 10.91.0.254. To do this we will configure a standard access list and apply it to the line vty section.

Note.. The IOS system on cisco routers uses a "wildcard" bit system to specify ranges within access lists. This is a dotted quad, like a netmask but different. A netmask uses a bit of one to specify a network and 0 to specify host. A wildcard bit uses a 1 bit to specify a bit that can be either 1 or 0, while a 0 indicated a bit that can not be changed. This causes wildcard bit masks to be the binary inverse of a corresponding netmask. A netmask of /24 would be represented in dotted quad as 255.255.255.0, but in wildcard bitmask as 0.0.0.255.


	!
	! here we create the access list 
	! first comes a sequence number, then permit/deny
	! then an address, then a wildcard bitmap
	! The deny any any at the end is the default for 
	! ciscos, but we put it in to  prevent any confusion..
	!
	r2(config)#ip access-list standard 1
	r2(config-std-nacl)#10 permit 10.91.0.254 0.0.0.0
	r2(config-std-nacl)#20 permit 10.XX.0.0 0.0.255.255
	r2(config-std-nacl)#9999 deny any
	r2(config-std-nacl)#ex

	!
	! Now apply to the vty lines. Also prefer and require ssh
	!
	r2(config)#line vty 0 4
	r2(config-line)#transport preferred ssh
	r2(config-line)#transport input ssh
	r2(config-line)#access-class 1 in
	r2(config-line)#exit
	r2(config)#

3. Configure static routing on all routers to effect full connectivity of the entire network. Each router will need to have at least a default route pointing all traffic to the BR router, and a few other routes. Feel free to use aggregate routes, and asymmetric routing is permitted (but must be documented, and must not violate the traffic engineering specified below).

You will set up routing such that all traffic between BR and net1/2 go through R2 (and in the case of net1 and net2 use the point to point link 10.XX.1.192/30 from R2 to R1). Also all traffic from BR to net3 will go through R3. From R1 all traffic to net0 should go through R2. All traffic from R1 to net3 will go through R3. All traffic from R1 to the default route will go from R1 to R2 to BR. You need to make sure that all routers can reach all networks (including the p2p networks). If the path for a network is not specified, then you can choose any appropriate next hop as needed.

The BR will also need a default route that will point to 10.91.0.254.

4. Host ws0 (10.XX.0.20) has a static route for all 10.0.0.0/8 networks pointing to 10.XX.0.1 (BR on net0) This is very similar to a default route. The real default route points to the real Internet, (connected to ws0 eth1) but this static route effects a default route for all the "test" nets.

Now we will perform a ping from ws0 to 10.XX.2.1. Set up tcpdump to monitor all ICMP and arp traffic on net 10.XX.0.0/24. Immediately before the ping you will want to execute the following commands (on ws0) to clear the ICMP redirect and ARP caches.


	arp -d 10.XX.0.1					(clear arp cache entries)
	arp -d 10.XX.0.2					(clear arp cache entries)
	arp -d 10.XX.0.3					(clear arp cache entries)
	echo 1 > /proc/sys/net/ipv4/route/flush			(clear ICMP redirect cache)

	tcpdump -i eth0 -s 0 -w /tmp/lab2.pcap arp or icmp &

	the above will start the tcpdump and save the data to the file /tmp/lab2.pcap
	it will run in the background because of the & at the end of the line. 
        Hit return a couple times to get the prompt back.

	then do the ping. I would recommend using the -c option and
	limiting it to 5 pings to keep the amount of data you need to analyze 
	down to a minimum.

	ping -c 5 10.XX.2.1

	then bring the tcpdump into the foreground

	fg

	and hit ctrl-c to stop it

5. Configure all the routers so that they boot with all interfaces and routing correctly configured. This means MAKE SURE you have done a

copy running-config startup-config
on r1/r2/r3.

The groups will need to demonstrate correct booting of routers (BR, R1, R2, R3) in the lab. The configurations should be set up and the networks fully functional by Midnight of the due date. Function will be 20 points All members of each group will receive the same "functionality" grade.

LAB REPORT

Configuration files: Each lab report should include the complete configurations for BR, R1, R2, and R3. In each case you will need to copy the configurations off from the router to ws0, then from ws0 to your ocelot.aul.fiu.edu account to include in the report. See the notes from class 1. This data can be collected as a group. (4 points)

Question 1: The lab report should also include a section showing what you would enter on R2 to configure a eth1/3 interface that also connects to *existing network* 10.XX.2.0/24 using 10.XX.2.3 as IP. (5 points)

Question 2: The lab report should also include a section showing what you would enter on BR to configure a fictional fxp3 interface that connects to new fictional network 128.227.128.128/25 using any appropriate address for that network. (5 points)

Question 3: The lab report should also include a section showing what you would enter on R1 to configure a fictional eth4 interface that connects to new fictional network 131.94.100.0/22. Use the *last* available address on that network. (5 points)

Wireshark capture: When I ask for a captured packet, I want to see the full ascii wireshark details of the packet in text in the report. Not the pcap version and not the summary version. See here for an example of the correct output of a ICMP echo reply You can do this by "marking" the packet. (Edit-Mark packet) then using the "File->Print" with "output to a file" and "marked packets only" with "packet details" checked with "all expanded" checked.

Include in report a full wireshark packet output of the ICMP redirect seen in step 4. (1 point)

Question 4: A detailed narrative describing what is going on in sequence for each arp, icmp echo request/reply, or icmp redirect packet in step 4. Narrative should be in this format. Remember that since we are monitoring a switched port, you will only see traffic that is broadcast or addresses to ws0 eth0 mac address. You will need to think about what *should* happen and include details on packets you might not have seen. (10 points)

Remember, all reports have to turned in on paper, or in PDF via email. MS word, open office or even plain text formats *WILL NOT* be accepted.