[Top] [All Lists]

Re: switched environment support -Reply

To: nv-l@lists.tivoli.com
Subject: Re: switched environment support -Reply
From: Chris Cowan <chris.cowan@2ND-WAVE.COM>
Date: Tue, 9 Feb 1999 12:36:28 -0500
Organization: 2nd Wave
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Hal Dorsman wrote:
> This has been on my wish list for a long time.  Presently it does not.
> IMHO, IP-centric autodiscovery is obsolete.  What about it Tivoli experts?
> Any hope for a layer two discovery soon?
> Hal
> >>> Matt Ashfield <mda@UNB.CA> 02/09/99 10:41am >>>
> Hi,
> I am wondering if Netview provides a mechanism or add-on to support
> MAC-Address based network configuration. For example, the way
> Netview works for us now, say we have a Network segment (Net 160),
> with pc's connected to it. When a node goes down, we know it is on 160
> and where it is physically located.
> ------+-----------+--------+--------
>        |            |         |
>    Net 160    pc      xxx
> We are moving to a switched environment, based on MAC-Addressing.
> So a PC on Net 160 connects to an 8271 (8271A below) device which in
> turn is connected to an 8274 (8274A) device. This 8274 device could be
> connected to other 8274's. The pc is part of the virtual network 160
> defined in the 8274 device. If we move the pc to another physical
> location, and connect to a different 8271(8271B) which connects to a
> different 8274 (8274B) the pc can still be part of the vlan 160. If the pc
> goes down, it will show as such in the 160 segment, but we will have no
> way of knowing where that node is physically connected.
>   pc   ===>  8271 device A    --move--     pc  ==>  8271 device B
>                         /                      pc              /
>                        /                                       /
>          8274 device A       connected       8274 device B
>               net160          <========>       net160
>                netX                                        netX
>                netXX                                      netXX
> Does Netview provide any support for this? If not, is there an add-on
> product?
> Thanks,
> Matt
> mda@unb.ca

I concur but with a caveat.

When I worked at IBM Austin (almost 3 years ago) we had a significant
amount of shared media (mixed with FDDI and ATM on the backbone).   We
had a vendor (whom I won't name) claim that they could do a layer two
discovery from a centralized station.   It failed miserably.

There are two things that I learned while in this environment, which I
feel are still true.
- Distributed polling and discovery is ALWAYS preferable to attempting
it from a centralized station.   There is a certain scale beyond which
this function has to be distributed.
- Switched media makes life and things like discovery much easier.
However, a lot companies don't just rework their infrastructure in one
step.  So accommodated mixed switched and shared environments is going
to be a requirement for a while.
- The discovery process could depend a lot more heavily on the managed
devices themselves.  A managed hub or switch should be able to give me a
lot of info, without having to "walk" the network and knock on each
nodes door.   If the method is available and more optimal, it would be
nice if the Manager used it.

I'd like to see either:
- Pluggable snap-in discovery methods to netmon.  Making the various
methods selectable.
- Expand nvsniffer to move both up and down the protocol stack.

I'd also like to see better utilization of non-DNS naming.   In other
words, use nsswitch.conf to enable the NV Manager (even a UNIX based
one) capable of resolving WINS names.  (Unfortunately, when I mentioned
this on the TME 10 list, some people at Tivoli had a heart attack ;)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web