Network Load

   


It is difficult and expensive to accurately determine the load being placed on a network, but a reasonable and useful estimate can be obtained by examining the number of "collisions" occurring on the network interface. By carrying out this exercise on a number of systems distributed around the network, a more accurate estimate can be calculated. In addition, this helps to identify network segments of particularly high (or low) usage.

A simple and effective way of gathering this information is to run the netstat command with the -i switch. Listing 13.1 contains some sample output.

Listing 13.1 Sample Output from Using the Command netstat -i to Gather Network Interface Statistical Information
 taurus# netstat -i 3  input   le0       output           input  (Total)    output   packets errs  packets errs  colls  packets errs  packets errs  colls  221981   5    302743  1     29087  283625  5     364387  1     29087  981      0    2095    0     670    991     0     2105    0     670  945      0    2025    0     847    953     0     2033    0     847  880      0    1901    0     1416   890     0     1911    0     1416  862      0    1862    0     1306   868     0     1868    0     1306  596      0    1249    0     857    606     0     1259    0     857  864      0    1872    0     417    872     0     1880    0     417  963      0    2083    0     588    971     0     2091    0     588  955      0    2050    0     535    963     0     2058    0     535  997      0    2114    0     532    1007    0     2124    0     532  928      0    2002    0     538    936     0     2010    0     538  1012     0    1980    0     505    1020    0     1988    0     505  947      0    2071    0     518    955     0     2079    0     518  935      0    2016    0     551    945     0     2026    0     551  978      0    2112    0     583    986     0     2120    0     583  934      0    2012    0     519    944     0     2022    0     519  986      0    2121    0     570    994     0     2129    0     570  923      0    2008    0     508    933     0     2018    0     508  944      0    2052    0     484    952     0     2060    0     484  975      0    2105    0     568    985     0     2115    0     568  432      0    986     0     295    440     0     994     0     295  350      0    824     0     235    358     0     832     0     235  360      0    850     0     251    368     0     858     0     251  371      0    877     0     231    381     0     887     0     231  360      0    853     0     247    368     0     861     0     247  373      0    879     0     260    383     0     889     0     260  taurus# 

The sample output from Listing 13.1 is useful because it shows a heavily loaded network interface. The line in bold text displays a set of typical values that can be used to see the current collision rate at a glance.

The interface counted 2,095 output packets ”that is, packets of data that were sent onto the network. Of those packets, 670 resulted in a collision ”meaning that they never arrived and had to be retransmitted. To calculate an approximate collision rate (as a percentage), divide the number of collisions by the number of output packets and multiply by 100:

Collision rate = (670 · 2095) x 100 = 31.9%

In this example, 31% of packets being transmitted onto the network are colliding with other packets and require retransmission. A network functioning normally should expect the collision rate to be 2% or less. A collision rate of between 2% and about 8 “10% depicts a normal, busy network, but anything over 10% is a clear indication that the network (or at least the segment relating to the system being examined) is too heavily loaded and needs to be addressed.

The previous example describes a nonswitched Ethernet network, where collisions are often an issue to be addressed. Of course a Token Ring network, including FDDI, does not suffer in the same way that an Ethernet network does because the use of a token determines which (single) host can send traffic. In a switched network, the "switching" of traffic virtually eliminates the issue of collisions and is a solution to a heavy-loaded nonswitched Ethernet network, as is subnetting.

The next section describes subnetting, a method of segmenting the network to reduce the circulation of network traffic and thus reduce the collision rate. It also discusses some other benefits that subnetting provides.

Subnets

Subnetting involves segmenting an existing network into a number of smaller, separate networks. Subnetting might be considered to be a valid option for several reasons:

  • Collision rate ”If the number of collisions is high, as in Listing 13.1, then splitting the network into a number of subnetworks localizes the propagation of the majority of the network traffic.

  • Large numbers of hosts ”A large number of hosts exist on a particular network ”say, greater than 25 or 30.

  • Performance ”Performance of network applications is degrading as more users access the network.

  • Isolating network power users ”Users of network- intensive applications can be provided with a dedicated subnetwork so that their usage does not adversely affect other users. A good example of this is in an engineering section, where graphical models are shared between a server and a small number of users.

  • Security ”The use of subnetworks is inherently more secure because network packets are restricted to the subnetted network segment instead of being propagated to the whole network. For example, a standard class C network, 210.127.8.0 supporting 255 hosts (with a network mask of 255.255.255.0), could be segmented, say, into 15 smaller networks, each of 14 hosts (by modifying the network mask to 255.255.255.240).

Benefits of Subnets

Splitting a network into several smaller subnetworks has a number of advantages:

  • Reduced traffic ”The amount of network traffic propagated to all hosts is reduced, improving the performance for the majority of users.

  • Fault diagnosis ”When diagnosing a network problem, it is easier to isolate smaller, existing portions of the network to assist with analysis and thus identify the cause of the problem. This also reduces the effect on the user community.

  • Testing ”The use of subnetworks allows small, manageable portions of the network to be used for testing and pilot implementations of applications, restricting the effect on other users. The subnetwork can be isolated from the "main" network quite easily to provide a standalone test facility when required.

  • IP address usage ”With the number of available IP addresses dwindling, subnetting can often make better use of existing IP address allocations .

  • Security ”Network traffic can be restricted to a small number of hosts on the subnetwork so that potentially sensitive information is not distributed too widely.

Of course, subnetting is not just a case of deciding what to do and then changing the network mask. Three basic steps are involved:

  • The existing network must be physically split to mirror the required changes. This may involve the addition of network bridges or similar network devices.

  • All affected nodes must be modified ”that is, you must change the IP addresses and the network mask of each system that is changed to belong to the new subnetwork. There might also need to be modifications to DNS tables so that the addresses can be resolved by external connections.

  • The new subnetwork needs to have a route supplied so that the hosts can communicate effectively with other networks or subnetworks.


   
Top


Solaris System Management
Solaris System Management (New Riders Professional Library)
ISBN: 073571018X
EAN: 2147483647
Year: 2001
Pages: 101
Authors: John Philcox

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net