i

DEDICATION
Dedicated in loving memory to my father, who inspired me to ask questions and encouraged me to be part of the answers. To my mother, my brothers and sisters, without whose kindness I would never have been able to do this, and to all the living beings, may this book help you in some small way to reach happiness.

Pierre Clestin NKUNDINTWARI

ii

ACKNOWLEDGEMENT
First and foremost, I am deeply grateful to my supervisor Dr Felix AKORLI for his tireless supervision and guidance in the achievement of this work. I am also grateful to Aimable GATERA, for his advice and encouragement during the preparation of this work. In addition, my thanks go to the Department of Electrical and Electronic Engineering, the Faculty of Applied Sciences, the National University of Rwanda for the knowledge I got throughout the six years. I want to thank also colleagues, friends and all people who have helped in many small, but significant ways for the realization of this work. Last, but not least I am sincerely grateful to my family for their love, support, and help.

iii

LIST OF ABBREVIATIONS AND EXPANSIONS

1. ARP: Address Resolution Protocol 2. ARPANET: Advanced Research Projects Agency Network 3. ATM: Asynchronous Transfer Mode 4. BITNET: Because Its Time Network 5. BPS: Bit Per Second 6. CDP: Cisco Discovery Protocol 7. CPU: Central Processing Unit 8. CSNET: Computer Science Network 9. DHCP: Dynamic Host Configuration Protocol 10. DNS: Domain Name Server 11. FTP :File Transfer Protocol 12. HTTP: Hypertext transfer protocol 13. IP: Internet Protocol 14. IPX: Internetwork Packet Exchange 15. ISO: International Organization for Standardization 16. LAN: Local-area network 17. MAC: Media Access Control 18. NETBIOS : Network Basic Input/Output System 19. NFS : Network File System

iv 20. NOS : Network operating system 21. NUR: National University of Rwanda 22. OS : operating system 23. PC : Personal Computer 24. PPP : Point-to-Point Protocol 25. QOS : Quality of service 26. RPC : Remote Procedure Call 27. SMTP : Simple Mail Transfer Protocol 28. SNMP : Simple Network Management Protocol 29. SPX : Sequenced Packet Exchange 30. TCP/UDP : Transmission Control Protocol/Internet Protocol 31. VLAN : virtual LAN 32. WAN : Wide Area Network 33. WWW : World Wide Web

LIST OF TABLES
TABLE 3.1: USER COMMUNITY [COMPUTING CENTER].......................................................................23 TABLE3.2: DATA STORES [COMPUTING CENTER]..................................................................................23

vi

LIST OF FIGURES

FIGURE 2.1: BOTTLENECK SEPARATION AND LINK[11].......................................................................12 FIGURE 2.2: NUR NETWORK DIAGRAM [COMPUTING CENTRE].......................................................28

TABLE OF CONTENTS

DEDICATION I

vii
ACKNOWLEDGEMENT......................................................................................................................................II LIST OF ABBREVIATIONS AND EXPANSIONS..........................................................................................III LIST OF TABLES..................................................................................................................................................V LIST OF FIGURES...............................................................................................................................................VI ABSTRACT RESUME CHAPTER 1 VIII IX 1

INTRODUCTION....................................................................................................................................................1 1.1 BACKGROUND......................................................................................................................................................1 1.2 STATEMENT OF THE PROBLEM ................................................................................................................................2 1.3 OBJECTIVES OF THE STUDY....................................................................................................................................2 1.4 HYPOTHESIS........................................................................................................................................................3 1.5 INTERESTS OF THE STUDY......................................................................................................................................3 1.6 SCOPE OF THE STUDY ...........................................................................................................................................3 1.7 ORGANIZATION OF THE STUDY ...............................................................................................................................4 CHAPTER 2 5 THEORICAL AND BASIC CONCEPTS OF SWITCHED LANS NETWORK AND NETWORK TRAFFIC.....................................................................................................................................5 2.1 AN OVERVIEW OF SWITCHED LANS NETWORKS ......................................................................................................5 2.1.1 Introduction to computer network...........................................................................................................5
2.1.1.1 LAN................................................................................................................................................................5 2.1.1.2 WAN...............................................................................................................................................................5 2.1.1.3 Internet............................................................................................................................................................6

2.1.2 OSI Model................................................................................................................................................6 2.2 TCP/IP NETWORK AND BANDWIDTH ......................................................................................................................8 2.2.1 Client/Server model.................................................................................................................................8 2.2.2 TCP/IP in more details............................................................................................................................8
2.2.2.1 TCP/IP Component area..................................................................................................................................9

2.3 BASIC CONCEPT OF BANDWIDTH [2]......................................................................................................................10 2.3.1 Link bandwidth and available bandwidth ............................................................................................11 2.4 CHARACTERIZING NETWORK TRAFFIC ....................................................................................................................13 2.4.1 Characterizing Traffic Flow..................................................................................................................13
2.4.1.1 Documenting Traffic Flow on the Existing Network.....................................................................................14 2.4.1.2 Terminal/Host Traffic Flow...........................................................................................................................15 2.4.1.3 Client/Server Traffic Flow.............................................................................................................................15 2.4.1.4 Thin Client Traffic Flow................................................................................................................................16 2.4.1.5 Peer-to-Peer Traffic Flow..............................................................................................................................17 2.4.1.6 Server/Server Traffic Flow............................................................................................................................18

2.4.2 Characterizing Traffic Load..................................................................................................................18 2.4.3 Characterizing Behavior ......................................................................................................................19

2.4.3.1 Broadcast/multicast behavior.........................................................................................................................19 2.4.3.2 Network Efficiency........................................................................................................................................20

2.4.4 Characterizing Quality of Service Requirements..................................................................................21 CHAPTER 3 22 METHODOLOGY AND ANALYSIS OF THE NUR NETWORK TRAFFIC...............................................22 3.1 RESEARCH METHODS AND TECHNIQUES .................................................................................................................22 3.1.1 IDENTIFYING MAJOR TRAFFIC SOURCES AND STORAGES.......................................................................................22 3.1.2 Data collection .....................................................................................................................................24
3.1.2.1 Design of questionnaire.................................................................................................................................25

3.2 ANALYZING NUR NETWORK TRAFFIC WITH WIRESHARK SOFTWARE...........................................................................29

viii
3.2.1 Real worlds Packets capture and collection........................................................................................29
3.2.1.1 Explore each of main labs traffics..................................................................................................................30 3.2.1.1.1 Traffic Flow..........................................................................................................................................30 Service Advertisements .......................................................................................................................................38 3.2.1.1.2 Traffic Behavior....................................................................................................................................42

CHAPTER 4

47

CONCLUSION AND RECOMMANDATIONS.................................................................................................47 4.1 CONCLUSION.....................................................................................................................................................47 4.2 RECOMMENDATIONS...........................................................................................................................................48 REFERENCES 49 APPENDIX 51

ABSTRACT
In this project we analyse the performance of traffic on the NUR network in order to find bottlenecks in the network and to identify the issues that the network administrators have to consider when making decision on bandwidth. To achieve the objectives, interviews were conducted on the users of NUR network. We use this information as a guide to identifying the problems. We therefore designed our test to

