[nv-l] Playing with 7.1.4 and Switch Analyzer - early days

[Leslie Clark <lclark@us.ibm.com>]

I just put in a new 7.1.4 system on AIX 5.2 with Switch Analyzer 1.2.1 and the required patches for that. I saw a few things that I am not ready to call problems yet, but which I wonder about. Maybe it is working differently for others, which would be good to know.

A) Usually I forget to update if_to_sym for Frame Relay (type 32) and the Networks symbol file to add IP capability to the Frame Relay network symbol until after discovery. And usually, after making these updates, all I have to do is close and open the map and the symbols change. With 7.1.4, I had to rediscover before the symbols changed. Hmmm.

B) I made a location.conf after the initial manual cut and paste of the map, and did my usual 'File..New Map', and it went a little nuts. There were mistakes in the first attempt related to the order. After correction, and another 'File..New Map', it refused to make the locations because there already existed objects of type 'location' with those names. I could not get it to honor the location.conf until I flushed and rediscovered. Hmmm.

C) With RFI enabled,  with a big switch in the center, when the far ends of the serial links go down, the core switch usually shuts down its end as well. RFI then reports that the remote router is Down, then Unreachable, and the core switch is Marginal. Which is misleading since it appears that the core switch is at fault when it is not.  At this site, with 7.1.4 (and maybe ITSA is involved), I am no longer getting the Router Marginal for the core switch. Netview does report the remote router Down, then Unreachable, and the serial subnet is Unreachable, and the core interface Down, but no Marginal event for the core switch.  I did see Router Marginal for other routers in the map. Maybe ITSA ate it? I wonder if this was intentional, to help with the event correlation. I could now act on Router Marginal, Down, and Unreachable without inadvertently reporting the core switch. This could be a nice thing, it it holds up.

D) WARNING! By default, and this is in the release notes, snmpCollect is polling a ton of stuff from everything imaginable. I seemed to have a lot of trouble turning it off. Is it possible that it was being turned back on automatically? (Is it possible that the customer was playing with it at the same time?) At any rate, it is configured to pull cpu from every Cisco device, but as far as I know, only the routers support this mib. And it pulls it every hour, when the variable is a rolling 5 minute average.  It is pulling a lot of stuff from all Routers, which will at most sites include a lot of servers. I am delighted to see so many mib variables pre-added to the list of collectables, and I assume that turning them all on is intended to ready us for populating Tivoli Enterprise Data Warehouse, but with so many customers running switches with 100-200 virtual interfaces these days, that kind of polling can be a bit much. Especially in the!
  absence of an automated purge of collected data on Unix. 

I'll be trying all of this again at another site next week. It will be interesting to see if I it works the same there with all different equipment but the same old practitioner.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit