Network Analysis Report

loyalsockvillemobNetworking and Communications

Oct 27, 2013 (4 years and 16 days ago)

67 views


[customer logo]




Network Analysis Report

[Date]














Submitted by:

Laura A. Chappell

Sr. Protocol Analyst

Protocol Analysis Institute, LLC

lchappell@packet
-
level.com

[customer]

Analysis Report


Page
1



May

2002

CONFIDENTIAL


[customer logo]


Network Analysis Report


Report Date:

[date]


Prepared by:

La
ura A. Chappell


Sr. Protocol Analyst


Protocol Analysis Institute, LLC


lchappell@packet
-
level.com


408
-
378.7841 (phone)


408
-
378.7891 (fax)


Thanks to following team for their assistance in the
onsite an
alysis tasks:



[IT assistant]


[IT assistant]


[IT assistant]


[IT assistant]



Please feel free to contact me for clarification on any
of the information contained herein.



Respectfully submitted,







Laura Chappell


lchappell@packet
-
level.com


[customer]

Analysis Report


Page
2



May

2002

CONFIDENTIAL


Ta
ble of Contents



Section 1:

Executive Summary

................................
................................
.................

3


Section 2

Technical Details

................................
................................
......................

6

TBS Application Fault When Loading “Cold”

................................
.......

7

General “Network Noise” Adds Unnecessarily to Overhead

.............

9

Inefficient Resoluti
on Procedures Add up to 2.5

Seconds to the Login Sequence

................................
..........................

11

Multiple Frame Types Cause Additional Unnecessary

Overhead

................................
................................
................................
.

13

Network Res
ponse Times Appear Good

................................
............

14

Gigabit Review Forthcoming

................................
................................

15

Possible Client Misconfiguration Causes

Network
-
Based Search for Desktop.i ni F
ile

................................
.......

16

Switches Should be Checked for “Leakage”
................................
......

17

ABC
.BAT File Loops

................................
................................
..............

18

Thr
oughput/Latency/Testing Tools Needed In
-
House

.....................

20


Appendix A:

Analysis Tools


Costs and Contacts

................................
.................

21


Appendix B:

Analysis Recommendatio
ns

................................
................................
.

22

Obtain Analysis Software

................................
................................
......

22

Train Network Team on Analysis

................................
.........................

22

Baseline

Current Network Traffic

................................
.........................

22

Test Configurations and Applications

................................
.................

23



Note
: At the end of each section, I have included a quick “Action
Item” that offers a suggested
action to resolve an issue or
investigate further.



[customer]

Analysis Report


Page
3



May

2002

CONFIDENTIAL

Section 1:

Executive Summary


Thank you for the opportunity to work with your team
at
[Customer]
.


This report focuses primarily on the “slow
performance” problem when opening the “the
Business System”
application (hereinafter referred to
as “TBS”). Secondarily, this report examines the
other general ‘traffic noise’ seen on the network and
issues relating to the client boot
-
up sequence.


This section provides a quick overview of the issues
noted during

the onsite visit and afterward upon
review of the trace files and network diagrams.




TBS Application Fault When Loading
“Cold”

During the first execution of TBS, we noted a
consistent error loading the PN (pathnames



YYYYY
\
DOS
\
PN
). This error indicates
that the
client cannot properly process one specific
area of the
file
, thereby causing a loop. The
loop resolves after what appears to be a
hardcoded application retry timeout occurs

(2.736 seconds)
. Second and successive
loading sequences do not encount
er the same
problem indicating that the application may
available in and loading from cache.




General “Network Noise” Add
s

Unnecessarily to Overhead

There are several communications that should
be removed from the network through client,
router and possibl
y server reconfigurations.
Most notably, we note a high number of SAP
type 640 packets broadcasting on the network.





Inefficient Resolution Procedures add up to
2.5 Seconds to the Login Sequence

During the login sequence, the NetWare clients
try to reso
lve NDS names using DNS,
NetBIOS, and WINS before trying NDS. The

[customer]

Analysis Report


Page
4



May

2002

CONFIDENTIAL

search order can be altered

on the NetWare
Client for 95/98




Multiple Frame Types Cause Additional
Unnecessary Overhead

There appear to be some systems on the
network that support both the
“Ethernet_802.3”
and “Ethernet_802.2” frame type. This adds
overhead and, in some cases creates a ‘local
routing’ problem on the network.




Network Response Times Appear Good

