Re: [nsp] unable to collect interface stats on 6905 MSFC2

From: Dmitri Kalintsev (dek@hades.uz)
Date: Wed Mar 13 2002 - 18:51:15 EST


On Wed, Mar 13, 2002 at 10:00:07AM -0800, matthew zeier wrote:
>
> This actually makes it difficult to do bandwidth-based billing with the
> Sup2.
>
> I've been eval'ing InMon's Traffic Server but I'm not seeing the sort of
> traffic numbers I'd expect to see.

You can export MLS NDE (netflow) from your PFC, which comes in 3 flavoors:
v1, v7 & v8. Welcome to the club. ;)

P.S. Don't come back asking for more info - I'm lucky enough not to deal
with writing billing info systems. ;)

> - mz
>
> ----- Original Message -----
> From: "David Sinn" <dsinn@microsoft.com>
> To: "Dmitri Kalintsev" <dek@hades.uz>; <cisco-nsp@puck.nether.net>
> Sent: Wednesday, March 13, 2002 9:38 AM
> Subject: RE: [nsp] unable to collect interface stats on 6905 MSFC2
>
>
> It depends on what PFC you have (thus what Sup you have).
>
> If you have a Sup1A then you have a flow based PFC. Thus the first
> packet of every new flow goes through the MSFC so that a flow entry can
> be pushed down to the PFC.
>
> If you have a Sup2 then you have a CEF based PFC. Thus almost no routed
> traffic will pass through the MSFC.
>
> The exceptions on both methods are any and all packets actually destined
> to the routing engine (snmp, routing protocols, telnet, ICMP, ARP, etc.)
> and any and all packets that need anything done to them other then
> normal routing (TTL expire, options bits set, etc.).
>
> I have yet to be able to confirm the assertion about CatOS 7.1 does
> anything different.
>
> David
>
> -----Original Message-----
> From: Dmitri Kalintsev [mailto:dek@hades.uz]
> Sent: Tuesday, March 12, 2002 8:54 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [nsp] unable to collect interface stats on 6905 MSFC2
>
>
> On Fri, Mar 01, 2002 at 10:57:12AM -0800, Nash Darukhanawalla wrote:
> > This is because the packets are L3 switched in the hardware by the
> > PFC.
>
> Related question: what traffic _is_ getting switched by MSFC? Is this
> snmp/routing protocol/netflow export from msfc/cdp/telnet/ssh traffic to
> or from MSFC itself or something more? If it is more, than what is it?
> Is statement about 7.1 and visibility of MLS/SEF switched traffic on
> msfc (when run in hybrid mode) true?
>
> Thanks!
>
> > Due to the CEF based architecture of the SUP2 / MSFC2, the MSFC2
> > processes
> > routing updates, creates FIB and ADj tables. These tables then get
> > downloaded to the PFC hardware so that it can do local CEF lookups.
> Sup2
> > also maintains the Netflow table to provide flow statistics.
> >
> > Please refer to this document on configuring NDE to monitor L3
> > switched
> > traffic:
> >
> http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_3/confg
> _gd/nde.htm
> >
> > Nash
> >
> >
> >
> > At 07:24 AM 3/1/2002 -0800, matthew zeier wrote:
> >
> > >I'm trying to run cricket against the Vlan interfaces on a 6905
> > >"router" and have noticed that IfOutOctets and IfInOctets barely
> > >incremenet, if at all. They do, however, if I query the switch but
> > >often customers are spread across several switches/switch ports and I
>
> > >wanted any easy way to grab inter-Vlan bandwidth.
> > >
> > >Running 12.1(8a)E2 and 6.3(3) .
> > >
> > >Any ideas?
> > >
> > >--
> > >matthew zeier - "In mathematics you don't understand things. You
> > >just get used to them." - Johann von Neumann
> ---end quoted text---
>
> --
> CCNP, CCDP (R&S) Dmitri E. Kalintsev
> CDPlayer@irc Network Architect @ connect.com.au
> dek @ connect.com.au phone: +61 3 9674 3913 fax: 9251 3666
> http://-UNAVAIL- UIN:7150410 cell: +61 414 821 382
>
>
---end quoted text---

-- 
 CCNP, CCDP (R&S)                          Dmitri E. Kalintsev
 CDPlayer@irc               Network Architect @ connect.com.au
 dek @ connect.com.au    phone: +61 3 9674 3913 fax: 9251 3666
 http://-UNAVAIL-         UIN:7150410    cell: +61 414 821 382



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:08 EDT