Network Simulation With OPNET Modeler

Routing protocol is the key for the quality of modern communication network. EIGRP, OSPF and RIP are the dynamic routing protocols being used in the practical networks to propagate network topology information to the neighboring routers. There have been a large number of static and dynamic routing protocols available but choice of the right protocol for routing is dependent on many parameters critical being network convergence time, scalability, memory and CPU requirements, security and bandwidth requirement etc.
This Assignment uses OPNET simulation tool to analyze the performance of RIP and EIGRP commonly used in IP network.
Initially We have Following Network.

By Examining the Network we figure out that Red line indicating the Data Rate of 44.736 Mbps between network components and only Network connection between London Office and Portsmouth office has Data Rate of 64 Kbps.
The Traffic Flow between London Office and Bristol_corporate is IP_Traffic Flow having following chracteristics   

RIP Protocol Over Netwrok:
Routing Information Protocol (RIP) is a distance vector dynamic routing protocol that employs the hop count as a routing metric. RIP is implemented on top of the User Datagram Protocol (UDP) as its transport protocol. It is assigned the reserved port number 520. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of permitted hops is 15. Hence a hop count of 16 is considered an infinite distance. This hop number limits the size of networks that RIP may support. RIP selects paths that have the smallest hop counts. However, the path may be the slowest in the network. RIP is simple and efficient in small networks.
First we have to run RIP routing protocol in the network for a simulation period of 600 seconds with selecting following criteria

Path Selection
Time Taken for routing convergence
Protocol Overhead

Path Selection
For path selection we get following result with RIP protocol

The IP traffic Flow is from London to Bristol Corporate and due to Low Data rate between London to Portsmouth path as compare to London to Oxford path the RIP protocol follows maximum the low Data rate path which is London Office to Portsmouth, and graph displays data throughput for the links London to Portsmouth and Portsmouth to Bristol.
Time Taken for routing convergence
RIP is distance vector routing protocols, announces its routes in an unsynchronized and unacknowledged manner. This can lead to convergence problems. The graph is showing the time taken for routing convergence of RIP. The convergence time is high 6.975 sec that’s mean routers are finding it difficult to exchange state information.

Protocol Overhead

RIP is a “distance vector” based protocol selects the best routing path based on a distance metric
(the distance) and an interface (the vector) , RIP protocols evaluate the best path based on
distance, which can be measured in terms of hops or a combination of metrics calculated to represent a distance value. In this exercise RIP selects London to Portsmouth link and maximum utilization occurs .
The utilisation and convergence data suggests there is some queuing and blocking on the link. For example, the utilisation for the London to Portsmouth link is high i.e 84.629 therefore suggesting the link is suffering from over-utilisation.

In the point to point queuing graph , the London to Portsmouth Link contains queuing delay on average 3.6032 sec , therefore suggesting there is traffic blocking or queuing on the link.
The link between London to Portsmouth uses a DS0 (Blue) cable with a data rate of 64Kbps compared to the other links in the network that use a DS3 cable (Red) with a data rate of 44.736Mbps; therefore the combination of the over-utilisation of the London to Portsmouth link with the low data rate cable (DS0) has caused traffic queuing or blocking to occur.
————————————-Excersise -2 ————————————-
EIGRP Protocol Over Netwrok:
Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco proprietary routing protocol. It is based on a new route calculation algorithm called the Diffusing Update Algorithm (DUAL). It has features of both distance vector and link state protocols. EIGRP metrics are based on reliability, MTU, delay, load, and bandwidth. Delay and bandwidth are the
basic parameters for calculating metrics

First we have to run EIGRP routing protocol in the network for a simulation period of 600 seconds with selecting following criteria

Path Selection
Time Taken for routing convergence
Protocol Overhead

Path Selection
For path selection we get following result with EIGRP protocol

The IP traffic Flow is from London to Bristol Corporate but as contrast with RIP which selected low data rate path, EIGRP select the path from London to Oxford , Oxford to Birmingham , and Birmingham to Bristol path to achieve the traffic Flow.
Time Taken for routing convergence
EIGRP is more efficient as compared to RIP , Graphs are showing the convergence duration very fast 0.0074427 Sec as Compared to RIP which was 6.975 Sec with same scenario.