ix confirm that the identified problems are the causes of bottlenecks, such as broadcast on the network. The tests are done and analyzed using comparative method. We find out that the causes of broadcast are due to name resolution and registration used by computers in NUR LAN using 137 and 138 UDP port (NetBIOS name service and NetBIOS datagram service), ARP protocol that break the limit of subnet due to missconfiguration of subnets, and there are also many broadcast generated by some computers on 177, 710, 1434, 1900, 6771, 7009 UDP ports without any specific application and other broadcast are generated as if the NUR network was IPX/SPX network. The heavy broadcast level is due also to the lack of VLAN configuration on NUR network. Recommendations are made to propose a way to achieve high performance traffics solutions reducing bandwidth bottlenecks by overcoming those unwanted traffics limitation.

RESUME
Dans ce travail nous avons analys la performance du trafic dans le rseau du campus dans le but de dcouvrir les raisons du rtrcissement de la bande passante, et de dfinir les paramtres que ladministrateur du rseau doit considrer pour loptimisation de la bande passante du rseau. Nous avons pu trouver que les cause principales de ce rtrcissement sont du aux broadcast dont les sources prpondrantes sont mentionns dans ce travail.

x Dans nos conclusion et recommandations nous suggrons la rvision des configurations des appareils du rseau pour raliser un traffic plus performant et flexible pouvant prendre en considration lexpansion du rseau.

CHAPTER 1 INTRODUCTION
1.1 Background
In modern world, computer and network systems are playing a greater part in everyday life. Networks have become an important asset for all sizes of business. By providing shared resources, accounting, e-mail, and Internet access, computer networks have reduced costs, streamlined processes, and facilitated the sharing of information. However, networks are often complex and convoluted assortments of hardware and software, and network problems can impact the productivity of dozens (even hundreds) of users. Most networks in use today are far too large for the system administrators to effectively manage all of their elements, given the current methods and tools used. It is therefore important for technicians to find the causes of the problem on networks and correct them as quickly as possible .Without the appropriate tools to display and interpret the traffic of the networks; a technician is limited to time-consuming trial-and-error troubleshooting methods. In our analysis we use the Protocol analyzer. This offers technicians a powerful and versatile tool to analyze the operations of a network and locate trouble spots, identify stations that send excessive traffic by means of broadcasting, or experiencing errors information that are impossible to identify through the techniques of trial and error.[1] An overall performance of a well designed switched network is usually very high and when the network is in place and running, the system administrator must focus on operation and maintenance of the network. There are two main areas of switched LAN operation. 1. Maintaining the network: This is the process of observing network behavior in order to track overall network health and detect potential problems before serious network failures occur. This proactive monitoring of the network is vital to maintain continuous system

2 availability. The task of maintaining a switched network will be significantly simpler than the process of maintaining and administering a highly segmented router-based network 2. Troubleshooting network-related issues: This is the process of identifying and solving network-related problems as they occur. This reactive task must be well defined in advance in order to quickly resolve any network-related failures. Key in this process is the understanding of the tools used for network troubleshooting and the processes in which these tools will be used to solve problems.[1]

1.2 Statement of the problem

The demand on network of National University of Rwanda is growing very fast since the number of students has increased tremendously over the years, the demand on the network by lecturers in search of research documents due to the refurbishment of library collections. Apart from the afore mentioned there are thousands of unwanted packets, unused protocols and a great number of broadcasts which are also acting as loads and have consumed almost half of the bandwidth and have also overburden the network. There is a need of filtering some packet by closing some TCP/UDP ports, make some configurations for network devises. By doing so in the NUR network, users could achieve greater performance. Analyzing each packet that came off the cable, handle its application, and find out what kind of user need, will be the main objective of our project. It is in this context that we analyse the performance of network traffic to identify the bandwidth bottleneck.

1.3 Objectives of the study

The objectives of the study are as follows: Analyze the current NUR network traffic; especially the way filtering is performed. Design a suitable filtering system to achieve high performance. Implement filtering system to improve bandwidth.

1.4 Hypothesis
This project tries to demonstrate that:

Real-time analysis; this feature analyzes the data as it comes off the cable. Wireshark network analyzers use this to find network performance issues, and network bandwidth packets distribution and allow administrator to customize their configuration.[3]

1.5 Interests of the study

This project will permit to participate to the improvement of the NUR network. To use the knowledge acquired from class to generate a solution to a running network performances problem. Implementing successfully the project will allow to have more available bandwidth. The availability of Wireshark network analyzers will be used in small research organization.

1.6 Scope of the study

To study how the Wireshark Packet Analyzer system can be build on the NUR network, as scope, the project is based on: Review Wireshark network analyzers installation software that can be used in network traffic analysis. Allow network administrator to manage for better network performance. Manage administrator Wireshark network analyzers applications system. Review performance and reliability of network.

1.7 Organization of the study

This work is divided and organized as follows: The first chapter is about the introduction. It is divided into the following points: the background of the study, statement of the problem, objectives of the study, hypothesis, interest of the study, scope of the study and organization of the study. The second chapter gives theoretical concepts and terminology. It is concerned with the consultations of the existing literature in this field of study. It is a review to network protocols from the perspective network layers. It introduces basic terminology and provides a description of various network protocols technologies. It gives a broad overview of the different network architectures and gives an account on other technologies used. The third chapter is about the analysis in NUR network. It focuses on methodology that will be used, review parts of NUR network which may benefit wireshark network analyzers software. Network traffic analysis is the process of capturing network traffic and inspecting it closely to determine what is happening on the network. A network analyzer decodes, or dissects the data packets of common protocols and displays the network traffic in human-readable format. By the software development steps, it describes the design, the implementation along with tools for better management. And lastly, the fourth chapter gives a conclusion and some recommendations for further improvement

CHAPTER 2 THEORICAL AND BASIC CONCEPTS OF SWITCHED LANS NETWORK AND NETWORK TRAFFIC

2.1 An overview of switched LANS networks

2.1.1 Introduction to computer network

A computer network is a system for communication among two or more computers. Networks can interconnect with other networks and contain sub-networks. 2.1.1.1 LAN

LAN (Local Area Network) is a computer network that spans a relatively small area. A LAN supplies networking capability to a group of computers in close proximity to each other such as in an office building, a school, or a home. A LAN is useful for sharing resources like files, printers, games or other applications. LANs are capable of transmitting data at very fast rates, much faster than data can be transmitted over a telephone line; but the distances are limited, and there is also a limit on the number of computers that can be attached to a single LAN. [2] Besides operating in a limited space, LANs include several other distinctive features. LANs are typically owned, controlled, and managed by a single person or organization. They also use certain specific connectivity technologies, primarily Ethernet and Token Ring. 2.1.1.2 WAN As the term implies, a wide-area network spans a large physical distance. A WAN like the Internet spans most of the world!

6 A WAN is a geographically-dispread collection of LANs. A network device called a router connects LANs to a WAN. In IP networking, the router maintains both a LAN address and a WAN address. WANs differ from LANs in several important ways. Like the Internet, most WANs are not owned by any one organization but rather exist under collective or distributed ownership and management. WANs use technology like ATM and Frame Relay for connectivity.

