Troubleshooting 6509 - SUP720 - ip accounting

Hi all,

actually I was troubleshooting the following _problem_ ...

For some days I change in a cat 6509 the supervisor from SUP2 to a SUP720. After the change the customer tell me that ip accounting doesn't work as before ...also he tell me bevor the change he saw much more packets...input and output.... For my understand I can _only_ configure _output_ packets !?

So now if I doesn't find a solution the best way to track ip packets is to use netflow !?

Any commentaries are welcome....;-))

greetz dennis

Reply to
dennis
Loading thread data ...

I'm surprised if ip accounting did much useful on this platform. I'm pretty sure it is only implemented in the "software forwarding" slow path in the MSFC.

Maybe the Sup720 is able to forward more packets in hardware than the Sup2 (a good thing), so ip accounting now sees less traffic.

Don't know... we stopped using ip accounting a few years ago.

Netflow is definitely something to look at. The Sup32/Sup720 implementation is very nice and has hardware support to allow running at line rate for both IPv4 and IPv6 (although if the number of flows exceeds the size of the hardware table(s), packets will be skipped by Netflow).

The problem is that you need software to analyze Netflow data, but then there are many tools available. Check out

formatting link
Hope this helps,

Reply to
Simon Leinen

Netflow seems the way to go since you get more detail if you need it, but a good collector / display system can give all the stats you might want for complete interfaces, just TCP and so on.

i have done some testing on a sup720-3b and a system with DFC-3b equipped blades.

netflow stats collect seems to be in hardware once the flows are set up.

we were doing meshed flows between 2.5k IP routes with 10 devices per subnet via a traffic generator - no significant s/w load apart from when all the flows start up pretty much simultaneously.

1 thing to watch is how much instrumentation traffic you might generate - one of the Cisco white papers talks about 1.5% of measured traffic worst case. so 50+ GigE ports on a switch starts to look like you need to monitor the Netflow traffic, and maybe more than GigE to carry it....

also try

formatting link

Not used the latest netflow V9 yet - but it conforms to a new draft RFC and adds a few nice extras, such as monitoring multicast.

Reply to
stephen

Hi Simon,

thanks a lot for your explanation... I also think that netflow is the better way...right now I need to speek with our customer what we would like to do..

greetz

dennis

Reply to
dennis

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.