Re: [802.3ae] Query : 10G Ethernet RMON status !!!

[Geoff Thompson <gthompso@xxxxxxxxxxxxxxxxxx>]

Kamal

No, they are not the same.

At 04:09 PM 4/23/02 +0530, Kamal Jain wrote:
> Hi All,
>  
>     Can somebody clarify me on
> the following two definitions for Ethernet frames
>  
> - "aFramesLostDueToIntMACRcvError",
> section 5.2.2.1.15 from IEEE-802.3-2000 Std,
>  
> Definition : A count of frames that would
> otherwise be received by the station, but
> could not be accepted due to an internal MAC sublayer receive error. If
> this
> counter is incremented, then none of the other counters in this subclause
> are
> incremented.The exact meaning and mechanism for incrementing this
> counter is implementation dependent.

This counter is intended to provide a bucket so that all events on the
wire are counted. actually only all the events that make it past the
portion of the hardware that drops collision fragments and shorter
events. Any internal hiccup can use it. It is still a packet/frame
counter.


> -
> "etherStatsDropEvents", RFC 1757, Remote Network Monitoring
> Management Information Base (MIB)
> Definition : "The total number of events in which packets were
> dropped by the probe due to 
> lack of resources. Note that this number is not necessarily the number of
> packets 
> dropped; it is just the number of times this condition has been
> detected." 

This is a fudge counter that was created back when computing speed and
memory size were more of a problem. It is just a count of the number of
times that the RMON probe ran out of steam and lost track of what was
actually going on. This is not a packet/frame counter, this is a number
of times I have been broken counter.

>              
> ::= { etherStatsEntry 3 }
>          Are both the definitions
> same from the implementation point of view.
> For example, if we define the Ingress (Rx) FIFO overflow error as a MAC
> internal error,
> then can it be taken as the "lack of resources" in
> "etherStatsDropEvents".
> Otherwise, can the "etherStatsDropEvents" be defied as the drop
> events for packets which
> has been dropped/discarded because of some filtering options, while
> receiving an Ethernet frame.
>  
> Looking forward for an early
> response.
>  
> Rgds
> Kamal Jain [SMTS] 
> GDA Technologies Ltd.


Geoff Thompson