2.1.1.3 Internet
The term Internet refers to the global network of public computers running Internet Protocol. The Internet supports the public WWW and many special-purpose client/server software systems. Internet technology also supports many private corporate intranets and private home LANs. The term "Internet" was originally coined in the 1970s. At that time, only the very meager beginnings of a public global network were in place. Throughout the 1970s, 1980s, and 1990s, a number of smaller national networks like ARPANET, BITNET, CSNET, and NSFNET evolved, merged, or dissolved, then finally joined with non-US networks to form the global Internet [7] 2.1.2 OSI Model The International Standards Organization (ISO) developed the Open Systems Interconnection (OSI) model in the early 1980's to describe how network protocols and components work together. It divides network functions into seven layers, and each layer represents a group of related specifications, functions, and activities. The layers of the OSI model are:

Application layer: This topmost layer of the OSI model is responsible for managing communications between network applications. This layer is not the application program itself, although some applications may have the ability and the underlying protocols to perform application layer functions. For example, a Web browser is an

7 application, but it is the underlying Hypertext Transfer Protocol (HTTP) protocol that provides the application layer functionality. Examples of application layer protocols include File Transfer Protocol (FTP), Simple Network Management Protocol (SNMP), Simple Mail Transfer Protocol (SMTP), and Telnet.

Presentation layer: This layer is responsible for data presentation, encryption, and compression. Session layer: The session layer is responsible for creating and managing sessions between end systems. The session layer protocol is often unused in many protocols. Examples of protocols at the session layer include NetBIOS and Remote Procedure Call (RPC).

Transport layer: This layer is responsible for communication between programs or processes. Port or socket numbers are used to identify these unique processes. Examples of transport layer protocols include: TCP, UDP, and Sequenced Packet Exchange (SPX).

Network layer: This layer is responsible for addressing and delivering packets from the source computer to the destination computer. The network layer takes data from the transport layer and wraps it inside a packet or datagram. Logical network addresses are generally assigned to computers at this layer. Examples of network layer protocols include IP and Internetwork Packet Exchange (IPX). Devices that work at this layer are routers and Layer 3 switches.

Data link layer: This layer is responsible for delivering frames between MAC on the same physical segment. Communication at the data link layer is generally based on MAC addresses. The data link layer wraps data from the network layer inside a frame. Examples of data link layer protocols include Ethernet, Token Ring, and Point-to-Point Protocol (PPP). Devices that operate at this layer include bridges and switches.

Physical layer: This layer defines connectors, wiring, and the specifications on how voltage and bits pass over the cabled or wireless media. Devices at this layer include repeaters, concentrators, hubs, and cable taps. Devices that operate at the physical layer do not have an understanding of network paths.

2.2 TCP/IP network and bandwidth

In this part, we review The makeup of TCP/IP and TCP/IP networks The effects of this ubiquitous protocol and hardware suite upon bandwidth consumption

2.2.1 Client/Server model

The TCP/IP protocol suite, the keystone of the Internet, is built upon a client/server model. Under such a paradigm, one computer or subsystem, the server, provides services; another, the client, must specifically request those services. A client always initiates the conversation by issuing such a request. A server, on the other hand, does nothing more than sit patiently waiting for client petitions. Exchanges between client and server rely on messages, which in the world of TCP/IP have a very specific nature and structure. When a server receives a message that contains a request for services from a client, the server first finds out if those services are available. Then it determines if the client has been allowed access to the services. Finally, the server figures out how it will deliver the services to the client [8]

2.2.2 TCP/IP in more details

TCP/IP, once the default protocol suite only of UNIX systems, has become the norm on the Internet at large. As one might expect, given this omnipresence, TCP/IP happily ignores: A computer's manufacturer, and therefore can be the basis for heterogeneous networks The physical layout of the network The operating systems involved in a network Rather, TCP/IP forces both client and server to rely on a single standard

9 The TCP/IP suite includes protocols, like the transmission control protocol (TCP) and Internet protocol (IP), for which it is named and which function at relatively low levels of the open systems interconnection or OSI model. It also takes into consideration the application-level protocols that accomplish, among other things the following Email Emulation File transfer Remote login

2.2.2.1 TCP/IP Component area

Any system or network that adheres to the client/server model contains a number of subsystems. These subsystems are categorised into the following components: Client components Server components Middleware Connectivity hardware Client Operating System: A client computer must rely on its native operating system in order to have access to network services. The client OS handles both internal processing which is related to data communications, particularly, the interface to middleware, that is, to the connectivity software and protocols Therefore, the client operating system has a significant effect on the overall efficiency of data communications. [8] Server Operating System: Like client operating systems, server OSes handle local operations related to data communications. Unlike their client counterparts, though, server operating systems must handle not only inter-process communications but also the applications that make up a large part of the resources distributed by any network.

10 Connectivity Software and Protocols: Middleware is the TCP/IP component area that is by far the most critical to data communications. This category contains all the software needed to establish and manage the client/server conversation. Middleware includes: Network operating systems or NOSes Service-specific software such as device drivers Transmission software and protocols Connectivity Hardware: Of the five most important types of connectivity devices: Repeaters Switches Bridges Routers Gateways

2.3 Basic concept of bandwidth [2]

The following list provides definitions for network performance goals that you can use when analyzing precise requirements:

Capacity (bandwidth). The data-carrying capability of a circuit or network, usually measured in bits per second (bps) Utilization. The percent of total available capacity in use Optimum utilization. Maximum average utilization before the network is considered saturated Throughput. Quantity of error-free data successfully transferred between nodes per unit of time, usually seconds Offered load. Sum of all the data all network nodes have ready to send at a particular time Accuracy. The amount of useful traffic that is correctly transmitted, relative to total traffic

11

Efficiency. A measurement of how much effort is required to produce a certain amount of data throughput Delay (latency). Time between a frame being ready for transmission from a node and delivery of the frame elsewhere in the network Delay variation. The amount of time average delay varies Response time. The amount of time between a request for some network service and a response to the request

2.3.1 Link bandwidth and available bandwidth

Bottleneck link bandwidth and available bandwidth are useful parameters for most network application and users. The bottleneck link bandwidth of path is also called path capacity, path bandwidth or bottleneck capacity. In an ideal environment, if there is no other traffic in the path, bottleneck link bandwidth is the bandwidth of lowest-bandwidth link from source to destination. It is limited by bottleneck links underlying capacity. Available bandwidth is defined as the maximum rate that the path can provide to a flow without reducing the rate of cross traffic, in order wise , available bandwidth is the amount of bandwidth which is available for a flow from the sender to the receiver, if we consider the cross traffic. Millions of users form all over the world use the Internet simultaneously. The available bandwidth depends on the link bandwidth and the presence of competing traffic.[11] The figure 1.1 shows the bottleneck separation and bottleneck link for sender and receiver traffics.

12

Figure 2.1: Bottleneck separation and link[11]

Why measure bandwidth performance?

