NET 270 Building Scaleable Networks Report by: Clint Abrams Lab Partner: Date Performed: 15 January 2013

3 Date Due: 22 January 2013

Overview: The purpose of this lab was to familiarize the student with the Routing Information Protocol versions 1 and 2. During the lab we were able to view debug information and Wireshark packet captures so that we could see the exchange of information from router to router and a detailed view of the errors causing RIP information not to be exchanged. Example lab sections follow Network Diagram and Topology Three routers were connected in a line from Router 1 to Router 2 to Router 3. A switch was connected between Router 1 and Router 2 and another between Router 2 and Router 3. This was done for the benefit of 1) being able to connect a Workstation computer into the same network created between the routers and 2) to be able to capture packets for analysis in Wireshark. Please see the network diagram below.

Section 1 Connection and Configuration In the first section RIP ver1 was configured on all routers with the following commands: Router 1 router rip network 10.254.0.0 network 172.31.1.0 Router 2 router rip network 10.1.0.0 network 172.31.1.0 Router 3 router rip network 10.1.0.0 network 10.1.4.0 Since RIP ver 1 is a classless routing protocol RIP automatically summarized all routes/networks at their classfull boundaries. 10.0.0.0 and 172.31.0.0. Excerpt from sh ip route Cicso3#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set R 172.31.0.0/16 [120/1] via 10.1.0.1, 00:00:14, FastEthernet0/0 10.0.0.0/24 is subnetted, 2 subnets C 10.1.0.0 is directly connected, FastEthernet0/0 C 10.1.4.0 is directly connected, Ethernet1/0 The RIP route 172.31.0.0 was learned on Cisco 3 router via Cisco 2. Notice network 10.254.0.0 was not learned because ver 1 does not support discontiguous networks. Summarization displayed in the output of sh ip rip database below Cicso3#sh ip rip database 10.0.0.0/8 auto-summary 10.1.0.0/24 directly connected, FastEthernet0/0 10.1.4.0/24 directly connected, Ethernet1/0 172.31.0.0/16 auto-summary 172.31.0.0/16 [1] via 10.1.0.1, 00:00:26, FastEthernet0/0 Also RIP ver 1 sends broadcast messages out with routing updates, see Wireshark capture below:

When debugging of RIP ver1 is enabled we see network information being exchanged, what interface sees the update, the ip address it was sent to, and the metric. Cicso3#debug ip rip RIP protocol debugging is on Cicso3# *Apr 20 16:52:10.427: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (10.1.0.2) *Apr 20 16:52:10.427: RIP: build update entries *Apr 20 16:52:10.427: subnet 10.1.4.0 metric 1 Cicso3# *Apr 20 16:52:32.315: RIP: received v1 update from 10.1.0.1 on FastEthernet0/0

*Apr 20 16:52:32.315: 172.31.0.0 in 1 hops Cicso3# *Apr 20 16:52:35.439: RIP: sending v1 update to 255.255.255.255 via Ethernet1/0 (10.1.4.1) *Apr 20 16:52:35.439: RIP: build update entries *Apr 20 16:52:35.439: subnet 10.1.0.0 metric 1 *Apr 20 16:52:35.439: network 172.31.0.0 metric 1 Section 2 Exploring Classless Routing Forwarding With current configurations a ping will not reach from WS4 to WS1. With examination of the routing table and the Wireshark captures above we see there is no route available to the 10.254.0.0 /24 network. Since 10.x.x.x is a Class A network, with classfull routing this makes a discontiguous network in our topology. Both routers 1 and 3 are advertising the 10.0.0.0 network. Enabling ip classless will not work in this scenario because RIP ver 1 is a classfull routing protocol. We can fix this problem using RIP by changing all routers to RIP ver 2. We are now able to ping WS1 from WS4. Section 3 RIP v2 and Optimizing for Scalability

From the Wireshark packet capture above, we see that RIP ver2 packets are no longer sent to broadcast address but are not sent to the RIP multicast adress of 224.0.0.9 and we can also see that the networks advertised are not summarized at their classful boundaries. Configuring a summary route on Router 2 allows the router to conserve bandwith and cpu usage by only sending out one network advertisement for the 10.1.0.0 /16 network instead of one for 10.1.0.0 /24 and 10.1.4.0 /24 networks. Please not the output from the command sh ip protocols below: Cisco2#show ip protocols Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 27 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip

Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain FastEthernet0/0 2 2 FastEthernet0/1 2 2 Automatic network summarization is not in effect Address Summarization: 10.1.0.0/16 for FastEthernet0/0 Maximum path: 4 Routing for Networks: 10.0.0.0 172.31.0.0 Routing Information Sources: Gateway Distance Last Update 10.1.0.2 120 00:00:07 172.31.1.2 120 00:00:01 Distance: (default is 120) Section 4 Authentication Normal RIP advertisements are sent unencrypted and unauthenticated. This can be a security risk as malicious users can intercept/alter these messages. Please note the following outputs to verify plain text (default) and MD5 authentications: Cicso3#debug ip rip RIP protocol debugging is on *Apr 20 17:18:18.479: RIP: received packet with text authentication 234 *Apr 20 17:18:18.479: RIP: received v2 update from 10.1.0.1 on FastEthernet0/0 *Apr 20 17:18:18.479: 10.254.0.0/24 via 0.0.0.0 in 2 hops *Apr 20 17:18:18.479: 172.31.1.0/24 via 0.0.0.0 in 1 hops Cicso3#sh ip protocols Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 24 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain FastEthernet0/0 2 2 private Ethernet1/0 2 2 private Automatic network summarization is in effect **output omitted**

As we can see by the Wireshark packet capture above the simple plain text password is very visible to prying eyes within the network. To defeat this we can configure MD5 authentication. Please note the following examples: RIP protocol debugging is on Cisco2(config-if)# *Jan 15 09:14:41.207: RIP: received packet with MD5 authentication *Jan 15 09:14:41.207: RIP: received v2 update from 172.31.1.2 on FastEthernet0/0 *Jan 15 09:14:41.207: 10.254.0.0/24 via 0.0.0.0 in 1 hops Cisco2#show ip proto Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 7 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain FastEthernet0/0 2 2 private FastEthernet0/1 2 2 private

The Wireshark packet capture above shows that this advertisement can be authenticated against the MD5 chain configured on the receiving router. Summary This lab went from basic set up / configuration of the RIP routing protocol. From debug outputs, routing tables, and packet captures we can see that RIP ver1 is a simple, not very scalable, classfull routing protocol, meaning a classless or subnetted network cannot be located on opposite sides of two routers. To defeat these problems, we introduced version 2, allowing discontiguous networks and less bandwidth by sending update packets to 224.0.0.9 multicast IP address instead of broadcasting advertisements. To increase security, we configured the interfaces for plain text or MD5 encrypted authentication. Doing this prevents RIP advertisements from being altered during transmission.