Protocol Overhead

As Compared to RIP , No over utilisation occurs in EIGRP , Utilisation graphs shown above clearly that the utilisation distributed evenly over path with value for the London to Oxford is 5.5606 , Oxford to Birmingham is 5.5783 and Birmingham to Bristol is 5.5662
EIGRP performs better in terms of network convergence, routing traffic, and Ethernet delay.
EIGRP has the characteristics of both distance vector and link state protocols, has improved network convergence, reduced routing protocol traffic, and less CPU and RAM utilization compared to RIP protocol.
EIGRP has very low usage of network resources during normal operation since only hello packets are transmitted. When a routing table changes, its convergence time is short and it reduces bandwidth utilization
————————————-Excersise -3 ————————————-
We introduced a link Failure Scenario between Bristol corporate and Porstmouth Office after 100 Seconds and its recovery at 200 Seconds and run the RIP and EIGRP protocol over network.
Following are our Observations with side by side comparison of RIP and EIGRP



In the RIP protocol the link failure after 100 sec prevented the traffic to flow; therefore when the link recovered after 200 sec a huge amount of traffic was bottlenecked on the link causing the utilisation of the London to Portsmouth to suddenly increase. Also it can be observed that during the time of the failure the RIP protocol began to reroute the traffic over the London to Oxford, Oxford to Birmingham, and Birmingham to Bristol links before the link recovered the graph is showing this small utilization on the links.
In the EIGRP Protocol, link failure event did not affect the utilisation of the EIGRP protocol because the link was not used in the routing path; The EIGRP did not use the link Portsmouth to Bristol in its path selection, so the performance of the network will be barely affected by the failure ; hence the utilisation values doesn’t change

In RIP The Convergence Duration becomes much higher as compare to old scenario before Failure , it was 6.975 before and 19.409 now , this is because routers updates their routing tables when failure occurred and recovered it takes more time period ,
In Contrast with EIGRP protocol the Convergence Duration becomes 0.012273 , much less than RIP this is because EIGRP only update the link failure routing table not the whole network , So EIGRP provides much efficient and faster way to achieve convergence.

Time Delay of Protocol
More IP packets drops in RIP as compared to EIGRP because of the failure in link of the path which RIP follows , and as contrast less IP packets drops in EIGRP because it does not follow the path of failure link.

————————————-Excersise -4 ————————————-
Consider the given Network merging with another network, Picture shown below the merging Network

The IP Traffic flows sending traffic from London Office to three destination North-wales Plant, Birmingham Plant and Oxford Office. We defined IP Traffic according to given table.
A New Link DS_1 ( Black Line in Picture ) introduced which connects North-wales Plant to London Office via The New Manchester Office.
We runs RIP as routing Protocol which gives us Following observations:


From Graph it is clearly showing that utilisation is high for London office to Manchester office and Manchester Office to North Wales
Both are approximately 97 % utilisation which is overutilization and cause serious problems to the network.
For London to oxford office and Oxford to Birmingham Plant the utilisation is nearly 13% and 6% this is because of link using high data rate cable DS3 where we get the low utilisation and low data rate comparatively where we get lower data rate cable.
DS1 cable has data rate of 1.5Mbps which DS3 has 44.736 Mbps
With this Observation , we come to know that one possible solution is using EIGRP protocol , as EIGRP protocol solve the over utilisation problem from our network.
Lets see by running the EIGRP protocols and compare the result of it with RIP



The EIGRP protocol solves the Over utilization problem we have faced in RIP protocol and the resultant graph and comparison is showing this clearly with evenly distributed utilization over selected path by EIGRP.
CONCLUSIONS : It can be seen that EIGRP compared to RIP performs better in terms of network convergence activity and Routing protocol traffic. EIGRP has the characteristics of both distance vector and link state protocols, has improved network convergence, reduced routing protocol traffic, and less CPU and RAM utilization compared to RIP
Performance Analysis of RIP, EIGRP, and OSPF using OPNET By Don Xu and Ljiljana Trajković
Dynamic Routing Protocol Implementation Decision between EIGRP, OSPF and RIP Based on Technical Background Using OPNET Modeller By Thornier, S.G.