When a network user complains that the network speed is slow. There are two main reasons that could cause the machine to be slow . 1. One is the limitation of the host machine, such as slow file servers or poor performance workstations, which do not have enough memory or hard disks. 2. Another reason is the properties of network, such us the limited bandwidth and network latency. The first problem may be solved by user though acquisition of better hardware. But, it is difficult for a user to attempt a solution of the second problem, without the availability of an easy method to measure the network bandwidth.[11] To improve network performance, we need to find ways to monitor it. Some of reasons that bandwidth measurement is necessary are: 1. As more and more applications are implemented in the internet, a large investment is being made to implement high-speed and large-bandwidth networks. But, how do we know the performance of the network has improved and we have achieved the expected result?

13 2. Network users benefit from knowing the bandwidth. For example, the network protocol or application programmers need to know the bandwidth and latency with accuracy to evaluate the efficiency of their protocols or programs. The more the availability of information about network path properties, the more efficiently network users can use the network to transfer their data. 3. Measuring bandwidth is the key to congestion control. In order to keep the amount of data that an application sends out below the network capacity, we must know the available bandwidth. 4. Network application could choose the best route dynamically to access the server. There are many potential paths through the internet between two hosts. The bandwidth, round trip time and packet loss rate of various paths are different. By measuring these parameters, network application can select the best path to get quick response and better performance. 5. For mobile computing, knowing the bandwidth is important. Mobile computers generally have more than one network interface and the available server changes frequently. Measuring the bandwidth and latency is the first step to find the best network interface to transfer the data.[12] 6. In the network control mechanism, measuring the bandwidth is a critical technique to provide the guarantees of QoS (Quality of service) [11]

2.4 Characterizing network traffic

2.4.1 Characterizing Traffic Flow Characterizing traffic flow involves identifying sources and destinations of network traffic and analyzing the direction and symmetry of data traveling between sources and destinations. In some applications, the flow is bidirectional and symmetric. (Both ends of the flow send traffic at about the same rate.) In other applications, the flow is bidirectional and asymmetric. Client stations send small queries and servers send large streams of data. In a broadcast application, the flow is unidirectional and asymmetric. This section talks about characterizing the direction

14 and symmetry of traffic flow on an existing network and analyzing flow for new network applications. 2.4.1.1 Documenting Traffic Flow on the Existing Network Documenting traffic flow involves identifying and characterizing individual traffic flows between traffic sources and stores. Traffic flows have recently become a hot topic for discussion in the Internet community. A lot of progress is being made on defining flows, measuring flow behavior, and allowing an end station to specify performance requirements for flows. Measuring traffic flow behavior can help network designers to accomplish the following:

Characterize the behavior of existing networks Plan for network development and expansion (scalability ) Quantify network performance Verify the quality of network service Ascribe network usage to users and applications

An individual network traffic flow can be defined as protocol and application information transmitted between communicating entities during a single session. A flow has attributes such as direction, symmetry, routing path and routing options, number of packets, number of bytes, and addresses for each end of the flow. A communicating entity can be an end system (host), a network, or an autonomous system. The simplest method for characterizing the size of a flow is to measure the number of Kbytes or Mbytes per second between communicating entities. To characterize the size of a flow, a protocol analyzer or network management system is used to record the load between important sources and destinations. A network flow can be characterized by its direction and symmetry. The direction of the flow specifies whether data travels in both directions or in just one direction. It also specifies the path that a flow takes as it travels from source to destination through an internetwork. The symmetry of a flow describes whether the flow tends to have higher performance or QoS

15 requirements in one direction than the other direction. Many network applications have different requirements in each direction. A good technique for characterizing network traffic flow is to classify applications as supporting one of a few well-known flow types:

Terminal/host traffic flow Client/server traffic flow Peer-to-peer traffic flow Server/server traffic flow Distributed computing traffic flow [2]

2.4.1.2 Terminal/Host Traffic Flow Terminal/host traffic is usually asymmetric. The terminal sends a few characters and the host sends many characters. Telnet is an example of an application that generates terminal/host traffic. The default behavior for Telnet is that the terminal sends in a single packet each character a user types. The host returns multiple characters, depending on what the user typed. As an illustration, consider the beginning of a Telnet session that starts with the user typing a username. Once the host receives each packet for the characters in the name, the host sends back a message (such as Password Required) in one packet. 2.4.1.3 Client/Server Traffic Flow Client/server traffic is the best known and most widely used flow type. Servers are generally powerful computers dedicated to managing disk storage, printers, or other network resources. Clients are PCs or workstations on which users run applications. Clients rely on servers for access to resources, such as storage, peripherals, application software, and processing power. Clients send queries and requests to a server. The server responds with data or permission for the client to send data. The flow is usually bidirectional and asymmetric. Requests from the client are typically small frames, except when writing data to the server, in which case they are larger. Responses from the server range from 64 bytes to 1500 bytes or more, depending on the maximum frame size allowed for the data link layer in use.

16 Hypertext Transfer Protocol (HTTP) is probably the most widely used client/server protocol. Clients use a web browser application, such as Netscape, Mozilla Firefox to talk to web servers. The flow is bidirectional and asymmetric. Each session often lasts just a few seconds because users tend to jump from one website to another. The flow for HTTP traffic is not always between the web browser and the web server because of caching. When users access data that has been cached to their own systems, there is no network traffic. Another possibility is that a network administrator has set up a cache engine. A cache engine is software or hardware that makes recently accessed web pages available locally, which can speed the delivery of the pages and reduce WAN bandwidth utilization. A cache engine can also be used to control the type of content that users are allowed to view. 2.4.1.4 Thin Client Traffic Flow A special case of the client/server architecture is a thin client, which is software or hardware that is designed to be particularly simple and to work in an environment where the bulk of data processing occurs on a server. With thin client technology, (also known as server-based computing), user applications originate on a central server. In some cases, the application runs on the central server, and, in other cases, the software is installed on the server and is downloaded into the client machine for execution. The main advantage of thin client technology is lower support costs. Network managers can have a centralized base of applications that are managed, configured, and upgraded only once. There is no need to individually configure each user's machine. In addition, because applications are controlled from the central server, security can be better managed. Thin client technology is not applicable to every computing application, however, because users may need computers capable of operating without constant connection to a central server. A downside of thin client technology is that the amount of data flowing from the server to the client can be substantial, especially when many computers start up at the same time every day. Networks that include thin clients should be carefully designed with sufficient capacity and an appropriate topology. Switched networking (rather than shared media) is recommended, and to avoid problems caused by too much broadcast traffic, each switched network should be

17 limited to a few hundred thin clients and their server(s). The switched networks can be connected via routers for communications between departments and accessing outside networks such as the Internet. [2] 2.4.1.5 Peer-to-Peer Traffic Flow With peer-to-peer traffic, the flow is usually bidirectional and symmetric. Communicating entities transmit approximately equal amounts of information. There is no hierarchy. Each device is considered as important as each other device, and no device stores substantially more data than any other device. In small LAN environments, network administrators often set up PCs in a peer-to-peer configuration so that everyone can access each other's data and printers. There is no central file or print server. Another example of a peer-to-peer environment is a set of multiuser UNIX hosts where users set up FTP, Telnet, HTTP, and NFS sessions between hosts. Each host acts as both a client and server. There are many flows in both directions. Recently peer-to-peer applications for downloading music, videos, and software have gained popularity. Each user publishes music or other material and allows other users on the Internet to download the data. This is considered peer-to-peer traffic because every user acts as both a distributor and consumer of data. Traffic flow is bidirectional and symmetric. Most enterprises and many university networks disallow this type of peer-to-peer traffic for two reasons. First, it can cause an inordinate amount of traffic, and, second, the published material is often copyrighted by someone other than the person publishing it. One other example of a peer-to-peer application is a meeting between business people at remote sites using videoconferencing equipment. In a meeting, every attendee can communicate as much data as needed at any time. All sites have the same QoS requirements. A meeting is different than a situation where videoconferencing is used to disseminate information. With information dissemination, such as a training class or a speech by a corporate president to employees, most of the data flows from the central site. A few questions are permitted from the remote sites. Information dissemination is usually implemented using a client/server model.

