Topic 3 Analysing network traffic Network design Topic 3 Analysing network traffic

Agenda Traffic flows Traffic load Traffic behaviour Quality of Service (QoS)

User communities and data stores A user community is a set of workers who use a particular application or set of applications May be located within a department May be a virtual team that crosses department boundaries Survey users to identify which applications they use and where the user is located Document user community name, number of users, location and applications used Locate data stores Server, server farm, SAN, mainframe, tape back-up, digital video library Document the data store name, the location, the application that uses the data store and the user community that uses the application

Traffic flows An individual traffic flow is protocol and application information transmitted between hosts during a single session Attributes include: Direction both directions or just one direction Symmetry is higher performance (QoS) required in one direction Routing path Number of packets Number of bytes End point addresses Measured by protocols analysers or network management systems NMS Cisco FlowCollector and data analyzer

Well known flow types Terminal/host traffic flow Usually asymmetric, telnet Client/server traffic flow Clients send queries and requests to servers, servers respond with data, Flow is bidirectional and asymmetric, SMB, NFS, HTTP Caching can change the flow Thin clients, Citrix and MS Terminal services, large volumes of data often at the same time of day Peer-to-peer traffic flow Bidirectional and symmetric, small LANs access to data Peer-to-peer applications for downloading music, software, videos Videoconferencing Server/server traffic flow Directory services, caching, data backup, management applications Generally bidirectional, symmetry depends on application Distributed computing traffic flow Multiple nodes share the processing load Flows are individual

Voice over IP flows Multiple flows Call setup and teardown Client-server flow, phone to gatekeeper or gateway, H.323, skinny, SGCP and MGCP, SIP Server or phone switch handles call control, call setup and teardown, addressing and routing, rules and capabilities, information and supplementary services Call switching, moving calls through infrastructure Audio voice flow and video flow Peer-to-peer between phones or software such as Cisco Softphone Distinct traffic flow which may follows a different path than call setup packets and requires QoS and bandwidth

Documenting traffic flows Create a table in your documentation to identify: Name of application Type of traffic flow Terminal/host Client/server Peer-to-peer Server/server Protocols used User community using application Data stores Approximate bandwidth requirements QoS requirements

Traffic load Traffic load is the sum of all the data that network hosts have ready to send at a particular time Network capacity should be adequate to handle the traffic load to avoid bottlenecks Consider: Number of stations Average time that a station is idle between sending frames Time required to transmit a message – frame size Number of stations * bits per second sent Estimate the load per application flow Investigate infrequent flows Such as printing monthly statements

Application usage patterns Identify: User communities Number of users in the community Applications used by users Frequency, number of sessions per day, week, month Length of average session Number of simultaneous users of an application Use information to predict total bandwidth requirement for all users of the application

Estimating traffic load of applications What size are the data objects sent by applications? What is the size of overhead caused by protocols? 802.3 frame header and trailer = 46 bytes IP header = 20 bytes TCP header = 20 bytes What is the size of any additional load caused by the application flow (initialisation)?

Estimating traffic load of routing protocols Large distance vector (RIP) routing tables can be sent every 30 secs Significant load on slow WAN links OSPF and EIGRP use very little bandwidth However OSPF database synchronisation packets every 30 mins could be a concern Hello packets (OSPF 10 secs, EIGRP 5 secs) are very small and effect is negligible

Traffic behaviour Broadcast traffic Broadcast radiation, the effect of broadcasting by a host can degrade performance NICs pass broadcasts and some multicasts to processor If more than 20% of network traffic is broadcast or multicast traffic segment the network with routers or VLANs Misconfiguration of subnet masks can cause intermittent broadcast storms IP network, limit the number of stations in a single broadcast domain to 500

Network efficiency Whether applications and protocols use bandwidth efficiently Frame size Use the largest MTU possible for large data transfers Configure on routers Protocols used Tune protocol timers Investigate read/write speeds of storage Windowing and flow control By increasing memory and CPU power on receiving hosts a larger receive window can be supported Error-recovery Selective ACKS, only missing segments are retransmitted

Quality of Service Is the bandwidth requirement flexible or non-flexible? Voice is inflexible to delay Sensitive to packet loss – clipped speech Packet loss occurs on congested links Protocols (RSVP) to allow hosts to reserve network bandwidth in advance and receive a guarantee of a negotiated level of service Packet classifier that determines the QoS class Admission control – are sufficient resources available on the intermediate nodes Packet scheduler – determines when packets are forwarded to meet the QoS requirements

Agenda Traffic flows Traffic load Traffic behaviour Quality of Service