Subject: RE: Using entPhysicalIndex

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 16 Aug 2001 11:27:45 -0500

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> >>>>> Ayers, Mike writes:

> I do not understand why the Entity MIB should define an algorithm
> for deriving its indexes.

	If the system reboots or enough cards are hotswapped, then an
entPhysIndex may not point to the same object that it did when the alarm
when off.

> Please take breath and explain. I certainly would love to know which
> port/module/... in my chassis caused an alarm.

	Okay.  We've got {TDomain, TAddress, ContextEngineID, ContextName}
pointing to our agent.  We walk its entLogicalTable and find our match.
Next, we use entLPMappingTable to find entPhysIndex, which we can use to
determine what the agent controls.

	So why not have entPhysicalIndex contained in the alarm?  Unlike
ithers I do not think that the Entity MIB will be very pervasive.  IMHO, it
only contains useful information when implemented in a multisegmented
behemoth.  For, e.g., a web server, you'll have a single entPhysIndex and
entLogicalIndex, single row mapping tables, and a single row stack table
that says "chassis".  Not terribly informative, so why implement?

> Mike> In order to determine the source agent for an alarm, we need to
> Mike> track four pieces of information: the TDomain/TAddress pair and
> Mike> the ContextEngineID/ContextName pair.
> 
> I do not think this was the subject of the debate - but I may 
> be wrong.

	It is and isn't.  We want to know how to track the source of alarms.
I contend that in the SNMP framework, we can only track the source of the
source of the alarms (i.e. the agent that sent them) and must rely on higher
level logic from there.

> [All identifiers we have only have a certain amount of stability.
>  Having TDomain/TAddress does not help if you change the IP address
>  after the alarm occured...]

	Agreed - but that can be mitigated by not using DHCP.  Reboots can
only be mitigated to a certain extent...  :-)

/|/|ike

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Aug 2001 01:17:47 +0200

>> for deriving its indexes.

Mike> If the system reboots or enough cards are hotswapped, then an
Mike> entPhysIndex may not point to the same object that it did when
Mike> the alarm when off.

I think implementations that change entPhysIndex on reboot when
nothing else has changed are kind of unfortunate. On the other hand,
if you swap cards, then it is quite normal that identifiers change or
get different meanings. If I replace my PCMCIA network card with
another card, I will get a new MAC address. Statistics recorded before
that event will loose meaning. Such is life. The good news is that you
will get an entConfigChange notification so that you can track these
events.

I agree that Entity MIB implementations should use an algorithm which
does not unnecessarily renumber things. But how this algorithm looks
like is implementation specific I guess and hard to put into a
standard.

>> Please take breath and explain. I certainly would love to know
>> which port/module/... in my chassis caused an alarm.

Mike> Okay.  We've got {TDomain, TAddress, ContextEngineID,
Mike> ContextName} pointing to our agent.  We walk its entLogicalTable
Mike> and find our match.  Next, we use entLPMappingTable to find
Mike> entPhysIndex, which we can use to determine what the agent
Mike> controls.

Mike> So why not have entPhysicalIndex contained in the alarm?

I think this is exactly what this thread started with.

Mike> Unlike ithers I do not think that the Entity MIB will be very
Mike> pervasive.  IMHO, it only contains useful information when
Mike> implemented in a multisegmented behemoth.  For, e.g., a web
Mike> server, you'll have a single entPhysIndex and entLogicalIndex,
Mike> single row mapping tables, and a single row stack table that
Mike> says "chassis".  Not terribly informative, so why implement?

If you implement a monolithic web server agent. (The WWW-MIB in RFC
2594 is more or less designed to be implemented by sub-agents.)
Anyway, a failure of the web server is most likely reported as a
software problem, even if it is caused by an underlying hardware
failure. So the source of an alarm from the web server would most
likely be a running process identifier - and of course, process
identifiers are only significant during a certain period of time.

/js