18 2.4.1.6 Server/Server Traffic Flow Server/server traffic includes transmissions between servers and transmissions between servers and management applications. Servers talk to other servers to implement directory services, to cache heavily used data, to mirror data for load balancing and redundancy, to back up data, and to broadcast service availability. Servers talk to management applications for some of the same reasons, but also to enforce security policies and to update network management data. With server/server network traffic, the flow is generally bidirectional. The symmetry of the flow depends on the application. With most server/server applications, the flow is symmetrical, but in some cases there is a hierarchy of servers, with some servers sending and storing more data than others. 2.4.2 Characterizing Traffic Load To select appropriate topologies and technologies to meet a customer's goals, it is important to characterize traffic load with traffic flow. Characterizing traffic load can help you design networks with sufficient capacity for local usage and internetwork flows. Because of the many factors involved in characterizing network traffic, traffic load estimates are unlikely to be precise. The goal is simply to avoid a design that has any critical bottlenecks. To avoid bottlenecks, you can research application usage patterns, idle times between packets and sessions, frame sizes, and other traffic behavioral patterns for application and system protocols. Another approach to avoiding bottlenecks is simply to throw large amounts of bandwidth at the problem. A strict interpretation of systems analysis principles wouldn't approve of such an approach, but bandwidth is cheap these days. LAN bandwidth is extremely cheap. There's simply no excuse for not using Fast Ethernet (or better) on all new workstations and switches, and most organizations can also afford to use Gigabit Ethernet on switch-to-switch and switch-to-server links.

19 2.4.3 Characterizing Behavior To select appropriate network design solutions, it is necessary to understand protocol and application behavior in addition to traffic flows and load. Thus, to select appropriate LAN topologies, one need to investigate the level of broadcast traffic on the LANs. To provision adequate capacity for LANs and WANs, you need to check for extra bandwidth utilization caused by protocol inefficiencies and non-optimal frame sizes or retransmission timers. 2.4.3.1 Broadcast/multicast behavior A broadcast frame is a frame that goes to all network stations on a LAN. At the data link layer, the destination address of a broadcast frame is FF:FF:FF:FF:FF:FF (all 1s in binary). A multicast frame is a frame that goes to a subset of stations. For example, a frame destined to 01:00:0C:CC:CC:CC goes to Cisco routers and switches that are running the Cisco Discovery Protocol (CDP) on a LAN. Layer 2 internetworking devices, such as switches and bridges, forward broadcast and multicast frames out all ports. The forwarding of broadcast and multicast frames can be a scalability problem for large flat (switched or bridged) networks. A router does not forward broadcasts or multicasts. All devices on one side of a router are considered part of a single broadcast domain. In addition to including routers in a network design to decrease broadcast forwarding, you can also limit the size of a broadcast domain by implementing virtual LANs (VLANs). VLAN technology, allows a network administrator to subdivide users into subnets by associating switch ports with one or more VLANs. Although a VLAN can span many switches, broadcast traffic within a VLAN is not transmitted outside the VLAN. Too many broadcast frames can overwhelm end stations, switches, and routers. It is important that you research the level of broadcast traffic in your proposed design and limit the number of stations in a single broadcast domain. The term broadcast radiation is often used to describe the effect of broadcasts spreading from the sender to all other devices in a broadcast domain. Broadcast radiation can degrade performance at network stations.

20 The network interface card (NIC) in a network station passes broadcasts and relevant multicasts to the CPU of the station. Some NICs pass all multicasts to the CPU, even when the multicasts are not relevant, because the NICs do not have driver software that is more selective. Intelligent driver software can tell a NIC which multicasts to pass to the CPU. Unfortunately, not all drivers have this intelligence. The CPUs on network stations become overwhelmed when processing high levels of broadcasts and multicasts. If more than 20 percent of the network traffic is broadcasts or multicasts, the network needs to be segmented using routers or VLANs. Another possible cause of heavy broadcast traffic is intermittent broadcast storms caused by misconfigured or misbehaving network stations. For example, a misconfigured subnet mask can cause a station to send ARP frames unnecessarily because the station does not correctly distinguish between station and broadcast addresses, causing it to send ARPs for broadcast addresses. In general, however, broadcast traffic is necessary and unavoidable. Routing and switching protocols use broadcasts and multicasts to share information about the internetwork topology. Servers send broadcasts and multicasts to advertise their services. Desktop protocols such as AppleTalk, NetWare, NetBIOS, and TCP/IP require broadcast and multicast frames to find services and check for uniqueness of addresses and names. 2.4.3.2 Network Efficiency Characterizing network traffic behavior requires gaining an understanding of the efficiency of new network applications. Efficiency refers to whether applications and protocols use bandwidth effectively. Efficiency is affected by frame size, the interaction of protocols used by an application, windowing and flow control, and error-recovery mechanisms. 2.4.3.3 Windowing and Flow Control To really understand network traffic, it is necessary to understand windowing and flow control. A TCP/IP device sends segments (packets) of data in quick sequence, without waiting for an acknowledgment, until its send window has been exhausted. A station's send window is

21 based on the recipient's receive window. The recipient states in every TCP packet how much data it is ready to receive. This total can vary from a few bytes up to 65,535 bytes. The recipient's receive window is based on how much memory the receiver has and how quickly it can process received data. You can optimize network efficiency by increasing memory and CPU power on end stations, which can result in a larger receive window. 2.4.4 Characterizing Quality of Service Requirements Analyzing network traffic requirements is not quite as simple as identifying flows, measuring the load for flows, and characterizing traffic behavior such as broadcast and error-recovery behavior. You need to also characterize the QoS requirements for applications. Just knowing the load (bandwidth) requirement for an application is not sufficient. You also need to know if the requirement is flexible or inflexible. Some applications continue to work (although slowly) when bandwidth is not sufficient. Other applications, such as voice and video applications are rendered useless if a certain level of bandwidth is not available. In addition, if you have a mix of flexible and inflexible applications on a network, you need to determine if it is practical to borrow bandwidth from the flexible application to keep the inflexible application working. Voice is also inflexible with regards to delays. Voice is also sensitive to packet loss, which results in voice clipping and skips. Without proper network-wide QoS configuration, loss can occur due to congested links and poor packet buffer and queue management on routers.

22

CHAPTER 3 METHODOLOGY AND ANALYSIS OF THE NUR NETWORK TRAFFIC