Modelling and simulation using opnet modeller 14.5

4.1 Overview
The aim of this chapter is to illustrate the modelling and simulation, using OPNET Modeller 14.5-Education version for the autonomic wireless network management. In addition, it will explain what kind of modifications and suppositions were necessary in order to achieve the autonomic self-healing mechanism, including agents’ architecture and description.
4.2 Autonomic Management Agents
This section will illustrate the modelling and simulation, using OPNET Modeller 14.5-Education version, of a community of autonomic management agents that provide network fault analysis for a group of base stations. The main objective of these intelligent agents will be to bring together process information in order to detect failures when base stations exchange information between them, and the creation of a high obtainable wireless access network. Analysing network failures is relatively difficult since these problems may differ from one network system to another and could depend on network dynamics, i.e., the type of network information to be exchanged and the traffic characteristics associated with that information. In addition, the pattern of failures could vary quickly as the network operates and reconfigures around a failed device

Get Help With Your Essay
If you need assistance with writing your essay, our professional essay writing service is here to help!
Essay Writing Service

As OPNET Modeller 14.5-Education version does not have an autonomous process ready for simulation usage, the existing code had to be adapted to allow autonomic behaviour. The use of two different autonomic agents was required in order to provide self-healing network diagnosis and facilities. In this report, OPNET coding modifications will be called Agents and two different types are mentioned and applied to the access points.
Testing Agents will supply data simplicity and monitor capabilities to Node Agents whereas Node Agents will periodically check the information that Testing Agents bring together and use it as a medium of failure detection within the wireless access network. In addition, a Testing Agent will be able to supervise and provide data regarding information exchanged among access points. Node agents use data obtained by the Testing Agents as a method of node analysis
Various Testing Agents may be found on a single wireless client. A Testing Agent can be situated on a host device since it does not have to deal with data acquisition and information simplicity. In contrast, Node Agents will be located on a base station. Various Testing Agents may be found on a single wireless client
4.2.1 Additions and Model Modifications
OPNET Modeller was used in order to determine concept achievability of the proposed model. The concept of Autonomic Mobile Wireless Networks is illustrated by using a community of wireless base stations which allow autonomous healing of interrupted paths
The OPNET simulation showed in this report will contain two Node Agents and two Testing Agents which take the part of a group of autonomic base stations. The new OPNET topology required the creation of ten nodes in order to characterize every autonomic agent and all the modifications were made to accomplish the needs of both agents. The autonomic behaviour was obtained through modifications to the wlan_server_adv and ip_arp_v4 OPNET process models, where code changes were made in order to achieve the desired behaviour.
Figure 4.0: OPNET ip_arp_v4 process model.
4.2.2 Testing Agent (TA) and Node Agent (NA) Description
Each Testing Agent belongs respectively with a Node Agent as a single component of a particular node in the OPNET simulation. As mentioned in section 3.3, each base station is aware of its next-door stations at all times. A Testing agent (TA_1) is designed to watch and detect alterations regarding other base stations. In the event of any modification of the network, TA_1 will notify Node Agent (NA_1) by using a UDP message. UDP presents lack of reliability so consequently the Testing agent TA_1 cannot assure successful message transmission. However, this lack of reliability will be useful for simulation purposes
After receiving information from TA_1, a Node Agent (NA_1) will inform other stations about changes in zone, and file updating may take place. When a NA_1 observes that information sent has not arrived at its destination within a particular period of time, the agent alerts its neighbours that a probable node malfunction has occurred. This time depends on certain attributes fixed for a particular mobile user.
Scalability of the network will be achieved with the use of a second pair of agents. Agent TA_2 then has the job of monitoring path request messages sent and received by other stations. Information regarding path request is detected by TA_2, including the time when the path request was generated and the destination of this demand.
Changes to the mobility architecture were necessary including ARP and IP alterations. The idea was to alter some settings in order to evaluate and compare the destination address with the address of the device where specific information was sent. The destination address must belong to a registered wireless client and the intelligent agents will check correct transmission of it
IP alterations were made changing the moip_core to allow stations to be able to forward information packets to its neighbours, modify the IP routing mode and help each station choosing the better route available. The moip_core has a list that could be dynamically regulated as the base stations travel between networks
The UDP is used as a transport protocol and the managing, mobility and registration information is handled by the process shown in the figure below.
Figure 4.1: OPNET moip_reg process model
The moip_reg process allows base stations to manage and update mobility information regarding next-door stations. When exchanging information among stations, all the agents will monitor and process each request and they will aim to find failures during the registration process. If the registration communication was successful, there is an identification value that is compared with a mobility list and the correctly matched among them will mean no error has occurred during the registration procedure
Updated messages must be sent when agents have no information regarding the mobile station due to updating failures. In fact, agents need acknowledgments in order to be sure that the communication between stations is happening perfectly. If an agent does not receive the updating message, it will not be able to monitor base stations and all the information exchanged among agents will be lost. Therefore, all the updates and acknowledgments will be verified within an identification field contained by the moip_reg. If they are equivalent, the update will be set as confirmed and the exchange of information will be free of failures.
Figure 4.2: OPNET agent node structure
Figure 4.2 shows a plain representation of agent node structure and distribution. In addition, OPNET Modeller allows us to present the node model which was modified in order to provide autonomic behaviour to a set of autonomic base stations within a self-managed wireless access network. The wireless connectivity is achievable through the use of IEEE802.11b interfaces, permitting roaming among networks. This type of interface could be improved by adding an extra communication module between the radio transceiver and the wlan_mac system. This process allows a base station to simulate the effect of completely losing connection among devices and at the same time avoiding unnecessarily queues of packets
4.3 Network Model
Three different network configurations were constructed to simulate and identify autonomic characteristics, and agent distribution was arbitrarily decided in order to improve the simulation. The Testing agent (TA_1) was applied to a single base station; another station was selected to make use of Testing Agent (TA_2) and Node Agent (NA_1) while Node Agent (NA_2) was modified to operate in all base stations
4.3.1 Design of Wireless Network Infrastructure
The next steps were followed in order to design a wireless infrastructure in OPNET:

