Sniffer Pro

[AyrishGrl]

We currently have Sniffer Pro v.4.70.04 and I am trying to do some research on the most recent version of this software. I can't seem to find the Sniffer Pro anywhere, but I have found Sniffer Portable. Are these the same application? It appears they may have just changed the name of the product at some point.

Also, I am trying to get approval to take a sniffer class. Anyone have any recommendations? We have had some network issues this week that have required some network sniffing and I wish I could interpret these traces better than I can currently. Right now I am relying on the diagnosis that the software is giving me.

 

[fortunat]

I've got some info on my site that you may find helpful;

http://www.thetechfirm.com

If you need anything else, let me know

'Making things work better; bit by bit.'

 

[jdeisenm]

Buy the sniffer book on amazon.
It is a good place to start reading.

Call network general you should at least get some good info from a sales person.
Learn how to use filters. That way you are not looking at so many packets.

I took the official Sniffer / TCPIP class from Sniffer instructor Bob Sherman.
That was really good.
Another good source for training is PMG.

http://www.pmg.com

 

[AyrishGrl]

Thanks for all the info so far. I have some specific questions that relate to traces I am trying to analyze. Traces are of the ports our database and web servers for a specific application. Whenever I include the database port in the traces I get tons of "Too many retransmissions" and "Non-responsive host" diagnosis (Sniffer Pro) in the diagnosis tab. These are occuring between the database and the front end application. When I look at the decode info for a specific retransmission I will see src add: 10.204.69.122 (front end app) and dest 10.206.18.13( database). The front end app is sending a retransmission to the database. Did the front end not receive the ACK from the database and thus send the retrans? Is is normal to see a lot of retransmissions when you are doing database calls?

 

[jdeisenm]

Can you look as the switchport to which each device connects?
Cisco command sh int g1/1
Are there any errors?
Are they running at maximum speed? full/1000
Is the database server ok (cpu memory usage)?
Are other users directly connecting to the database server?
Are there any broadcast storms on either network?

 

[AyrishGrl]

Not showing any errors on the involved ports. The database port on the passport is set to auto-negotiate and are negotiating to 100/full. That's one of the weird things. This port used to be hard coded to 100/full and two weekends ago it somehow changed back to auto. However, it is negotiating correctly and we aren't seeing any errors that we usually see when autoneg is causing problems. DB server utilization is fine. Would the sniffer show if there were broadcast storms?

 

[AZeemeri]

Yes Sniffer will show broadcast storms.

Seeing retransmissions is normal to a certain extent. Depending on the tresholds that you set in Sniffer before it creates a Diag or Symptom. This should always be adapted to your own baseline. Every network is different.
How is the application performing then?

 

[AyrishGrl]

The application will run slow then it will speed up. This goes on back and forth throughout the day. We are getting certain errors that are supposedly from a bug in the Progress code. Our developers are working on that with Progress. I guess they have been given some sort of patch. How much of the slowness is because of that I can't really tell.

How do you set the thresholds in Sniffer Pro? Thanks.

 

[Whoheard]

Hardware can cause these types of problems. I would go back and set the port to 100/full and do the same for the NIC. Auto is fine, but some NIC's and Switches don't play well when comes to negotiating.

Just a thought.

I know what I know and that's all I know. What I don't know I'll find out.

 

[Kyusaku]

With the expert reporting "too many retransmissions" and "Non responsive host" this to me sounds hardware related. I would first look at cpu utilization and the amount of ram avaliable. This can account for your errors (network congestion can account for this as well, but I always look at the machine first.) since the server is just too busy swapping memory and cpu cycles are heavly utilized by running programs to quickly answer network connections. If both are maxed out, I suggest finding ways to better utilize your system resources. If this doesn't help, then you have probably outgrown the servers. Next, what type of load is there on the network in which the servers are connected? Is it heavly saturated? Are you running on a hub which you thought was a switch...etc...

Hope this helps

 

[AZeemeri]

Under Tools-->Expert Options--> Alarms Tab you can view and change the values

 

[Helmuth2]

A few questions to better understand your problem

Did the front end not receive the ACK from the database and thus send the retrans?
Do you see the ACK of the Database in the trace? If yes what ist the delta time to the Request?

src add: 10.204.69.122 (front end app) and dest 10.206.18.13( database)
What is the subnet mask on your network? is it really 255.0.0.0 ? Otherwise you might have a layer 3 instance such as router in between. Where did you take the trace - at the mirrorport of the frontend or of the database?
If there are more then one router the ACK paket could travel a different path.

However, it is negotiating correctly and we aren't seeing any errors that we usually see when autoneg is causing problems
I made the experience that if you hardcode duplex, you have to do it on both sides otherwise you might get problems.

Do you have the possibility to provide the trace somehow so that i could have a look on it?

regards
Helmuth

 

[netwho]

Did you ever had chance to check nPO Manager (Network General)?

This includes a modula who allows you to do a multi-trace and multi-tier analysis, means your frontend traffic can be alligned to the backend traffic.
(e.g. Apache, IIS, Websphere to MySQL, Oracle, MSSQL)

Regards, netwho




__________________________________
DOS -> Windows -> Linux -> FreeBSD
**** The evolution of a geek ****