In this chapter we propose a process for analyzing traffic performance project. It describes the methodology used to carry out this project. Analyze requirements: In this phase, the network analyst interviews users and technical personnel to gain an understanding of the business and technical goals for a new or enhanced system. The task of characterizing the existing network, including network performance, follows. The last step in this phase is to analyze current and future network traffic, including traffic flow and load, protocol behavior, and quality of service (QoS) requirements.

3.1 Research methods and techniques

As the NUR network continue to grow in terms of number of students that are admitted, the new services that are introduced it becomes necessary to identify the major traffic sources and storage facilities. 3.1.1 Identifying Major Traffic Sources and Storages To understand network traffic flow, you should first identify user communities and data storage for existing and new applications. A user community is a set of workers who use a particular application or set of applications. A user community can be a student, teachers department or staff officer.

23

Table 3.1: User Community [computing center] Location(s) Percentage User Community Size of Community (Number of of Name Students Teachers Staff Other computers dedicated to Users) 434 76 254 8 Community Campus site Campus site Campus site Campus site 56 10 33 1 (%)

Figure 3.1: PC Utilization This figure shows that 56% of students have access to computers connected in different labs. In addition to documenting user communities, characterizing traffic flow also requires that you document major data stores. A data store (sometimes called a data sink) is an area in a network where application layer data resides. A data store can be a server, a server farm, a storage-area network (SAN), a mainframe, a tape backup unit, a digital video library, or any device or component of an internetwork where large quantities of data are stored. Table3.2: Data Stores [computing center]

24 Used by User Community (or Data Store Samba server Location Computing server farm Application(s) Center -valuable document -softwares -movies Unix student Computing server Radio server GIS server Library server server farm Salus Computing server farm Computing server farm Computing server farm Center Addressing Center Naming Center E-mail All All All server farm UNIX server DNS Computing server farm server farm web server Computing server farm Center Hosts the UNR website. All Center Research Students and teachers Center GIS web site host Students and teachers Center Used for exercises for Unix course Center IP Broadcasting Student and Teachers All Communities) academic Students and teachers

DHCP server Computing

e-mail server Computing

3.1.2 Data collection

Data collection has been done using questionnaire as research method for collecting data, questionnaires were distributed among different types of users of NUR network, as the project is designed to have great impact to every user, asking them their point view did much in making information accuracy.

25 3.1.2.1 Design of questionnaire

The questionnaires were addressed to three types of NUR network users: students, teachers and helpdesks personnel, with short and clear questions for gathering large number responses. The questionnaires aim at collecting three types of information in order to: administrator. Document traffic flow for new (and existing) network applications Characterize the flow type for each application and List the user communities and data stores that are associated with applications.

Here is the table we have to fill after collecting the answers of users and network

Table 3.3: Network Applications Traffic Characteristics User Communities Data Name Application of Type of Traffic That Use the (Servers, Flow Application All and So On) Mail server Satisfaction Stores Hosts, Comment

Electronic mail Client-server

26 User Communities Data Name Application of Type of Traffic That Use the (Servers, Flow Application and So On) Stores Hosts, Comment

File transfer, Sharing, access Remote terminal Web browsing

Client-server.

All

Different library server

servers: Too slow , there is a need for

and peer to peer Terminal/host Client-server All All Staff teachers

samba, unix server, optimization Unix server Web server Satisfaction and Printer server Satisfaction Satisfaction

Printer sharing Client-server

To refine your estimate of application bandwidth requirements, you need to research the size of data objects sent by applications, the overhead caused by protocol layers, and any additional load caused by application initialization. (Some applications send much more traffic during initialization than during steady-state operation.) Because applications and users vary widely in behavior, it is hard to accurately estimate the average size of data objects that users transfer to each other and to servers. (The true engineering answer to most questions related to network traffic is "it depends.") Table 3.4 provides some estimates for object sizes that you can use when making back-of-theenvelope calculations of application traffic load,

Table 3.4.: Approximate Size of Objects That Applications Transfer Across Networks [2] Type of Object Terminal screen E-mail message Size in Kbytes 4 10

27 Type of Object Size in Kbytes

Web page (including simple GIF and JPEG graphics) 50 Spreadsheet Word processing document Graphical computer screen Presentation document High-resolution (print-quality) image Multimedia object Database (backup) 100 200 500 2000 50,000 100,000 1,000,000

28

Figure 2.2: NUR network diagram [computing centre]

29 In figure 3.3 design there are some comments that have to be made or one set of questions that can be asked.

Most important suggestions for a Good Network Design

Here are some suggestions from Dr Peter Welcher [2] that are based on the tenets (rule) of hierarchical, modular network design: When you already know how to add a new building, floor, WAN link, remote site, ecommerce service, and so on When new additions cause only local change, to the directly connected devices When your network can double or triple in size without major design changes When troubleshooting is easy because there are no complex protocol interactions to wrap your brain around When scalability is a major goal, a hierarchical topology is recommended because modularity in a design enables creating design elements that can be replicated as the network grows. Because each instance of a module is consistent, expansion is easy to plan and implement. For example, planning a campus network for a new site might simply be a matter of replicating an existing campus network design. The last suggestion is the one that oriented the next part of this work.

3.2 Analyzing NUR network traffic with wireshark software

3.2.1 Real worlds Packets capture and collection The protocol analyzer provides technicians with a powerful tool for monitoring network traffic, then analyzing that network traffic to develop real-time or trending information that can help to efficiently pinpoint up to 85 percent of all network problems. They can even simulate traffic and other network conditions. For example, a protocol analyzer can Identify problem stations on the network. Filter and save data based on a range of criteria.

30 Identify the source and destination of selected network traffic. Measure network utilization and efficiency. Raise alarms when preselected settings are exceeded.[5] Without the type of information yielded by a protocol analyzer, there's no practical way to know what's going on ''inside the network wiring," and network problems could go undetected and uncorrected until a hardware failure occurs. This can cost an organization dearly in lost productivity of an impaired network, or in countless hours of frustrating trial-and-error troubleshooting. Current network analyzers can decode and process captured information to determine what events are causing specific error conditions, and then provide information as to the possible causes of the events. [1] In this part we discuss real world packet captures and traffic that we have been seeing on our network. Network scanning is used to identify available network resources. Also known as discovery or enumeration, network scanning can be used to discover available hosts, ports, or resources on the network. 3.2.1.1 Explore each of main labs traffics

As shown in diagram of NUR network there are many labs but the traffic in term has the same characteristic and behaviour in broadcast as we will see in following analysis done using wireshark software. 3.2.1.1.1 Traffic Flow

Here we tried to analyze the traffic flow; we explored the capture that we took on April 27 between 10:00:08 and 11:11:57 without any browsing. It means that we can see the level of broadcast on broadcast domain that we were working on. During that hour the average of bandwidth was 3482.524 byte/sec (0.028 Mbit/sec)

31 The source and destination was the first part of this analysis, here we found that the broadcast traffic was sent from terminals of network that was not in the same subnet as the terminal receiving those packets was. Figure 3.3 illustrate the broadcast flow.

