Network Capacity Planning OPNET tools practice evaluation

Transcription

1 Network Capacity Planning OPNET tools practice evaluation Irene Merayo Pastor Enginyeria i Arquitectura La Salle, Universitat Ramon Llull, Catalonia, EUROPE Paseo Bonanova, 8, Barcelona E Mail: st11183@salleurl.edu ABSTRACT Nowadays companies are more dependent on communications as a basic tool for their success. This is why the companies must have a previous knowledge about which are the incidences and problematics new applications can take on their communications. INTRODUCTION In the area of networks and communications analysis tools, OPNET offers an extensive range of products, where we can find specific modules that will help us to analyze the problems a company can find in relation to its net. The modules we are referring to are ACE, Flow Analysis and NetDoctor. ACE permits the characterization of an application using analysis tools, which have been created to find and differentiate the delays produced by networks and applications. ACE will help us to find network design errors and improve application characteristics to reduce the impact this can take on the network and obtain an optimum efficiency. Also, it has been mentioned Flow Analysis which permits analyzing different types of networks, such as IP, ATM networks and commuted circuits. It will be used to diagnose actual network problems or as an aid to predict future performance of a net. We can also study the effects that some characteristics have on the net performance. These characteristics can be: Volume of traffic Traffic type Equipment failure Device configuration Finally, NetDoctor module manages network integrity and security. Some of these tasks are: Configuration problems identification. Security policies violation detection. Network inefficiencies These tasks are the reason which makes NetDoctor very useful. Due to the extensive volume of configuration information a network supports, NetDoctor becomes an essential tool to find out many types of problems.

2 OBJECTIVES The aim of this project is to analyze on OPNET tools both performance and efficiency. First, we must learn how and what is necessary to make a simulation. Once we have enough knowledge to simulate a network we can continue and study the tools we want to evaluate. Before realizing any test for evaluating the tools, we must study and learn all the characteristics each tool offers and how they are applied. OPNET MODULES ACE The performance of network applications depends on interactions between servers, networks and applications. IT organizations need a detailed and quantitative vision of these interactions to solve and expand applications efficiently. Indeed, ACE is the OPNET tool which will permit us to characterize an application, and analyze it to find out the impact this will have on a specific environment. The performance of ACE can be divided in the following steps: It permits capturing, filtering and synchronizing application traces of multiple network segments. It graphically visualizes the results, in the application and the network layer. It diagnoses problems automatically with AppDoctor. It validates if the obtained results are the expected ones. Fig. 1 Different ACE analysis This capturing characteristic makes ACE more useful in capturing than typical programs used to do it. ACE offers the possibility of capturing traces from different places, controlling the captures from an only device (Capture Manager). It can be done using both capture Agents and Manager. Another characteristic of the ACE module is that you can also import captures from other programs to Opnet, for example, we will be able to make captures onto the network with the Sniffer Pro to lately import them to Opnet using ACE tool. FLOW ANALYSIS OPNET s Flow Analysis module empowers planning and engineering groups to design robust IP and ATM networks. With Flow Analysis, you can view the effects of traffic volume, traffic types, equipment failure, or device configuration on the operation of the network. The failure analysis may be a very interesting characteristic to previously know the impact a device failure can cause on network performance. This possibility helps administrator to apply changes on the network to decrease the impact that failure could have.

