Case Study #4
Home Up

Home
What's New
Travel
Consulting
Patz Etc.
Search/Site Map
Contact Us

 

 

CASE STUDY #4

This project involved an underperforming WAN. We were engaged to determine the network's trouble
 spots and to recommended fixes.

After several days of system monitoring, modeling, and extensive analyses, we uncovered a raft of issues which negatively affecting this network's performance.

The following plate displays an analysis of a conversation sourced from network station 0.0.0.0 to network station 255.255.255.255. The protocol is Bootp wherein a source is asking the Bootp server to issue it a valid network address. The 255 address is a network broadcast that is sent to every station on the network (0.0.0.0 and 255.255.255.255 are not valid [real] addresses). This is a perfectly normal network activity except for the fact that this installation did not run the Bootp protocol. This device is seeking a network identity from a Bootp server that does not exist. This consumes network bandwidth 24 hours a day, 365 days a year.

 

We found a large number of network ‘longs’, or illegally long (>~1508 bytes) Ethernet packets. An overly long packet is troublesome for at least two reasons:

 1.        it is dropped by the router that handles it, or by the final receiving station as it is an illegal packet

2.        it wastes network bandwidth as the illegal packet has to be retransmitted in two, or more smaller packets.

 In addition to the longs, we encountered a number of ‘runts’, illegally short Ethernet packets (<~64 bytes). The plate below shows both longs and shorts.

 

 

We wanted to get a better understanding of where the longs were coming from, so we dug deeper and found the following network conversation:

 

The long packets were coming from a misconfigured server. In the course of our analysis, we found other misconfigured devices.

Consider the following, all Novell Raw broadcasts (to FFFFFFFFFFFFFFFF, in gray at about 9 o'clock) from the network workstations whose addresses are in black (in hex). So, what's the issue? Well, this customer was not using any Novell protocols. Thus, all these spurious broadcasts were eating up network resources.

 

 In addition to these issues, we also uncovered some misconfigured routers:

 

HSRP is a Cisco protocol "Hot Standby Router Protocol" wherein two configured routers can be paired to provide backups for each other. To this this, they must be configured correctly. When not correctly configured, the routers can antagonize each other and actually slow network performance.

Result: Substantial performance gains on the WAN, increased network satisfaction and reliability. All of this was accomplished  through tuning with no hardware costs.

to top of page

Further information

bullet

Contact Us

bullet

Our Methodology

Jerrold Patz "Jerrold Patz" patz.com computer consulting "behavior modeling" "forensic engineering" "patz consulting"