Open the OPNET program and select New Project and then press OK.
Give the project and the scenario a name.
Select create empty scenario and press next.
Network space was chosen as campus and specific size was selected as: X-span and Y-span 10 kilometres respectively.
The Object Palette Tree will open which illustrates the various WLAN devices as follows.

The file Node Models situated in the object palette contains the item wireless-lan-adv which encloses all the different network devices used in the wireless network presented in this report
All nodes were modified by using the function configuration Application Config and Advance Edit Attributes option.
In addition, the following wireless parameters were customized as stated in the figure 4.4:

Physical characteristics
Data Rate (bps)
Transmit Power (W)
AP Beacon Interval (sec)
Packet Reception-Power Threshold (bytes)

The wireless access network contains ten base stations (Figure 4.5) which are connected via point to point duplex links (ppp_adv). Each base station has at least two interfaces; one interface to provide connectivity among wireless mobile devices and another wired interface for uplink communication.
The network configuration showed above was created in order to simulate and analyse the wireless system when it includes nodes (Base Stations) on the exterior sector of the network and no more than two neighbour stations close to it. Therefore, these stations will only have a maximum of two paths to communicate their next-door devices. On the other hand, the rest of base stations will be surrounded by more stations and more possible routes.
Figure 4.6 shows the second configuration. There are various potential routes on which base stations and mobile devices may exchange information among them. As a result, the agent’s performance is going to be probed by selecting the best path and being able to repair route problems.
The third model illustrated in the Figure 4.7 offers a more narrowly linked network configuration. The number of neighbours for every node will increase and the communication between Node Agents and Testing Agents will improve due to a decrement in the number of paths required for Testing Agent information to meet the suitable Node Agent. Therefore, a superior self-healing performance will be expected using this configuration.
4.4 Verification of Agent’s self-healing process upon base station malfunction
To experiment the right operation of the agents, different simulations were made in every network model. The main purpose is to test agent reliability and its competence when providing an intelligent self-healing course of action. Consequently, the base stations were programmed to reproduce a failure and the action of agents would eventually lead us to simulate an autonomic behaviour.
In order to obtain a more understandable vision of the self-healing performance, a reduced network configuration was simulated (Figure 4.8). Exchange of information among nodes may take different paths until data arrives at its final destination. In the event that a particular base station fails, the permanent monitoring service of the Node Agents will detect the malfunction, and then the base station’s self-healing method will autonomously locate another route allowing intelligent diagnosing and repairing
OPNET code modifications provide one method of simulating a malfunction in the base station. The most important features required for this process were the use of an acknowledged mechanism and the understanding of the range capacity of base stations. These characteristics were required to allow mobile devices to recognize when a failure takes place in a base station and stop transmitting and routing traffic, in order to start self-healing and path recovery
4.5 Self-Healing and Route Discovery
The new route discovery was obtained through modifications to the wlan_server_adv and ip_arp_v4 OPNET process model, where code changes were made in order to achieve the desired autonomic behaviour. In a wireless access network, if the base station and mobile nodes are within transmission range of each other, an ARP request can be use in order to find a new route to the target mobile node. The Internet’s Address Resolution Protocol dynamically translates IP addresses to its MAC level address. Full OPNET source code is given in Appendix – Source Code page 70
//Route failure was created by denying connection service for a given destination address. The program looks into ARP table entries to find an entry for the destination IP address. Because the IP address given does not match in the ARP table the program returns a FAILURE ROUTE situation. On the other hand, in case that a matching entry was found SUCCESS connection will take place.
static Compcode
arp_cache_entry_find (IpT_Address dest_ip_addr, int* index_ptr)
Int table_size;
//Find the entry in the ARP cache for a given destination IP address.
table_size = op_prg_list_size (arp_cache_lptr);
for (i = 0; i {
entry_ptr = (IpT_Arp_Entry *) op_prg_list_access (arp_cache_lptr, i);
//Match the to-be-resolved destination IP address with the entry’s IP address
if (ip_address_equal (dest_ip_addr, entry_ptr->ip_addr) == OPC_TRUE)
*index_ptr = i;
When a new route is discovered (SUCCESS connection case), the information needs to be sent to an explicit destination (Mobile node) as specified in the “Destination Address” attribute. If the destination address specified is correct it generates a destination and forward the appl_packet to the MAC layer with that information.
if (destination_address == OMSC_AA_AUTO_ASSIGN)
curr_dest_addr = OMSC_AA_AUTO_ASSIGN;
oms_aa_dest_addr_get_core (oms_aa_handle, &integer_mac_address, (int) mac_address);
curr_dest_addr = integer_mac_address;
//Destination Address” attribute.
curr_dest_addr = destination_address;
// Set this information in the interface control / information to be sent to the MAC layer
op_ici_attr_set_int64 (wlan_mac_req_iciptr, “dest_addr”, curr_dest_addr);
// Install the control information and send it to the MAC layer
op_ici_install (wlan_mac_req_iciptr);
op_pk_send (pkptr, outstrm_to_mac);
send_paket = op_ici_create_fmt (“appl_packet”);
sendID = (SPkt *) op_prg_mem_alloc ( sizeof (SPkt) );
In order to make the code modifications a simple as possible, the new path discovery was made through a simple Request-Response communication between base station and mobile node. Transmission of selected configuration parameters from the base station to the mobile node is possible by the creation of the autonomic agents and their interaction. The agent’s configuration is also executed in the OPNET Modeller Simulation by the use of the Node Editor described in the Figure 4.9.