Sample client boot up and web browsing
sessions indicated that network response t
ime
is below 1 millisecond on the LAN with
appropriate delays seen when web browsing
off the local network or country
.




Gigabit Review Forthcoming

I plan to return to
[Customer]

with a
[name of
analyzer]
Gigabit Analyzer to examine the
communications on
the Gigabit backbone. The
schedule for this return visit is not yet defined.




Possible Client Misconfiguration Causes
Network
-
Based Search for Desktop.ini File

As we
examined the client boot sequence, we
noted that the client searched for desktop.ini
on t
he network up to 104 times before giving
up.

Why is the client looking to the server for
the desktop.ini file? Although this may be an
anomaly dealing with ZenWorks, the local IT
group should look further into this to identify
the possible cause.




Switch
es Should be Checked for “Leakage”

During the evaluation of
[user]
’s traffic, we
noted several unicast communications visible
from her switch port. It should be verified that
corporate switches are, in fact, offering virtual
circuits and not unnecessarily

forwarding traffic
down ports.


[customer]

Analysis Report


Page
5



May

2002

CONFIDENTIAL




ABC
.BAT File Loops


Adding over 5000 packets to the network at a
rate of 2500 packets/second, the
ABC
.BAT file
does not appear to be loading properly. The
clients appear to load the file numerous times
indicating a prob
lem with the batch file
processing system.





Throughput/Latency
/
Testing Tools Needed
In
-
House

The IT staff needs
appropriate tools and
training to troubleshoot packet
-
level
communications and define latency and
throughput rates on the LAN/WAN.


[customer]

Analysis Report


Page
6



May

2002

CONFIDENTIAL

Section 2

Technical Details


This section provides technical details on the network
analysis session. Wherever appropriate, this section
also includes recommended “Action Items” indicating
the next steps required to fix a problem or examine
causes.




[customer]

Analysis Report


Page
7



May

2002

CONFIDENTIAL

TBS Applicatio
n Fault When Loading
“Cold”

As mentioned in the summary section, d
uring the first
execution of TBS, we noted a consistent error loading
the PN (pathnames


YYYYY
\
DOS
\
PN).


Figure 1 shows the ‘loop’ that the client gets into.



Figure 1: Although there a
ppears to be a short loop remaining, it
is quickly resolved.


This loop is consistently occurring when the client
cold boots and begins loading the
YYYYY
/DOS/PN
file. During the loop, the client consistently makes the
following read requests:




Read 512 by
tes at offset 0



Read 512 bytes at offset 512


This error indicates that the client cannot properly
process one specific area of the file, thereby causing
a loop. The loop resolves after what appears to be a
hardcoded application retry timeout occurs (2.73
6
seconds).




[customer]

Analysis Report


Page
8



May

2002

CONFIDENTIAL

Second and successive loading sequences do not
encounter the same problem indicating that the
application may avai
lable in and loading from cache,
as shown in Figure 2.



Figure 2:
Although there still is a small loop, it is immediately
re
solved.



-
Action

Item
-


This problem is not related to the network
infrastructure


increasing bandwidth will not affect
this problem. This problem should be brought up to
the TBS application developers to identify a solution
or ‘workaround.’


[customer]

Analysis Report


Page
9



May

2002

CONFIDENTIAL

General “N
etwork Noise” Adds
Unnecessarily to Overhead

There are several communications that should be
removed from the network through client, router and
possibly server reconfigurations. Most notably, we
note a high number of SAP type 640 packe
ts
broadcasting on
the network, as shown in Figure 3.



Figure 3: Several systems, including “
[blanked out]
” advertise
640 services.


Additional unnecessary packets are generated
because multiple frame types are supported on the
IPX network causing local routing loops, as
defined in
the next section.


[customer]

Analysis Report


Page
10



May

2002

CONFIDENTIAL


-
Action

Item
-


This service can be removed unless
Gateway
Services for NetWare (GSNW) is
required. GSNW
broadcasts
SAP Type 640
packets
every 60 seconds
for
the remote procedure call (RPC) service. This
SAP broadcast continu
es even if the user disables the
GSNW and the SAP Agent Service.


For details on disabling the RPC service, see:


http://support.microsoft.com/default.aspx?scid=kb;EN
-
US;q1713
07
.




[customer]

Analysis Report


Page
11



May

2002

CONFIDENTIAL

Inefficient Resolution Procedures
A
dd up to 2.5 Seconds to the Login
Sequence

