[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [802.1] [802.1AB]: Problem with the lldpXdot1RemProtoVlanEntry table inde x
Hi,
I don't believe the zero usage is the problem, but your mail has been
sent to the RMONMIB WG and the MIB Doctors of the IETF for
consideration.
I suspect the lldpRemTimeMark (a TimeFilter) is the problem you are
experiencing.
TimeFilters are known to cause infinite loops, depending on how the
GetNext code has been implemented in the agent and manager.
I do not know of any definitive text that explains how to avoid this
problem.
The RMONMIB WG is the correct place to discuss this issue, since they
control the definition/interpretation of the TimeFilter.
I believe the RMONMIB WG has chosen to not fix the get-next-forever
problem, because it would impact the advancement of the RMON2-MIB
through the IETF standards advancement process.
The RMONMIB WG considered adding an object that helped to characterize
the "mode" of implementation of an agent, to help solve the problem.
The RMONMIB WG chose to not add this object to the RMON2-MIB, because
it didn't actually fix the problem.
The description may help you to understand the issue and to check the
implementation you are working with.
From the RMONMIB WG archive,
http://www.ietf.org/mail-archive/web/rmonmib/current/msg00672.html:
------- archive message #672 --------------
Hi,
The RMONMIB WG decided at the last IETF that the timeFilter
get-next-forever
problem should be fixed. I am proposing the following MIB object,
which
should be added to the RMON2-MIB module. It could either be added to
the probeConfig group or added to a new group. The MIN-ACCESS of this
object would be read-only.
timeFilterMode OBJECT-TYPE
SYNTAX INTEGER {
stopAfterOne(1),
stopAfterAll(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the way the SNMP agent implements the
getnext operation for tables with a TimeFilter index, such
as those found in the RMON2-MIB module.
If this object has the value `stopAfterOne(1)', then a
GetNext
or GetBulk operation will provide one pass through a given
table,
i.e., the agent will continue to the next object or table,
instead of incrementing a TimeMark INDEX value, even if
there exists higher TimeMark values which are valid for
the same conceptual row.
This mode is not strictly compliant with the TimeFilter
textual
convention definition, because potentially many conceptual
rows
will be skipped instead of returned in a GetNext or GetBulk
operation. Such rows are identical to each other, except for
the returned TimeMark INDEX value. This mode is intended only
for testing purposes, however it may also be useful if an NMS
wishes to utilize the GetBulk PDU. This mode will prevent the
GetBulk responses from containing duplicate rows due to the
TimeFilter mechanism.
If this object has the value `stopAfterAll(2)', then a
getNext
or getBulk MIB walk will repeat through the same MIB table
until
the TimeMark for the most-recently changed entry is reached.
Note that as long as traffic occurs on the monitored
interface,
it is possible a highest value of the TimeFilter INDEX may
never be reached. This mode is strictly compliant with the
TimeFilter textual convention definition. Note that GetBulk
PDU responses in this mode will likely contain multiple
copies
of the same MIB instances, differing only in the TimeMark
INDEX
value.
As an example, consider row 'fooEntry' which was last updated
at 'time 1000'. An NMS may use any TimeMark INDEX value in
the
range '0' to '1000', and the current (i.e., time of get
request)
counter values for the 'fooEntry' will be returned by agent.
In the 'stopAfterOne' mode, the agent will not increment
the fooEntry TimeMark index under any conditions. In the
'stopAfterAll' mode, the agent will increment any fooEntry
TimeMark INDEX value in the range '0' to '999', up until
the TimeMark value of '1000' is reached."
DEFVAL { stopAfterAll }
::= { probeConfig 15 }
_______________________________________________
RMONMIB mailing list
RMONMIB@ietf.org
https://www1.ietf.org/mailman/listinfo/rmonmib
----------------------------------------------------------------------
----------
Prev by Date: [RMONMIB] I-D
ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt
Next by Date: RE: [RMONMIB] proposal to fix TimeFilter problem
Previous by thread: [RMONMIB] I-D
ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt
Next by thread: RE: [RMONMIB] proposal to fix TimeFilter problem
Index(es):
Date
Thread
> -----Original Message-----
> From: IEEE 802.1 [mailto:hdk-0117.pgqfwd@att.net] On Behalf
> Of Eelco Chaudron
> Sent: Thursday, January 20, 2005 2:35 AM
> To: STDS-802-1-L@LISTSERV.IEEE.ORG
> Subject: [802.1] [802.1AB]: Problem with the
> lldpXdot1RemProtoVlanEntry table inde x
>
> Hi All,
>
> When implementing the dot1 extension MIB I was running into a
> problem with
> the lldpXdot1RemProtoVlanTable.
> The table has the following indexes:
> - lldpRemTimeMark
> - lldpRemLocalPortNum
> - lldpRemIndex
> - lldpXdot1RemProtoVlanId
>
> The problem lies within the last index,
> lldpXdot1RemProtoVlanId. This can
> have a value of zero, and would be causing an infinite loop
> when doing SNMP
> getnext operations.
>
> To my understanding a SNMP index can never have a value of zero, as
it
> indicates to SNMP to get the first value.
>
> How would we hande this? For example not returning entries in the
> lldpXdot1RemProtoVlanTable wich have a vlanid of zero? Or
> report the zero
> values as 4096?
>
> Regards,
>
> Eelco
>
> IEEE 802.1 list info:
> http://www.ieee802.org/1/email-pages/etkg1204.html
>