This is probably two separate issues, both of which I have contributed to my
graying hair over the years. Maybe I can clarify it a little.
1) Netview has never actively managed the status of unnumbered interfaces.
It is a feature, being the only thing I can think of that it will discover and
draw,
and then never manage again except during a demand-poll or configuration
poll. Usually these are unnumbered serial interfaces connecting remote
routers. Found via SNMP, but unpingable, so status never changes unless you
do it yourself with snmp polling. I was surprised to see an apar has finally
been
taken, since it has been this way since unnumbered support appeared in V3.
2)When Cisco implemented Frame Relay, customers started using the subinterface
feature. But Cisco did not populate the standard MIB II Interface table with
instances
for these subinterfaces until IOS 11.2. Until they did, Netview was usually not
able to draw connections between these subinterfaces. At 11.2 or better, it
draws
the connections beautifully, numbered or not.
You can have both of these problems at the same time. If you stick with
unnumbered,
you will still have the status problem even at 11.2 until a solution is
delivered
for apar IX81136.
One customer I know of circumvents the status problem by setting the map
to 'Propagate most Critical'. So the down numbered interface makes the parent
router red, even if those unnumbered interfaces stay green.
I hope this helps.
Leslie Clark
IBM Global Services - Network & Systems Management - Detroit
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Joe,
That's an interesting question - the Tivoli tech support person who opened the
APAR for my ticket did not even get into the Cisco IOS level. And as a matter
of fact, the router that we had the problem on was pre 11.2 (11.1(2)), so that
may be the problem. Thanks for the info,
Scott
Prokott, Joe wrote:
> Scott,
>
> I have been told by Tivoli that there was a bug if one was using pre 11.2
> Cisco IOS. Does your APAR below apply to post 11.2 IOS as well as pre? We
> are using 11.2(12), so I thought perhaps this problem was taken care of?
> Perhaps there was another separate issue with the pre 11.2 IOS? It
> definitely would be useful for us to be able to get color status in the NV
> GUI for frame-relay subinterfaces, and we thought NV may be able to provide
> this with the discovery of the "0.0.0.0" interfaces on our frame-relay
> routers. It would appear that perhaps Tivoli was trying to add this
> capabilty - or this just wishful thinking? Thanks,
>
> Joe Prokott - West Group
> Network Architect
> 610 Opperman Drive
> St. Paul, MN 55123
> Phone: 651-687-4536
> Fax: 651-687-6946
> E-mail: joe.prokott AT westgroup DOT com
>
> > -----Original Message-----
> > From: Scott Wilson [SMTP:swilson AT rpm DOT com]
> > Sent: Wednesday, September 02, 1998 9:33 AM
> > To: Prokott, Joe
> > Cc: NV-L AT UCSBVM.UCSB DOT EDU
> > Subject: Re: Cisco Frame Relay subinterface representation
> >
> > This is a bug in in NetView - it will not change the status of those
> > unnumbered
> > IP subinterfaces! If the router actually goes down (i.e. unplugged from
> > the
> > network), NetView will change the node to a marginal status (yellow), as
> > those
> > IP unnumbered (0.0.0.0) interfaces will stay green (there is apparently
> no
> > way
> > to get the status).
> >
> > There is an APAR opened on this: IX81136
> >
> > I have resorted to unmanaging those interfaces, as we had some routers
> > reload
> > and never saw it since the unnumbered sub-interfaces never changed color,
> > hense
> > we never received a Node Down event.
> >
> > HTH,
> >
> > Scott
> >
> > Prokott, Joe wrote:
> >
> > > Does someone understand how NV graphically depicts and updates status
> > > information for Cisco frame-relay subinterfaces? We have Cisco routers
> > > running IOS 11.2(12) and NV is able to discover the unnumbered (each
> > > subinterface is mapped to the router's loopback address to save on IP
> > > addresses) subinterfaces on these routers. NV labels these
> > subinterfaces
> > > as
> > > "0.0.0.0" at the interface card level within the NV submap.
> > >
> > > Now, it appears NV does not distinguish between the various
> > subinterfaces
> > > within the NV database? That is, when I select one of these "0.0.0.0"
> > > interface cards within the NV submap and do a Tools...Display Object
> > > Information..., there is no field(s) in the NV database that makes it
> > > apparent that this interface card represents the frame-relay PVC XXX as
> > > opposed to, say, another frame-relay PVC YYY defined on the same
> router?
> > > Why not? How/when is the status of these "0.0.0.0" interface cards
> > updated
> > > within the NV maps? Does netmon do some "special" (other than "ping")
> > > polling to update the status of these interface cards representing the
> > > frame-relay PVCs? If not, why do these interface cards even exist at
> > all?
> > > I assume these interface cards are put in the NV map so that some NV
> > > process
> > > could and would update the color based upon some condition(s) change,
> > > right?
> > > The question is what change would constitute a color change of these
> > > "0.0.0.0" interface cards within a NV submap? Thanks in advance,
> > >
> > > Joe Prokott - West Group
> > > Network Architect
> > > 610 Opperman Drive
> > > St. Paul, MN 55123
> > > Phone: 651-687-4536
> > > Fax: 651-687-6946
> > > E-mail: joe.prokott AT westgroup DOT com
> >
> >
> >
> > --
> > -----------------------------------------------------------
> > Scott Wilson Email: swilson AT rpm DOT com
> > Network Management Consultant Pager: 800-506-7348
> > RPM Consulting, Inc.
> > -----------------------------------------------------------
> >
--
-----------------------------------------------------------
Scott Wilson Email: swilson AT rpm DOT com
Network Management Consultant Pager: 800-506-7348
RPM Consulting, Inc.
-----------------------------------------------------------
|
