Re: Re: 3.0 features

From: Tim Durack (tdurack@yahoo.com)
Date: 05/13/03

  • Next message: Tim Durack: "Monitor applet"

    So I can create IPV4 protocol groups too? What about Ethernet etc?

    On a separate 3.0 issue, I have noticed that a monitor applet feature
    appears to have gone away:

    http://server/its/monitor?address=0x000102010203&addressType=MAC

    This link used to display a top connections chart for the switch port
    associated with this MAC (or IP address etc)

    This doesn't seem to work anymore - now I have to do something like
    query IP->MAC->Switch port, and then generate a link using that queried
    information:

    http://server/its/monitor?agent=10.1.0.10&interface=1

    This introduces an extra step. Did I miss something?

    Tim:>

    --- Neil McKee <neil_mckee@inmon.com> wrote:
    > > Having set up some protocol groups, I am now running into the
    > situation
    > > where reports show both "TCP.other" and "TCP.Other"
    > >
    > > This looks rather strange in the report. I assume this is happening
    > > because of an interaction between protocolGroups and resultTruncate
    > (I
    > > have resultTruncate=5 in these reports)
    >
    > Yes, I see what you mean. "other" is a protocol group classification,
    >
    > while "Other" means that resultTruncate kicked in. It would perhaps
    > be
    > better if "other" could just be accumulated into "Other"...as long as
    >
    > that didn't blur the distinction between TCP.other and UDP.other and
    > IPv4.other. It's a tricky one that will need some thought!
    >
    > > I can try to workaround it by increasing the number of
    > protocolGroups,
    > > so that TCP.other doesn't have much in it. However this is
    > extremely
    > > error-prone when there are large numbers of clients using services
    > not
    > > running on well-known ports, using RPC for example...
    > >
    > > Any suggestions as to how I can avoid this?
    >
    > Not at the moment, sorry.
    >
    > > p.s. According to IANA TCP well-known ports are 0-1023, the default
    > > configuration has these mapped 1-1024. Should it really be 1-1023?
    >
    > Yes. 1-1023 is more correct. Thanks for pointing this out.
    >
    > neil
    >
    > --
    > Neil McKee, InMon Corp.
    > tel: +1 (415) 661-6343
    > http://www.inmon.com
    >

    __________________________________
    Do you Yahoo!?
    The New Yahoo! Search - Faster. Easier. Bingo.
    http://search.yahoo.com

    This archive was generated by hypermail 2.1.4 : 05/13/03 PDT