Lab4ModellingaRoutingProtocol

Lab 4, Modelling a Routing ProtocolObjectivesTo demonstrate simulation the OSPF and IGRP routing protocols showing the differences between a distance-vector and link state protocols and how they respond to a link failure and a link re-start. We will use the ICMP’s “ping” with the “trace route” option to show changes in routes during the simulations.Modelling the OSPF Routing ProtocolFor this lab we will use the routing scenarios provided with Opnet Modeler. Start Opnet and from the ‘File’ menu select ‘Open’ to open an existing project.From the list of projects find the ‘Routing’ project and open it.Now, so not to save your work over the existing example, save the project under the new name ‘Routing_Protocols’.Switch to the ‘OSPF’ scenario. In this setup the routers are configured to use the Open Shortest Path First routing protocol. The subnets contain networks of varying topologies each has 10 workstations running e-mail and http background traffic. The main topology looks like this.We are going to generate ping traffic from the Northberg subnet selecting the Eastber subnet as the target. This will allow us to see the route taken by the ping traffic across the backbone routers.We are going to fail and recover the link between backbone router 2 and backbone router4 as this is the link across which the traffic initially flows between these subnets.A probe in backbone router 4 and the router in Northbergs subnet will keep a track on the packets being dropped.Open the ‘Object palette’ and select the ‘utilities’ group.Place a ‘Failure recovery’ icon and a ‘IP Attribute Config’ icon on the workspace.The ‘failure Recovery’ node will control the failure and recovery of the link and the ‘IP Attribute Config’ will allow you to activate the ICMP ping record route option.Edit the attributes for the ‘IP Attribute Config’ and select ‘Edit’ on the ‘IP Ping Parameters’. ‘Edit’ the ‘Details’ and select ‘Enable’ for the ‘Record Route’ option. Click ‘Ok’ to close all the windows.Select the link between backbone routers 2 and 4 then ‘edit attributes’ and highlight its name, use ‘copy’ (Ctrl-C) to copy the links name to the clipboard.Now ‘Edit Attributes’ for the ‘Failure Recovery’ icon and ‘Edit’ the value for ‘Link Failure/Recovery specification’ attribute.Add 2 rows and ‘paste’ (Ctrl-V) the links name from the clipboard into the name field of each row.In the first row change the fail time to ‘500’ seconds. In the second row enter the recovery time of ‘1000’ seconds and change the ‘Status’ value to recover.In order to find out the IP address of the intended destination of the Ping- traffic, Eastber.PARAM, run a simulation with ‘IP Interface Addressing Mode’ set to ‘Auto-addressed/Export’ in the simulation options.When the simulation runs Opnet will generate a text file called ‘Routing_Protocols-OSPF-ip_addresses.gdf’. Locate this file in the ‘op_models’ directory on your network drive and open it.Using the ‘Find’ option from the ‘Search’ menu search for ‘Node Name: Enterprise Network. EASTBER.PARAM’ and copy the address to the right of the string (in this case 192.0.38.1).Return to Opnet Modeler and open the Nothberg subnet. ‘Edit Attributes’ for the router edit the value field for the ‘IP Ping Traffic’. And change the destination IP address fields to that retrived from the file.click ‘OK’ now change the values in the ‘Start time’ fields to 100, 400, 700 and 1000.Return to the main network and right click on an empty part of the workspace and select ‘Choose Individual Statistics’. Select the following statistics.Global Statistics -> OSPF->Traffic Sent (bits/sec)Node Statistics ->IP ->Traffic Dropped (packets/sec)Link Statistics -> point-to-point -> throughput (bits/sec) ->Link Statistics -> point-to-point -> throughput (bits/sec) <-Configure a simulation for 1500 seconds. Selecting 100 values per statistic and 100 values per seed. Change the ‘OSPF stop time’ to ‘1500’ seconds then run the simulation.Once the simulation ends view the results for:Global Statistics -> OSPF->Traffic Sent (bits/sec)Link Statistics -> point-to-point -> throughput (bits/sec) ->Link Statistics -> point-to-point -> throughput (bits/sec) <-The resultant graph will look as follows:The point at which the link fails is clearly visible from these graphs, you can see the point-to-point utilisation flat-line where the link is down. The OSPF traffic sent graph shows us that traffic is still being sent. There are bursts of traffic when the link fails and recovers.Now look at the results for traffic dropped by backbone router 4 and the router in the Northberg subnet.Object Statistics -> Enterprise Network -> BACKBONE ROUTER 4 -> IP -> Traffic Dropped (bits/second)Object Statistics -> Enterprise Network -> NORTHBERG -> ROUTER -> IP -> Traffic Dropped (bits/second)The graph will look like this:There is only 1 packet dropped. This is the ICMP ping sent at 10 seconds before the routers routing tables were established and no route is available.The simulation log stores the results for the ICMP ping record route. Open it by right clicking over an empty portion of the workspace and selecting the ‘Open Simulation Log’ option. There are 4 rows that are of interest to us. These are for the ICMP pings at 10, 400, 700 and 1200 seconds.The ping sent at 10 seconds has been dropped as the routers have not yet discovered the routes between them.The ping at 400 seconds, before the link fails, goes through the link between backbone routers 2 and 4.192.0.8.2 0.00000 Enterprise network.NORTHBERG.ROUTER192.0.7.1 0.01658 Enterprise network.BACKBONE ROUTER 2192.0.16.1 0.00007 Enterprise network.BACKBONE ROUTER 4192.0.38.1 0.01658 Enterprise network.EASTBER.ROUTER192.0.16.2 0.00002 Enterprise network.EASTBER.ROUTER192.0.7.2 0.01658 Enterprise network.BACKBONE ROUTER 4192.0.8.1 0.00007 Enterprise network.BACKBONE ROUTER 2192.0.8.2 0.01658 Enterprise network.NORTHBERG.ROUTERThe ping at 700 second once the link fails takes a different route through the backbone network. It goes from backbone router 2 through backbone router 3 to backbone router 4. 192.0.8.2 0.00000 Enterprise network.NORTHBERG.ROUTER192.0.6.1 0.01658 Enterprise network.BACKBONE ROUTER 2192.0.11.1 0.00010 Enterprise network.BACKBONE ROUTER 3192.0.16.1 0.00011 Enterprise network.BACKBONE ROUTER 4192.0.38.1 0.01658 Enterprise network.EASTBER.ROUTER192.0.16.2 0.00002 Enterprise network.EASTBER.ROUTER192.0.11.2 0.01658 Enterprise network.BACKBONE ROUTER 4192.0.6.2 0.00011 Enterprise network.BACKBONE ROUTER 3192.0.8.1 0.00010 Enterprise network.BACKBONE ROUTER 2192.0.8.2 0.01658 Enterprise network.NORTHBERG.ROUTERFinally at 1200 seconds when the link has recovered the ping takes the original route through the now restored link.192.0.8.2 0.00000 Enterprise network.NORTHBERG.ROUTER192.0.7.1 0.01658 Enterprise network.BACKBONE ROUTER 2192.0.16.1 0.00007 Enterprise network.BACKBONE ROUTER 4192.0.38.1 0.01658 Enterprise network.EASTBER.ROUTER192.0.16.2 0.00002 Enterprise network.EASTBER.ROUTER192.0.7.2 0.01658 Enterprise network.BACKBONE ROUTER 4192.0.8.1 0.00007 Enterprise network.BACKBONE ROUTER 2192.0.8.2 0.01658 Enterprise network.NORTHBERG.ROUTERModelling the IGRP Routing ProtocolDuplicate the scenario, naming the new scenario ‘IGRP’. The simplest way to change the routing protocol to IGRP is to open the ‘Configure Simulation’ window and locate the ‘IP Dynamic Routing Protocol’. Change its value to ‘IGRP’ Now set the ‘Sim Efficiancey’ attribute to ‘disabled’.Before running the simulation change the simulation results to include: Global Statistics -> IGRP -> Traffic Sent (bits/sec)Global Statistics -> IGRP -> Traffic Received (bits/sec)Now run the simulation. And display the results for:Global Statistics -> IGRP -> Traffic Sent (bits/sec)Global Statistics -> IGRP -> Traffic Received (bits/sec)Link Statistics -> point-to-point -> throughput (bits/sec) ->Link Statistics -> point-to-point -> throughput (bits/sec) <-From the throughput of the link we can see that after the link is recovered it takes a little longer for traffic to build up along the link. The IGRP routing protocol has struggled to react to the link failure and recovery as well as OSPF and the background HTTP traffic takes longer to start traversing the network successfully again.Again look at the packets dropped by backbone router 4 and the router in the Northberg subnet.Object Statistics -> Enterprise Network -> BACKBONE ROUTER 4 -> IP -> Traffic Dropped (bits/second)Object Statistics -> Enterprise Network -> NORTHBERG -> ROUTER -> IP -> Traffic Dropped (bits/second)With IGRP after 14 minutes traffic is being dropped by the Northberg router.Take a look at the simulation log to find out more, Note that:The ICMP ping at 720 seconds did not reach its destination and was dropped. This means that no routing updates for the failed link have been received.The ping packet at 1200 seconds successfully traverses the network through the recovered link.These results clearly show that the distance-vector routing protocol IGRP has a long propagation time when reaction to a failed link. The link-state routing protocol OSPF is by far superior under these circumstances.Extension WorkRepeat this experiment using some of the other routing protocols. EIGRP is a Cisco-protocol with very fast convergence. How do you think it will respond to the link failure and re-start?。