0

Is there a best practice for configuring the sampler rate for interfaces that will be sending netflow data. I have tested on our Nexus 7000 with the mode 1 out-of 1000 on interfaces that are seeing very little traffic (see below)

60 seconds input rate  345 packets/sec

60 seconds output rate  23 packets/sec

But I now want to add it to possibly eight interfaces (we have four Nexus 7000s with two interfaces on each that need monitoring) that are Internet facing and seeing much greater traffic (see below one example)

60 seconds input rate  100153 packets/sec
    
60 seconds output rate  10745 packets/sec

Will the sampler rate mode 1 out-of 1000 be adequate here? Or will it be too much? CPU on each Nexus is between 10 and 15%. I am also worried about the Netflow server being swamped. My crude calculations say that I could expect 800 packets a second across all interfaces which seems a lot.

Thanks, P

1
  • There is no "best practice." You don't want to overrun your Netflow receiver -- that should be your upper limit. The rest depends on what your needs are.
    – Ron Trunk
    Apr 27, 2021 at 12:08

1 Answer 1

0

It depends entirely on what kind of LC you're using. Much older LC's like the M1 and M2 can run sampled or un-sampled but there are limits to how many packets per second the processors on the LC and supervisor can track and generate. The newer blades (F2/F2e/M3 and presumably F4) have to run sampling and have minimum limits (i.e. no more than 1 in 100 or so) as well as being limited to a certain number of packets per second. In turn, the system has limits in terms of the total number of flows kept in memory at a given time as well as how many exports can be put on the wire per second.

The line cards (..or the various ASIC's on line cards) can generate flow entries up to a certain number of packets per second. These flows are sent over the EOBC to the system's cache on the CPU. The rate at which those collectors generate flows dictates how quickly that that flow cache fills up. A few gigantic long-lived flows uses a tiny amount of memory. Relatively low bandwidth filled with packets from constantly varying sources and destinations can blow the cache out surprisingly quickly. There's a maximum rate at which the CPU can generate flow exports on the wire, but within that the rate of flows being generated is a function of both the table's size and the average lifespan of the flows. Again - a box that's pegged with long-lived elephant flows won't tax either the cache or the CPU, while traffic generated with random sources and destinations can max the entire thing out surprisingly quickly. Sampling attempts to address these issues (the rate at which traffic is analyzed and the number of flows the CPU sees and exports).

So would 1 out of 1000 be adequate with that traffic flow? It's hard to say without knowing the nature of the traffic and the line cards in use. If you're distributed across SoC complexes on F3's? Almost certainly fine. If it's all on a single F2 blade? Probably not.

Cisco's documentation gets into the specific detail for the various LC's and system limits. I'd suggest using that as a starting point.

1
  • Thank you, I had not seen the Cisco document which does begin to explain how it all works. What is a bit confusing is our max sampling rate is 8191 which Cisco says is for F2 and F2e but our modules are N77-F348XP-23 which I believe are F3 so should have a maximum rate of 131071. I have set the rate to 1 out-of 5000 and will work down from there if its needed. Apr 28, 2021 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.