3 Fig. 2 Failure analysis We use the Flow Analysis to: Visualize the route taken by each virtual circuit or traffic flow. Model multiple failure scenarios quickly and easily. Using this option you can prove the tolerance of the network and the QoS it offers. Automatically identify bottlenecks in ATM networks. Calculate end to end delays for IP traffic flux, including propagations, transmission and queuing. In this case the tool will be analyzed using IP mode. NETDOCTOR Studies show that configuration errors are the major source of network downtime, degraded performance and gaps in network security. Maintaining network integrity and security is essential to guarantee the QoS and decrease failure risks. The problem is that the number and diversity of network devices makes extremely difficult to identify configuration problems. Here is where NetDoctor module takes importance and utility. NetDoctor is a tool that basically is used to automatically identify device misconfigurations, policy violations and inefficiencies. Moreover, you obtain significant benefits by integrating this tool into configuration and management, identifying problems that could damage in the future the network performance, assisting changes and administration configuration processes, checking policy security application It is important to remember that before executing any analysis with NetDoctor you must simulate whatever you want to analyze with Flow Analysis or DES. In this case, the simulation will be done with Flow Analysis because it is another module being studied. TOOLS APPLICATION This section will discuss if the benefits that the previous modules offers, really contribute to network and application analysis. Before executing any analysis on the mentioned modules, the following steps must be done: Studying OPNET general performance. Studying each module and their benefits. Learning to configure simulated and physics implementations. Once the previous studies have been completed, you are able to analyze the OPNET modules using a simulated and physical network. The network used in

4 this case is the network on the next figure. Fig. 3 Analyzed network ACE ANALYSIS Network shown in figure 4 has been physically configured with a 56k Serial connection. To capture all the traffic on the network and to have the possibility of executing PathProve on different existing paths, Capture Agents have been distributed as seen in the following figure: Fig. 4 CaptureAgents and Manager distribution The traffic captured is only an HTTP server access done from machines and to HTTP server ( ), and a ping between the previous hosts. The reason of this ping is to make ACE Manager able to auto synchronize frames captured from the different agents. Once having capture files, the following step is importing them. In the importing phase is where I find the first inconsistency. When it has to be specified the Tier Locations, the machines that are agents appear with the tier location in Local to site specified. Example: Tier Auto detected Local to Site Really, the tier is the capturing machine, so the tier location must be in the option Capturing Machine al Site, but the problem is that if a machine is auto detected you can not change its location. The bandwidth and latency are the parameters that have to be configured both in segments and between tier locations, the problem is that you can not use the segment parameters results to configure bandwidth/latency between locations, because their definitions differ a bit. According to the latency definition in the importing process, it is one half the total round trip (ping) time, but in this process (ping) take place other delays such as processing delay (of destination machine), congestion delay, Using this way of analyzing latency, we will be ignoring part of other delays on ACE analyzing, because they are included in latency instead of their respective delays. After importing the traffic, the next step is analyzing it. In this step there seems to be some inconsistencies. For example, on AppDoctor diagnosis of the traffic explained appears many Bottlenecks and potential bottlenecks as seen in figure 5. Some of this bottlenecks are a problem, there is a Protocol Overhead bottleneck

5 between and hosts which seems to have no explanation, because the only traffic between this devices is a simple ping. After various tests it can be seen that AppDoctor activate the Protocol Overhead bottleneck between two machines if the percentage of short messages is big, although traffic are ping messages. Another bottleneck is the Network Effects of Chattiness one. It is found between the address and hosts. The only reason of having this effect is that ACE interprets the inexistent path between these devices as a delay. Finally, in QuickPredict analysis, the response time is measured from the time it sends the first applicationpayload packet to the time it receives the last one. This method to calculate the response time makes the results to be dependent on the application speed. Although the latency and bandwidth were null and infinite respectively, there will be a minimum response time (not null) because it depends on the time the application takes to send the messages. NETDOCTOR ANALYSIS As it has said in previous sections, NetDoctor is a tool that basically is used to automatically identify: - Device misconfigurations - Policy violations - Inefficiencies These tools are going to be analized, applying them to create the explained scenario, and testing on it how works the identification of policy violations. In order to detect policy violations, you have to define a security demand and configure the characteristics, like connectivity, information (permit or deny) and socket information (IPs, ports and protocol). Fig. 5 Security demands configuration The results format is not if it is correct or not, they are shown as in the figure: Line# Demand Name Expected Behavior 0 Servidor HTTP > PC Xarxa_30 Deny Status Unroutable Fig. 6 Security results Description Represents Network Security Demand If the behavior would be permitting the result will be the same except that in the Expected Behavior field it would appear Permit instead of Deny, so if you want to know whatever policy performance, all the results have to be analyzed. It also show the hops the demand can realize, so you can see where the traffic is blocked or if it is permitted all the hops the frame have to do. Another useful characteristic is the possibility of rules creation and edition. This tool permits user to modify the

