Leslie:
This is all good info, however, I have opened PMR93117 with Tivoli on the
cat5500 with the RSM card. After I applied & accepted PTF U453385 on
AIX/Netview V4.2.1, netmon does core every time it discovers a switch. As a
temporary solution, I had a cron running every 20 minutes re-starting netmon,
then we notice the CPU on the cat5500 was getting up to 98% every 20 minutes.
CPU utilization for snmp within the switch gets up to 48% driving the switch to
98% total CPU utilization.
So, the new temporary solution is NOT to do discovery of the cat5500 switches.
I am still waiting on Tivoli for a proper solution. It been 3 weeks+ since I
opened the PMR.
Here is a list of the in-house switches.
Router Name IOS Version # of VLANs Configured
---------------- ---------------
-----------------------------
FF5500-1-RSM - 11.2(13)P 28
FF5500-2-RSM - 11.2(13)P 21
SD5500-2-RSM - 11.2(13)P 38
GV5500-1-RSM - 11.2(13)P 13
GV5500-2-RSM - 11.2(13)P 14
Gil Irizarry
280 King of Prussia Road
ST. Davids, PA 19087
Phone: (610) 902-3426
INTERNET: IRIZARRG@LABS.WYETH.COM
>>> Leslie Clark <lclark@US.IBM.COM> 10/24/98 03:30pm >>>
>I have a customer with NetView v4.12 who has several Cisco 5500 switches in
>a VLAN configuration. NetView
>is not handling the discovery and mapping of this environment well at all,
>Is this an unsupported environment with
>NetView V4? Is it fixed in NetView v5? Any one with this environment have
>comments on using NetView to manage the
>5500s?
You don't say how it is handling it, or what you expected it to do.
All you should expect Netview to do with this is draw it, preferably at the
Network submap level, in the
subnet appropriate for the ip address and mask of its interface card. There
should be no difference
between Netview versions, I think, in the handling of this. I suspect that
they are being discovered as
unknown snmp Object IDs and placed (as generic boxes) in the segment level
submap, as if they were
PCs or something.
In all cases I expect that you will have to add the agent to the agents list in
/usr/OV/fields/C/snmp_fields
and run ovw -fields, then update the oid_to_type file using 'smit nv6000 ..
configure', enterng the oid,
selecting the vendor (cisco) and agent (you just defined it) and setting the
type to H or B. (There is no
special entry for Switch, I just pick H or B and that gets it promoted from the
Segment submap to the
Network submap, the same way G promotes things to the Internet submap). Once
you call it a H or B,
Netview will automatically assign an approprate symbol for it. If you load
CiscoWorks, it provides its
own bitmaps, but some of the later devices, or later releases of Cisco os have
different OIDs that even
Cisco does not provide bitmaps for. Anyway. But if you want a different symbol
than Netview assigns,
configure oid_to_sym to assign it a different one. (Look at Help...Legends on
the top toolbar to see what
is available). To get these changes applied, it is usually quickest to just
delete and rediscover the device.
Now, all of this is really just cosmetic. Netview handles all such devices in
the same way, and does not
provide any special topology handling for switches, bridges, or hubs that
would, for instance, divide
IP subnets and associate end nodes with such devices. So there is nothing to
'not support', as long
as the device provides an entry in the MIB II interface table for the address
you know it by.
Cordially,
Leslie Clark
IBM Global Services - Network & Systems Management - Detroit
|