During the login sequence, the NetWare clients try to
resolve NDS names using DNS, NetBIOS, and WINS
before trying NDS. The search
process

can be
altered on the NetWare C
lient for 95/98

and
the
NetWare Client for NT/2000.


Just as there appears to be a name resolution
problem related to the NetWare service names, there
also appears to be a problem related to NT name
resolution. This requires further investigation and
expe
rimentation in a lab environment
, as shown in
Figure 4
.



Figure 4: The clients attempt unsuccessful name resolution
again.



[customer]

Analysis Report


Page
12



May

2002

CONFIDENTIAL


-
Action

Item
-



For more information, see:

http://support.novell.com/cgi
-
bin/search/searchtid.cgi?/10057730.htm

and
Novell’s
TID 10018391
.


This reference states that “
The Novell Client for
Windows NT/2000 allows you to selectively
disable/enable the different
service resolution
processes
. This i
s visible in the Protocol Preferences
tab of the Novell Client for Windows NT/2000
Properties. You must first select which protocol (IP or
IPX) you wish to configure and then check/uncheck
the
name services

listed in the "Protocol component
settings" dialo
g.


The Novell Client for Windows 95/98 allows you both
to selectively enable/disable these
Name Service
Providers (
NSPs
)
, but also allows you to change the
order in which they are used (NT/2000 will query the
NSPs asynchronously so there is no "order" to

how
they are checked). These controls are visible in the
Protocol Preferences tab of the Novell NetWare Client
Properties. You must first select which protocol (IP or
IPX) you wish to configure and then "Add" or
"Remove" the NSPs listed in the "Name Resol
ution
Order" dialog.






[customer]

Analysis Report


Page
13



May

2002

CONFIDENTIAL

Multiple Frame Types Cause
Additional Unnecessary Overhead

There appear to be some systems on the network that
support both the “Ethernet_802.3” and
“Ethernet_802.2” frame type.


This adds overhead and, in some cases creates a

local routing’ problem on the network.

This may also
cause some connectivity issues


for example, the
NSLP routers do not view as many neighbors over the
Ethernet_802.3 frame as
shown

in Figures 5.



Figure 5: Looking into NLSP neighbors known over the
Ethernet_802.2 frame type.



-
Action

Item
-


I highly recommend that you standardize on one
frame type


the Ethernet_802.2 is the preferable
frame type for IPX
-
based NetWare communications.
TCP/IP network services, however, should be run
over the Etherne
t II frame type.




[customer]

Analysis Report


Page
14



May

2002

CONFIDENTIAL

Network Response Times Appear
Good

Sample client boot up and web browsing sessions
indicated that network response time is below 1
millisecond on the LAN with appropriate delays seen
when web browsing off the local network or
internation
ally
.


-
Action

Item
-


Using
[tool]
, we were able to determine the route
throughput and latency times. This test should be
performed whenever users complain of network
WAN/Internet performance problems.



[customer]

Analysis Report


Page
15



May

2002

CONFIDENTIAL

Gigabit Review Forthcoming

I plan to return to
[Cu
stomer]

with a
[analyzer name]
Gigabit
Analyzer

to examine the communications on
the Gigabit backbone. The schedule for this return
visit is not yet defined.



-
Action

Item
-


We should plan on one hour to tap into the gigabit
network, check the status and

gather general traces.


[customer]

Analysis Report


Page
16



May

2002

CONFIDENTIAL

Possible Client Misconfiguration
Causes Network
-
Based Search for
Desktop.ini File

As we
examined

the client boot sequence, we noted
that the client searched for desktop.ini on the network
up to 104 times before giving up.


Why is t
he client looking to the server for the
desktop.ini file?



-
Action

Item
-


Although this may be an anomaly dealing with
ZenWorks, the local IT group should look further into
this to identify the possible cause.



[customer]

Analysis Report


Page
17



May

2002

CONFIDENTIAL

Switches Should be Checked for
“Leakage”

D
uring the evaluation of Dina’s traffic, we noted
several unicast communications visible from her
switch port. It should be verified that
corporate

switches are, in fact, offering virtual circuits and not
unnecessarily forwarding traffic down ports.


Swi
tches should provide a ‘closed circuit’ between
ports. During our connection on the network,
however, we found that we could ‘listen in’ on
numerous non
-
spanned ports.


This is a
performance and
potential security risk.


-
Action