Figure 3.3: Broadcasting flow In this figure we can see the packet dedicated to the subnets 192.168.6.0, 192.168.16.0 192.168.22.0, 192.168.18.0 not only those subnet are broadcasting , because even the following subnet have many computer that broadcast on the network 192.168.0.0, 192.168.2.0, 192.168.4.0, 192.168.20.0, 192.168.8.0, 192.168.22.0, 192.168.10.0, 192.168.24.0, 192.168.12.0, 192.168.26.0, 192.168.14.0, 192.168.28.0, 192.168.18.0, 192.168.30.0,

192.168.32.0. We can explore how much subnets can break its limit in broadcasting. In this small time we can see clearly that no limit in subnet in term of broadcast domain.

32 As said earlier too many broadcast frames can overwhelm end stations, switches, and routers. It is important that you research the level of broadcast traffic in your proposed design and limit the number of stations in a single broadcast domain.[2] Network administrators sometimes need to divide networks, especially large ones, into smaller networks. These smaller divisions are called subnetworks and provide addressing flexibility. Most of the time subnetworks are simply referred to as subnets. A primary reason for using subnets is to reduce the size of a broadcast domain. Broadcasts are sent to all hosts on a network or subnetwork. When broadcast traffic begins to consume too much of the available bandwidth, network administrators may choose to reduce the size of the broadcast domain.[9] On NUR network we can see that addressing is not structured. The consequences are: When sharing files with someone one the same lab become difficult when you dont have the IP address range. It requires that you have first change it manually. Without structure, it is easy to run out of addresses, waste addresses, introduce duplicate addresses and names, and use addresses and names that are hard to manage. [2] To meet a customer's goals for scalability, performance, and manageability, you should assign addresses and names systematically. A structured model for addressing means that addresses are meaningful, hierarchical, and planned. IP addresses that include a prefix and host part are structured. Assigning an IP network number to an enterprise network, and then subnetting the network number, and subnetting the subnets, is a structured (hierarchical) model for IP addressing.[2]

33 The benefits of hierarchy in an addressing and routing model are the same as those for a topology model:

Support for easy troubleshooting, upgrades, and manageability Optimized performance Faster routing-protocol convergence Scalability Stability Fewer network resources needed (CPU, memory, buffers, bandwidth, and so on) [2]

One of the applications using the broadcast is NetBIOS Figure 3.3 shows that, one of the applications using the broadcast is NetBIOS. NetBIOS is an application programming interface (API) that includes functions for naming devices, which ensures the uniqueness of names, and finding named services. Looking also the way the broadcast are spread on NUR network we see well that the configuration used for NetBIOS service is by default Registering and Resolving Names with Broadcasts. So let take a look on NetBIOS environment

NetBIOS in a TCP/IP Environment (NetBT)[2]

NetBT has gained popularity as a way of sharing files among Microsoft Windows clients in a TCP/IP internetwork. In a NetBT environment, there are four options for name registration and lookup: Broadcasts(which is used on NUR Network) Lmhosts files Windows Internet Naming Service (WINS) Domain Name System (DNS) A combination of WINS and DNS is also supported.

34

Registering and Resolving Names with Broadcasts

Because NetBT is based on NetBIOS, it makes extensive use of broadcast packets by default. Broadcast packets are used to announce named services, find named services, and elect a master browser in a Windows NT environment. Using broadcasts is not the preferred method for implementing naming functions in a TCP/IP environment, however, because of the performance implications and because routers do not forward broadcast packets by default. (A router can be configured to forward NetBT broadcasts, which go to UDP port 137, but this is not an optimal solution.)

Registering and Resolving Names with Lmhosts Files

To avoid clients having to send broadcast frames to look for named services, a network administrator can place an lmhosts file on each station. The lmhosts file is an ASCII text file that contains a list of names and their respective IP addresses. The lmhosts file is similar to the hosts file on UNIX TCP/IP devices, although it includes some Windows NT-specific functionality.

Registering and Resolving Names with WINS Servers

The use of lmhosts files requires a lot of maintenance because the files don't dynamically change as names change. As a network grows, lmhosts files should be removed in favor of using WINS or DNS servers for dynamic resolution of NetBIOS names to IP addresses. When a PC is configured with a WINS server, the PC sends a message directly to the WINS server to resolve a name, instead of using the lmhosts file or sending broadcast packets. The PC also sends a message to the WINS server when it boots to make sure its own name is unique.

35

Figure 3.4: Broadcast versus NBNS name registration [10]

Figure 3.5: Broadcast versus NBNS name resolution [10]

36 We can also continue with the same capture we can see some unusual traffic flow in figure 3.6. It is well clear that the destination 239.255.255.255 receive a great number of packet and act as broadcast address for our network. On my computer assigned with for 3rd class (class C) now receive broadcast packets that are in 4th class (class D) which are used for broadcast purpose. The funny thing with this broadcast is that you can watch it 24 hour, seven day a week, when you are connected on NUR network.

Figure 3.6: Class D broadcasting ( 239.255.255.255)

37

Figure 3.7: Broadcasting on UDP port 1434 This capture was done from 23h51:17 04 April 2007 till 01h28:21.Here we characterized the traffic flow looking at UDP port destination. The figure 3.7 we analyzed the traffic flow looking on UDP port 1434 assigned by IANA for Microsoft-SQL-Monitor but exploited by hackers, sending one of the dangerous worm SQL worm[3] It is known as the fastest spreading worm, and infected most vulnerable systems within 10 minutes. The SQL Slammer worm exploits a stack buffer overflow vulnerability that allows for the execution of arbitrary code. Once a system is compromised the worm will attempt to propagate itself by sending 376- byte packets to randomly chosen IP addresses on UDP port 1434. [3]

38 Broadcast over IPX also constitute a great impact on NUR network as we can explore in the following figure.

Figure 3.8: Broadcasting over IPX We can then take a look on IPX protocol on its way in broadcasting.

Service Advertisements
In an IPX network, servers advertise the services they provide. This is the reason why the protocol is sometimes referred to as chatty. The advertisement of services is done though the use of the Service Advertisement Protocol (SAP), an IPX protocol through which network resources such as file servers and print servers advertise their addresses and the services they provide.[10] The SAP sends its advertisement every 60 seconds and each service advertised is identified through the use of a SAP identifiera hexadecimal number identifying the service type.

39 Routers in the network build a list of services and their network addresses, which are the internal network addresses or virtual network addresses . The routers then send their SAP table every 60 seconds. It is important to note that IPX servers naturally perform a routing function and so, act as routers. Clients wishing a particular service make a request for the service and routers respond to the request by supplying the network address of the service. From then on, the client directs its request directly to the address advertising the service The same way the IPX protocols use NetBIOS in their broadcast configurations. But we can ask our self, is this IP or IPX network? Why this strange behavior does occur limiting our bandwidth? We can continue looking at some packet using TCP as transport layer to see how when addressing is not structured some consequences occur. Any strange thing we can see is that there are some packets that take the wrong destination: switches acting as hubs due to the heavy level of broadcast. Some packets are send to all ports of the switches.

40

Figure 3.9: Bad routed packets Not only broadcast overwhelm switches with excessive traffic but also sometime we can watch some computer sending traffic to specified IP address or using IPX protocol. The following figure show the conversation between my computer without any browsing with one computer that has 192.168.22.252 as its IP address. It was the top talker during the evening of Tuesday June 12, 2007; using TCP port 139 ; this port is used for sharing folders.