6 characteristics of an existing rule or creating a new one that defines new technologies, without having to wait for OPNET actualizations. For example, in this case, it has been modified an administration rule, exactly the OS version of the routers used in the simulation. The routers used to configure the physical network (figure 3) are 2601 CISCO model and they support 12.2 OS version, but OPNET has defined in the rule to give a warning if a router has a different version than The only modification that has been done to avoid the appearance of warnings is to change the Default Value and the Description of the os_version parameter. Fig. 7 Rule edition FLOW ANALYSIS ANALISYS Flow Analysis is an OPNET module used to analyze networks that supports specific traffic (configured or imported). In this case the network is an IP network and the traffic supported are flows imported from ACE captures which have been taken from the physical network. It is important to remember that flow analysis only runs with background traffic. The simulation will be done on the network where NetDoctor analyses have been done, so you know that it doesn t have configuration errors. Traffic flows are the following: Fig. 8 Traffic imported flows The flows on the network are: HTTP Server (PC Opnet_1). HTTP Server (PC Opnet_2) (PC Opnet_2) (PC Opnet_1). In order to obtain each one of the flows you have to configure correctly the devices when you are importing. OPNET detects in the file imported the devices that have generated traffic so you are able to divide each part of traffic between each pair of devices. The first idea was to analyze the efficiency of both Flow Analysis and ACE results and compare them, but the flow importing method calculates the traffic level in different intervals applying specific procedures. R = sum of repetitions for frame files ( repetitions _ frames frame _ size) V = R R TAR = number _ users interval _ duration 3600 Poisson( TAR) V bps _ per _ interval = durada _ interval Fig. 9 Variable traffic calculation

7 T = application bits source destination V = number of users TAR = repetitions per user per hour T U R bps _ per _ flow = 3600 Fig. 10 Uniform traffic calculation Although traffic is not analyzed packet per packet, the other results, like delays, would be similar to ACE results because the physical and simulated network is the same, and the imported traffic in Flow Analysis is the one captured with ACE. The results obtained with ACE and Flow Analysis are completely different, for example the processing effect on HTTP Server is approximately 3.3 msec instead of the inexistent processing delay that appears in Flow Analysis. This is an inconsistency, because if you are analyzing the same simulated characteristics as you have physically the results would be similar and they aren t. Apart from simulating networks and viewing the results to analyze them, this module offers other characteristics that become useful to make other type of analysis: Failure analysis Visualize route maps These characteristics have been applied on a simple network with redundant paths and it has been tested if the traffic is routable although having a connection failure, and if there exists difference between the results obtained in one path (figure 11) or the other (figure 12). Fig. 71 Default path Fig. 82 Redundant path for failures The result is surely changing in the Demand Routing between the server and PC Opnet_2. The rest of results won t change because of the inexistent delays. CONCLUSIONS The importance of detecting inefficiencies and problems on networks has increased in the last years. The reason is the expansion of networks and the continuous development of new applications. It has been verified that OPNET integrates all necessary tools to realize network and application analysis. The objective of this project was to evaluate each module benefits, apart from analyzing the efficiency of each one. ACE integrates the possibility of making simultaneous captures from different points of a network, managing the network from an only device

8 (Capture Manager). This new development makes ACE differentiate from typical sniffers. Moreover, NetDoctor and Flow Analysis help to check configuration, security policies, routing, The fact of having tools to analyze the performance of networks and applications before introducing them physically, helps companies to detect problems and inconsistencies that could decrease their efficiency.