Item
-


The switches sh
ould be checked to determine
whether they are performing properly. This is a
simple process as mentioned earlier in this report.


In order to check every port, however, the IS
team should randomly connect into available
ports on a switch to listen in on

the network
traffic and determine whether ‘leakage’
happens on specific ports or all ports.



[customer]

Analysis Report


Page
18



May

2002

CONFIDENTIAL

ABC
.BAT File Loops

The repetitive loading of the
ABC
.BAT file adds

over
5000 packets to the network at a rate of 2500
packets/second
.




Figure
6
: Filtering on
only
ABC
.bat file lookups indicates a
definite problem.


In fact, as I looked at communications relating to the
“Z”
directory and application, I saw a number of
problems. Figure
7

shows the file transfer process
relating to the synonym.val file contained
in the
“Z
\
R50
\
USER
\
username
\
” directory.



[customer]

Analysis Report


Page
19



May

2002

CONFIDENTIAL


Figure 7
: Clearly, this file transfer was never intended to run
across a network!


-
Action

Item
-


It may be worth compiling
ABC

into an executable
program to determine whether the ‘batch file’ nature is
causing
this repetitious behavior.



[customer]

Analysis Report


Page
20



May

2002

CONFIDENTIAL

Throughput/Latency/Testing Tools
Needed In
-
House

The IT staff needs
appropriate

tools and training to
troubleshoot packet
-
level communications and define
latency and throughput rates on the LAN/WAN.


During the onsite, I used
the following tools:


[Tool1]


[Tool 2]


[Tool 3]


[Tool 4]


[Tool 5]


[Tool 6]


[Tool 7]


-
Action

Item
-


The IS team needs the appropriate analyzer tools with
strong dec
odes and filtering abilities.
There are a
variety of tools that meet the analysis

and

troubleshooting needs of the
[Customer]

team.


These tools are listed in Appendix A.








[customer]

Analysis Report


Page
21



May

2002

CONFIDENTIAL

Appendix A:

Analysis Tools


Costs and
Contacts


Throughout the onsite analysis, I used
[Tool1], [Tool
2] and [Tool 3]
. My standard toolkit items are listed in
thi
s section:



[Tool 1]
:

Why I used it.


What it costs
.


Where they can get it
.


[Tool 2]
:

Why I used it.


What it costs
.


Where they can get it
.


[Tool 3]
:

Why I used it.


What it costs
.


Where they can get it
.


[Tool 4]
:

Why I used it.


What it costs
.


Whe
re they can get it
.


[Tool 5]
:

Why I used it.


What it costs
.


Where they can get it
.


[Tool 6]
:

Why I used it.


What it costs
.


Where they can get it
.


[Tool 7]
:

Why I used it.


What it costs
.


Where they can get it
.



I
f you have any problems
contacting

the mentioned
vendors, I am pleased to
assist
on your behalf.







[customer]

Analysis Report


Page
22



May

2002

CONFIDENTIAL

Appendix B:

Analysis Recommendations


Based on the initial meeting and the time spent
working with the local network team, I highly
recommend the following steps be taken to ensure
maximum

uptime and security on the network:


Obtain Analysis Software

As the local team noted, I used
[Tool 1]
throughout
my onsite analysis session. I also used
[Tool 2]
to
view live traffic. To ensure proper analysis
techniques and decoding, stay up
-
to
-
date o
n analyzer
software revisions.


Train Network Team on Analysis

The network team should be trained in packet
capture, port spanning/mirroring, and general network
analysis troubleshooting.


Baseline Current Network Traffic

You should maintain a ‘master se
t of trace files’ that
depict normal network operations. These trace files
should include:



general broadcast/multicast traffic


workstation boot up sequences


workstation login sequences


application launch sequences


workstation shut down sequences


Wh
en faults occur in any of the standard processes,
the local team can compare the trace files of the
problematic communications with the baseline set to
identify differences and faults.


[customer]

Analysis Report


Page
23



May

2002

CONFIDENTIAL


Test Configurations and Applications

Your network appears to be in a

state of extreme
change. I highly recommend that you test network
client/server communications in a lab environment
before deploying them on the production.


Look for the ‘overhead’ of each application and
process


such as the packets per second rate a
nd
utilization rate (bytes per second). Also spend some
time looking through the packets to determine
whether any dependencies can be identified. Finally,
check to ensure communications are secure and login
names/passwords are encrypted as needed.