41

Figure 3.10: Conversation between on TCP port 139

42 3.2.1.1.2 Traffic Behavior

3.2.1.1.2.1 Broadcast/Multicast Behavior First let take one hour of broadcast, the following graph shows the evolution of broadcast without any browsing.

Figure 3.11: Broadcasting behavior On this graph we can see the main consumers of bandwidth in terms of broadcast. NetBIOS Name service (with UDP Port 137) and NetBIOS Datagram Service (with UDP Port 138) are the two protocols that come first in consuming the bandwidth (56.36% of broadcast) then come ARP. After we can watch in following wireshark graph window, the broadcast traffic with class D (IP addressing class) destination.

43

Figure 3.12: Class D with strange broadcasting behavior One of funny thing is when you follow the behavior of this traffic is that it is in order that three computers are broadcasting in cycle. First 192.168.230.3 start then 192.168.230.1, 192.168.230.4 finally it comes 192.168.230.2, 24 hours 7 days a week! 3.2.1.1.2.2 Network efficiency As said earlier characterizing network traffic behavior requires gaining an understanding of the efficiency of new network applications. Efficiency refers to whether applications and protocols use bandwidth effectively.

44 Let us see how during 2h40min on Monday march the 21 between 17h 34min and 20h13min. During browsing the average bandwidth was 2981.480 bytes/sec during those two hours and forty minutes. Figure 3.13: Traffic efficiency

The blue curve is for main broadcast protocols (NetBIOS Name service, NetBIOS Datagram service, IPX packets, RX, UDP port 1434, and UDP port 1900). The black curve is for the all traffics. At this time without any doubt it is clear that it is in critical network efficiency period. More than 70% of traffic here are broadcast. As in Top-Down Network Design book If more than 20 percent of the network traffic is broadcasts or multicasts, the network needs to be segmented using routers or VLANs. And this behavior is almost always the same every day on our network. Here we can say is more than a need. For the next figure we try to see protocol hierarchy.

45

Figure 3.14: Protocol hierarchy Only NetBIOS name service occupy 46.47% of packets during this time. And we can see in network conversation ( the following figure) the top talker( 192.168.2.33) computer was broadcasting on UDP port 6646, which is not a well known port in IANA registered UDP/TCP port.

46

Figure 3.15: Conversations In 41 top-talkers computers, 40 were broadcasting. It is important to take care about all those packets on network which are consuming the buffers of switches without any specific application. Configure the access list (deny option) on switches and routers allow the ability of blocking those unwanted packets coming from others subnet or other VLANs. This chapter provided techniques for analyzing network traffic caused by applications and protocols. The chapter discussed methods for identifying traffic sources and data stores, measuring traffic flow and load, documenting application and protocol usage.

47

CHAPTER 4 CONCLUSION AND RECOMMANDATIONS

4.1 Conclusion
The main objective of this project was to analyze the performance of network traffic and propose a way to achieve high performance traffics solutions, reducing bandwidth bottlenecks by overcoming the unwanted traffics limitation. It is possible to implement such systems in the NUR network and achieve a scalable network, to benefit of those features. To arrive to successful realization the current project, thus propose it on NUR network, Wireshark as packets analyzer was used. With the implementation of packet analyzers, to control each day the behavior of traffics, their efficiency, the system achieves these features: Manageability: looking at the behavior of device on network addressing and try to correct it systematically, we can transform this network more flexible and manageable. Performance: Get closer to each applications need by NUR user and the protocols that handle each; thus eliminate all packets that reduce the efficiency of the network. It can be the way to get network vaccination so avoiding malicious Hackers that can make NUR network every day more vulnerable and congested. Scalability: Network administrator has to know anything that refers to how much growth a network design must support, the network design he proposes to a client should be able to adapt to increases in network usage and scope. Briefly, traffics analysis systems enhance the performance and management of computation network resources.

48

4.2 Recommendations
After the analysis of NUR network traffics we recommend to the network administrator the following vital suggestions: Implementation of VLAN in NUR network [13] Review subnets configuration Make manageable DHCP configurations (basing on hierarchical addressing ) [4] Implementation of NetBIOS server using Registering and Resolving Names with WINS Servers option Remove IPX networks properties UDP ports 139, 1434, 1900 and 7009 must be closed temporally before taking furthers measures. (using access list command) [9] Disconnect the following list of computers for broadcasting on 177, 710, 3702, 5355, 6771 UDP ports. Before taking further measures: UDP port 177: IP 192.168.28.44 MAC : 00:09:3d:12 :3e:0e

IP 192.168.230.4 MAC : 00:09:3d:12:3e:0e (here it is easy to see that it is the same computer changing dynamically its IP address ) UDP port 710: IP 192.168.28.6 MAC :00:06:5b:dc:9b:aa

UDP port 6771 : IP 192.168.4.67 MAC : 00 :12:79:5d:b7:c2 IP 192.168.4.68 MAC : 00:0d:56:d3:e9:ee

49

REFERENCES
[1] Bigelow, Stephen J, Troubleshooting, Maintaining & Repairing Networks McGraw-Hill Professional, 2002. [2] Priscilla Oppenheimer, Top-Down Network Design, Second Edition, Cisco Press, May 27, 2004. [3] Angela D. Orebaugh and Gilbert Ramirez, Ethereal Packet Sniffing Syngress, February 2004. [4] Ralph Droms and Ted Lemon, The DHCP Handbook, Second Edition SAMS, October 2002. [5] Ogletree, Terry William, Upgrading and Repairing Networks, 4th Edition Indianapolis, Ind. Pearson Education, Inc., 2004. [6] Q.Walker, Jeffrey T. Hicks, Taking Change of Your VoIP Project Cisco Press, February 23,2004. [7] Roese, John J., Switched LAN's: Implementation, Operation, Maintenance New York, N.Y. McGraw-Hill Professional, 1998. [8] Petrovsky, Michele, Optimizing Bandwidth New York McGraw-Hill Professional, 1998. [9] James Boney, Cisco IOS in a Nutshell, 2nd Edition O'Reilly, August 2005. [10] David Collier-Brown, Robert Eckstein, Jay Ts, Using Samba, 2nd Edition O'Reilly, February 2003.

50

[11] Jun Wei, Bottleneck Bandwidth Measurement University of Windsor, Ontario Canada 2003. [12] Henrik Abrahamsson, Traffic measurement and analysis, Swedish Institute of Computer Science, September 1999. [13] Ingabire Batrice, Umutesi Liliane, Implementation of Virtual Local Network NUR, February 2005.

51

APPENDIX

52 NATIONAL UNIVERSITY OF RWANDA Faculty of Applied Sciences Electrical and electronics department QUESTIONNAIRE OF INTERVIEW FOR NUR NETWORK USERS 1. Which Professional category are you: Student Staff Professor 2. What kind of job and application do you use and need when you are connected to NUR Network? 3. Are you satisfied with the available network resources when making computation?
YES NO

4. If you answered to the above as NO what the limitations and problems you meet? 5. Which kind of system would you want which can satisfy your need?