|
Wow, I read your reply in the notes conference and was really blown away. I
didn't necessarily agree with your characterization of his response as ill
thought out. I have the philosophy that RMON pods are not to be relied on to
do emergency diagnosis, necessarily, since their information is carried in SNMP
which relies on a stable network to run properly. If you are trying to use
RMON to troubleshoot a broken network, you will probably have less than optimal
results.
I think that is why he suggests you rely on a sniffer type box for emergency
situations. RMON is a client-server architecture and needs the net to function
correctly. A sniffer doesn't need a running net to get its data. I'm sure you
realize that a sniffer is nothing more, essentially, than the probe and the
probewatch on the same system. I'm sure you also know about our internal tool
IRIS. You can't give it to customers, but you can put it on a laptop, if you
can get one. It has a lot of decoders in it, and if you use it in a pc with a
NIC card that can accept bad packets, then you can use it on a broken network.
Probewatch is not a sophisticated product to do the network monitoring out of
the box. I don't know what its evolution is going to be, I just accept that it
needs customization to each site. I can't speak for the unix version, I only
know the windows version, and it can be used to track down different protocols
on the net, you just have to fish for them. I know it sucks, but that's life.
This guy isn't the developer, or the product manager. You blasted him pretty
good, undeservedly so.
>>>It appears that the probe was actually seeing was one that I have been
>>>told, it cannot track which is DECnet/OSI.
To set up the tracking of a not currently recognized protocol, you have to set
up a domain and at least one filter that characterizes this or these protocols.
You can use the domain editor and the filter editor, found on the main screen.
Documentation on how to use the editors may be in the online help in the
windows version. Unix, I don't know.
You then have to install the domain that you have created into the probe. This
design is, I believe, dictated by the RMON RFC. Once this is done, data on
this protocol, or collection of protocols can be logged, as a subcategory of
the overall ethernet statistics, and a list of hosts and a matrix of
conversations can be logged. The form of this is also dictated by RMON.
To find out what the protocols int the Other category are, do some data
captures. Download one, display it, then launch another data capture, but
filtering out the most popular protocol this time. Download this capture,
display it, and repeat the process, adding this most popular protocol to the
filter list. Repeat this process until you have a list of filters that is long
enout so that you don't capture any packets for a whole day. The list of
filters is all the protocol types that run on your net. Now if anything new
pops up in a data capture, you know what to look for.
The rest of Probewatch's reporting and graphing facilities can be extended,
too. More protocols can be added to the categories that get graphed. Jack
Forrest has posted some papers on how to extend the reporting function, to get
more detailed multi-domain reports. The file resides on the node that you
posted your note from.
>>This site uses a bit of DECnet/OSI....which makes the probes less
>>than satisfactory for our use!
If you get the assigned numbers RFC, or the ethernet protocol type list, you
can construct a filter and domain to monitor this protocol, or any other
ethernet protocol. Why the filter or domain is not pre-constructed, ask
product managment.
>>>>The game is to know what are the protocol running on youyr network.
>>>>For that use a professional tool like a LAN Analyser.
>>>>or Wait for RMON-2 to be implemented.
>>I'm glad you think this is a game. From the users perspective and I
>>would hope your customers as well, when a problem occurs on the network
>>and the montoring equipment doesn't report correct information, tempers
>>flair and work doesn't get done!
>>This is no game sir!!!!
As far as this guy's use of the word game, maybe English is his second
language, or he actually enjoys his work as a network manager, and it is a game
to him. I don't know him. Some people enjoy troubleshooting. I do. I already
commented on the LAN Analyzer part.
>>If the network manager knew everything that was on their network they
>>wouldn't need a damn probe!!!
You use the damn probe to find out every thing that's on your network!
>>The probe should track all protocols
>>by default and report what it finds.
The probe is a hard disk-less hub module. What the system design constraints
are, I don't know, but each tracking of a protocol consumes memory, and it is
finite. I know that the number of different kinds of RMON features, like
domains, matrix tables, host lists, network addresses, counters, packet capture
buffers, do consume a lot of memory, especially if multiple management stations
are using them. Resources are finite, so you have to experiment with your
particular site.
>>So with regard to your rather feeble and ill thought out response, I
>>beg to differ with you and put this right back on your plate or
>>Frontiers since they write the software....it is a probe problem.
The design of the probe's data collection features are dictated by the RFC.
Complain to them for the data representation short comings, and blame the probe
hardware designers, for not including 64 Meg of RAM in the probe.
>>You go tell each customer that you sell these damn things to that they
>>need an army of programmers to setup their tools just to be able to
>>tell them what is happening on their network. I hope you're well
>>padded because I would expect you to land on your backside by being
>>booted out of the site!
It is a less than friendly tool, and the documentation on how to get at its
extensibility is non existant, for all practical purposes, but if you know how
to use it, and where its place to use it is, then it can tell you a lot about a
stable network so that you can prevent problems from happening, or diagnose
different situations that do not affect the travel of SNMP packets. But if the
net can't carry SNMP, its not the probe's design's fault, and anybody's probe
would be S**T out of luck. You also don't need to be a programmer, you do have
to do a lot of digging and packet grabbing to get the information you need, and
that is the state of RMON-compliant tools today, as far as I know.
There is another package that is not RMON compliant. It is VMS based, called
the Network Professor, by Technically Elite Concepts. We have some discount
arrangement with them, and NIS uses them extensively, or used to. It is a
client-server architecture like RMON and Probewatch, but not RMON compliant.
TEC does make an RMON probe, but I sell my customers Packetprobes. And I
collect consulting dollars setting them up. Your customer doesn't need "an
army of programmers", they just need you. And you can bill them. If they don't
know anything about RMON, they will probably have to hire somebody to set up
whatever probes they use. They might as well hire you. If management hasn't
priced you out of your customer's range. And the way you keep from getting
booted out is to position Probewatch as a network managment, not a network
repair tool. You can't manage something that is broken, as working for this
company has taught me.
I've sold nine probes to my customer, and they love them, because I know how to
extend the product to give them the reports that they desire, but I also
constantly remind them that RMON only works on a stable network, and they also
need a LAN Analyzer for when things break. If you can't convey that to them,
or they refuse to get that, there is nothing you can do to avoid being booted.
-Craig
|