I was thinking on this topic and came up with the list of things to do on a 6500
to get stats on a per vlan basis (which cisco will not give you)
1. Get NDE stats from MSFC(router) on a per interface basis (this works by
2. Get NDE stats from Sup(switch) on a per port basis and convert to a per
interface basis. You must enable S-D flow mode on the switch. IT also requires a
mapping of ports to vlan. However if you use trunking (and most users do) then a
port will not map to a single vlan so.....
2a. Use the rout tables to help predict on what vlan traffic is on based on
the S/D IP address. For many networks this is fairly static. However spoofed
address will cause a problem (as will multicast). Cisco's RPF check can help
prevent spoofing, but it does not work with MLS (yet).
3. Combine the NDE data from the router to help predict what ports the traffic
on the switch is using. The router gives the source/destination address and
vlan. You can keep this information around for a while and if you get a flow
from the switch with the same ip information you can predict that the vlan
information is the same. The switch maximum flow time (set mls agingtime
long: hidden command) will have to be set about the same as the routers and you
will have to manage a fairly large cache, but this should work regardless.
We have several 6500 in our core and we use a combination of all the methods but
#3 to obtain L3 stats. If #3 works it might be the best since you don't have to
worry about changing route table etc..
University of Texas at Austin
On Thu, 9 Nov 2000, Jeffrey Papen wrote:
> We run only IP traffic. I'm not sure how DecNet or other protocols would work out. Unfortunately, my stats are far from perfect because NetFlow will only see the first packet. Everything else in the flow is hardware switched at layer 2. For perfect stats, I would need to have a GSR or some other layer3 only router that will pass all packets through the ip route-cache flow collecting.
> - Jeffrey
> Andrew Fort wrote:
> > > I'm doing identical polling and have not experienced problems
> > > with ifIndex not matching up. However, I have had long talks
> > > w/ Cisco about the MSFC switching method only allowing for
> > > the first packet of any flow to be recorded and then having
> > > the rest switched at layer2 (outside NetFlow's view).
> > >
> > > The way I solved this was using the 64 bit HC counters to
> > > poll the Gig interfaces corresponding to the uplinks I'm
> > > getting NetFlow data from. I use NetFlow to calculate a
> > > rough % and then multiply this by the SNMP MB/sec average for
> > > an average Mb/sec to a given AS.
> > Is all of your traffic hardware switched? If not, how do you handle the
> > flows which are always software switched (DECnet traffic, for instance) in
> > your calculations (this is difficult only if you mix IP and DECnet traffic
> > routed on the same interface)?
> > --
> > afort
> > --
> > cflowd mailing list
> > firstname.lastname@example.org
> Yahoo Network Engineering
> email: email@example.com beep: firstname.lastname@example.org
> work: 408-616-3897 fax: 408-530-5307
> cell: 650-580-2684 page: 408-619-0572
> Yahoo Messenger ID: jpapen
> cflowd mailing list
-- cflowd mailing list email@example.com
This archive was generated by hypermail 2b29 : Thu Nov 09 2000 - 18:37:30 PST