[nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the
Field
Ian Cox
icox at cisco.com
Mon Nov 24 22:33:07 EST 2003
Supervisor 2 can not provide counts for how much traffic is switched on a
vlan interface. Supervisor 720 can perform this functionality. In the
Supervisor 2 ASICs, the L2 multicast packet / octet counters and L3
multicast packet / octet counters share the same space. The ASIC allows
the selection of either; the sum of both L2M and L3M IN packets/octets or
only one set of them will be counted. So, we are faced with different
alternatives with different trade-offs. Currently, the code is set for the
sum of both. Whenever there is a L2 Multicast packet or there is a L3
Multicast IN pkt, the shared counter will always increase accordingly. The
reason for this choice is that it will cover all the SMON-MIB related
objects and most of IF-MIB related objects correctly.
Supervisor 2 Counters per vlan:
Vlan Id : 2
L2 Unicast Packets : 2895064
L2 Unicast Octets : 1582339457
L3 Input Unicast Packets : 0
L3 Input Unicast Octets : 0
L3 Output Unicast Packets : 0
L3 Output Unicast Octets : 0
L3 Output Multicast Packets : 0
L3 Output Multicast Octets : 0
L2 Multicast Packets + L3 Input Multicast Packets : 851823
L2 Multicast Octets + L3 Input Multicast Octets : 72999937
Supported MIB objects for Supervisor 2:
SMON-MIB objects
smonVlanIdStatsTotalPkts ,
smonVlanIdStatsTotalOverflowPkts,
smonVlanIdStatsTotalHCPkts,
smonVlanIdStatsNUcastPkts,
smonVlanIdStatsNUcastOverflowPkts,
smonVlanIdStatsNUcastHCPkts
IF-MIB object
ifInOctets,
ifInUcastPkts,
ifInNUcastPkts,
ifOutUcastPkts
CISCO-SWITCH-ENGINE-MIB object
cseL3VlanOutPkts,
cseL3VlanOutOctets,
cseL3VlanInUnicastPackets,
cseL3VlanInUnicastOctets,
cseL3VlanOutUnicastPkts,
cseL3VlanOutUnicastOctets,
Unsupported MIB objects for Supervisor 2:
These are unsupported because of the sharing of the L2+L3 multicast counters.
IF-MIB object
ifOutOctets
ifOutNUcastPkts
CISCO-SWITCH-ENGINE-MIB object
cseL3VlanInPkts
cseL3VlanInOctets
Supervisor 720 provides the following counters per vlan:
Vlan Id : 2
L2 Unicast Packets : 2669991
L2 Unicast Octets : 1597525877
L3 Input Unicast Packets : 0
L3 Input Unicast Octets : 0
L3 Output Unicast Packets : 0
L3 Output Unicast Octets : 0
L3 Output Multicast Packets : 0
L3 Output Multicast Octets : 0
L3 Input Multicast Packets : 0
L3 Input Multicast Octets : 0
L2 Multicast Packets : 366788
L2 Multicast Octets : 41615382
Supervisor 720 has separate counters for L2 + L3 multicast and therefore it
is possible to support the above values which are not supportable on
Supervisor 2. The reason why Supervisor 720 has these extra counters is
because of customer comments about the counters for interface vlan.
Counters take space on the ASICs or in external memories and logic in the
ASIC, for vlan counters alone on Supervisor 2 there are 4096 x 10 counters
and 1023 x 3 counters for policers. Supervisor 720 has 4096 x 12 counters
for vlans and 1023 x 3 counters for policers. The ASIC team regularly
lectures myself on how much space all the counters I keep requesting for
future versions of the Supervisor are consuming. The number of counters
provided is a function of the ASIC technology available to construct the
forwarding ASICs (gate count), cost (which relates to price you are willing
to pay), features, and knowledge of what customers want to count. It is
very easy to say we don't care about counters, but the reality is trade
offs have to be made between the four variables to build the forwarding
ASICs. We do care about counters, and we also care about the other three
variables. Knowledge of what customers want to count comes from talking to
customers and listening to your concerns on aliases like this one. That is
why Supervisor 720 resolves the issues Supervisor 2 has.
I would also like to correct another comment made by someone else in this
thread. The Catalyst 6500 (Supervisor 2, Supervisor 720), Catalyst 4500
(Supervisor, Supervisor 3, 4), Catalyst 3550, Catalyst 3750 are not flow
based switches. All these switches are CEF (FIB) based forwarding switches
and utilize TCAMs for ACLs.
Ian
At 08:53 PM 11/22/2003 +0100, Gert Doering wrote:
>Hi,
>
>On Fri, Nov 21, 2003 at 10:07:38PM -0500, Terry Baranski wrote:
> > I don't think it's unreasonable to view an SVI as a MAC address (with an
> > associated IP) that is used as a next-hop for packets leaving the VLAN,
> > and as a source for packets entering the VLAN. Using this perspective,
> > I'd argue that all such packets use the SVI whether they actually hit
> > the MSFC or not. Take the SVI away, and the packets stop flowing. So
> > the issue with SVI counters has never made sense to me, and is a major
> > inconvenience when you care about traffic stats.
>
>Full ACK.
>
>However it is done "under the hood" - that must be the net result: working
>counters that precisely document what went in and came out.
>
>gert
>
>--
>USENET is *not* the non-clickable part of WWW!
>
>//www.muc.de/~gert/
>Gert Doering - Munich, Germany gert at greenie.muc.de
>fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
>_______________________________________________
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list