Monitoring network, bandwidth

[MohitAnchlia]

I haven't monitored the network before. There are few things that I really want to monitor just to see how the traffic is, where is the bottleneck etc. Basically I want to check:
1. Different types of NIC cards or bridges etc. we have that are transmitting data. For Eg: gigabit ethernet, 10g ethernet etc.
2. Which Ethernet is most used on that box. Their transmission rates, % of utilization etc.
3. Which process is hogging network.

What I just described above may sound weird, I am new to most of the networking terminologies, but I am trying to read about variouse transmission technologies.

[Hoff]

Did you intend to post this question in the OpenView network tools forum and not in the OpenVMS operating system forum? If you had intended to post here and are seeking tools for use on and with OpenVMS, which architecture and version?

With OpenVMS, you can generally poll the NIC counters, and determine an aggregate of the network activity.

SDA (ANALYZE /SYSTEM) commands here include SHOW LAN and the LAN extension; LAN COUNTERS, etc.

Most folks tend to use an open-source or add-on tool (or network server appliance) for examining network traffic, or something such as OpenView.

[Robert Gezelter]

Mohit,

If I am simply trying to gather statistics, the network tools on OpenVMS can supply raw statistics. You can use the various SHOW commands in LANCP to display the list of interfaces and their associated counters.

For looking at overall traffic from different sources, I generally use WireShark (http://www.wireshark.org) on a mobile computer to monitor the network. A cautionary note: analyzing backbone usage correctly requires a fair degree of knowledge, it is regrettably easy to come to incorrect conclusions based on various errors.

As a starting point, an accurate, complete topology of the network, with all of the network components and their configurations is essential to getting a correct understanding.

I have traced many backbone problems for clients, it is not uncommon to find straightforward errors have catastrophic effects on system performance.

- Bob Gezelter, http://www.rlgsc.com

[MohitAnchlia]

I am sorry I don't even know what OpenView is. Is it a software that helps monitor HP network ? Is it always part of HP Box.

[Jon Pinkley]

http://forums1.itrc.hp.com/service/forums/pageList.do?userId=CA1420608&listType=question&forumId=1

shows that all your previous posts were to the HP-UX forum.

Did you really intend to post this question to the OpenVMS forum?

You don't specify what platform you want to do the monitoring from. If you are expecting to collect statistics from devices (e.g. routers or switches), you would normally collect that information with SNMP.

I suggest you look at somethng like MRTG or Cacti if you want something free. Google is your friend when you want to fnd info.

Good Luck.

Jon

[Hoff]

Yes, OpenView can -- among its many functions and capabilities and tools and options and knobs and dials -- monitor network activity.

http://www.hp.com/go/openview

OpenView is a large and complex package.

Others have mentioned some of the open-source network monitoring packages for various platforms. Lithium is a package for Mac OS X, for instance, and can monitor SNMP traffic from various sources.

Network probes -- data collectors -- are available for various platforms, including for OpenVMS, HP-UX and for various other platforms. These are often SNMP, with extensions. OpenView ties in with these.

In addition to posting up the operating system architecture and version involved here, providing some background on why you are looking for here might also be in order; on what symptoms you are investigating or troubleshooting.

[Paul Beaudoin]

MohitAnchlia and others:

I beg to differ with the slant of the replies. I came to VMS via the network management world many years ago and it was the networking, and particularly the management ability native to VMS that kept me interested for these past 2 decades. Running either form of DECnet gives a wealth of performance data that, via simple DCL procedures, is easily turned into useful information along the lines that the poster was asking for. More recently SNMP (and its DCL interface) was added. Further, with the abilty to easily collect this from all the machines on the network and assemble it locally, it is very nearly trivial to produce a simple, but accurate picture of network performance. Shame on you guys! Suggesting that VMS is not useful in this area? Scandalous!

BTW: If you want a few samples of how to do some of these procedures, just ask.

Regards

Paul

[Robert Gezelter]

Paul,

My reason for not favoring the statistics directly from OpenVMS over the use of a LAN analyzer (e.g., WireShark) are simple: the OpenVMS statistics show traffic that is known about by the OpenVMS nodes, WireShark will see all traffic on the network, period.

I have seen far too many cases where the network documentation is inaccurate. Actually monitoring the network will show accurately what is on the network (it is a separate question of whether that traffic should be on that network). Example: It is not uncommon to see non-OpenVMS traffic on what is supposed to be a dedicated OpenVMS-only LAN; this would be undetectable using the OpenVMS statistics.

WireShark, however, will quickly allow identification of such traffic.

For sure, both tools have their uses, and each tool should be used where appropriate.

- Bob Gezelter, http://www.rlgsc.com

[Paul Beaudoin]

Robert,

I take the point (and agree) but, (you knew the 'but' was comming didn't you)analysers like wire shark are indeed the best at seeing what is on the wire at this location and at this point in time. They are usually too expensive and complex to distribute through the network to get the multi-point, longer time-frame view that is necessary to gain a useful understanding of network performance. If you are chasing a specific problem then an analyser is the best tool. If you are simply monitoring for looming problems then you need a distributed gathering tool. If you have sufficient VMS boxes sprinkled around the net, this network (ackowleged as much simpler than dedicated tools) is already available. Two other points it I may: by monitoring JUST the ethernet interfaces you can gain a pretty useful picture of what that local segment is doing even in the absence of collecting all protocols (%collisions for example) and the poster indicated this was exploratory - building some simple procedures by hand strikes me as an excellent education.

Regards

Paul

[Robert Gezelter]

Paul,

I just have to put in my US$ 0.02.

The price of WireShark is indeed great, US$ 0.00. Admittedly distributing the monitoring requires rescuing some second-string notebooks/desktops from the local (generally in-house) boneyard.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

Paul,

I would be interested in the tools you have to collect data. Once you collect it, how are you using it?

Jon

P.S. is MohitAnchlia still reading this thread?

[Paul Beaudoin]

John,
It was a long journey; I started off building an automation layer (in DCL) for an old DEC product (NMCC) largely as it lacked any ability to 'autodiscover' (as it came to be known). This was mostly via DECnet phase IV using NCP commands then parsing out the responses and eventually placing it all in an RDB database. Once I hit about 30,000 lines it was clear that DCL was not the best route to go (I can be a bit slow at times). I then started converting this all to macro and eventually designed and mostly built a standalone NMS that included both DECnets (NICE and CMIP) SCS, IP(SNMP), IPX/SPX, LAT and other protocols that were around then.
As far as examples go, I released the macro version of this to the Freeware (v5 I think) and it is there under EMU. If you want the DCL. let me know and I'll zip it up and send it.
In terms of usefulness, given a faily extensive phase IV network, the DCL programs will find all the nodes and document all characteristics in an RDB database. There is the begining of a performance management module that captured the available counters, did some rudimentary arithmetic and alerted the more obvious problems but it was clear this was not the best approach.
The macro version is similar except it will chase down all nodes on more protocols and document them in RMS files. DO NOT run this on the internet. I made this mistake once and it atempted to document the entire thing! Once it found some 15,000 nodes (of which maybe a third responded to the SNMP requests for info), the files started to get rather big. Now, doing this is probably a good way to get denied.

We've probably beaten this one to death as much as is needed publicly. If you want more (I can happily go on for days ...) sent to my email.

Regards

Paul

PS. Rob: not so much disagreeing as looking at it from a different angle.