Re: MIB-II on proxied chassis entities.

kzm@hls.com (Keith McCloghrie) Sun, 19 July 1992 01:55 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA21152; Sat, 18 Jul 92 21:55:09 -0400
Received: from LANSLIDE.HLS.COM by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21148; Sat, 18 Jul 92 21:55:05 -0400
Received: from nms.netman (nms.hls.com) by lanslide.hls.com (4.1/SMI-4.0) id AA18764; Sat, 18 Jul 92 18:55:22 PDT
Received: by nms.netman (4.1/SMI-4.1) id AA03131; Sat, 18 Jul 92 18:45:00 PDT
From: kzm@hls.com (Keith McCloghrie)
Message-Id: <9207190145.AA03131@nms.netman>
Subject: Re: MIB-II on proxied chassis entities.
To: gallagher@quiver.enet.dec.com
Date: Sat, 18 Jul 92 18:45:00 PDT
Cc: chassismib@cs.utk.edu
In-Reply-To: <9207161448.AA17648@us1rmc.bb.dec.com>; from "gallagher@quiver.enet.dec.com" at Jul 16, 92 10:49 am
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]


> For example, say the Chassis Entity Table contain the following entries:
> 
> 	Agent:
> 	  chasEntityCommunity "public"
> 	  chasEntityIpAddress  16.21.16.128
> 	Proxied Entity 1:
> 	  chasEntityCommunity "lineCard1"
> 	  chasEntityIpAddress  16.21.16.128
> 	Proxied Entity 2:
> 	  chasEntityCommunity "lineCard2"
> 	  chasEntityIpAddress  16.21.16.128
> 
> so the agent is proxying for "lineCard1" and "lineCard2".
> 
> >From past discussions, the minimal MIB-II implementation has the system
> and snmp groups.  One could:
> 
>   1) Keep a per proxied entity system group and a per proxied entity 
>      snmp group.  So, the agent's snmp group counters count only 
>      those messages directed at 16.21.16.128 on community "public".
>      lineCard1's snmp group counters count only the snmp messages 
>      directed at 16.21.16.128 on community "lineCard1".   Similarly, 
>      lineCard2's snmp group counters count only those messages directed 
>      and 16.21.16.128 on community "lineCard2".
> 
>      In other words, there is an individual snmp group per community.
> 
>   2) Keep a per proxied entity system group, and a per proxy agent 
>      snmp group.  So, the agent's snmp group counters count all snmp
>      messages directed at 16.21.16.128 regardless of community.
>      The counters are the sum of all snmp traffic to "public", 
>      "lineCard1", and "lineCard2".  The view of "public" contains
>      the system, if, ip, etc., and snmp groups.  The view of
>      "lineCard1" and "lineCard2" contains the system and snmp groups.

My opinion is that since you have specifically labeled this situation as a 
case of proxy, the transparency principle should apply, i.e., the manager 
should notice no difference between retrieving data from the proxy agent, or
retrieving data from the real agent (irrespective of whether in fact 
there is a real agent).  So, if lineCard1 has a system group in its view,
it should be specific to lineCard1, and if it has a snmp group, it should 
only count the snmp requests which would (logically) be handled by the "real" 
agent.  Note that the proxy agent also processes those requests, so your
agent's native snmp group (you label it "public") should count them also.
Of course, if there isn't a real agent after all, one *might* argue that
lineCard1's view doesn't need to contain a snmp group.

Keith.