I have a softflowd instance running on my router sending it's data to my server. It's pretty CPU intensive, although the router is an 8-core x86_64 and can handle it no problem.
I thought instead to mirror the port on my switch that is connected to my router 's LAN interface to the port connected to my server's second ethernet interface and run the softflowd directly on the collector machine instead. This means one less thing to manage directly on the router....
I was just trying to work through mentally which of the two would be the better option performance-wise: run the softflowd directly on the netflow collector machine (it's an i7-4790s with 24GB of RAM) or keep running the softflowd directly on the router.
I guess the question I'm asking here is what type of performance / latency impact is mirroring all my incoming and outgoing internet traffic going to have on the switch (it's a Netgear GS308T).
I'm kind of surprised that softflowd has such an impact on your router. A couple questions:
What internet speeds are you running?
What effect does it have on the router? (You say it's CPU intensive...)
Does it cause problems?
In any event, I'm running softflowd 0.9.9-2 on an Archer C7 with OpenWrt 19.07.4. My internet is 25mbps up and down. Here's the /etc/config/softflowd configuration file. As you can see, it's shipping the flow information off to my netflow collector at 192.168.253.5.
My main net connection is a 1Gbps link + a second 75Mbps VDSL connection.
At 1Gbps flows, softflowd generates a lot of softirqs.
But the router is more than capable of handling it. Even running SQM + snort + softflowd, cpu utilization doesn't usually peak above 40% at 1Gbps flows on the two cores running softflowd and snort (it's an 8-core).
I have RX/TX interrupt affinities tuned with hardware accelerated receive flow steering enabled and softflowd and snort are both pinned to different cores using taskset.
If I stop softflowd running, it makes a visible difference in terms of CPU utilization, but it's hard to quantify just by looking at the htop output....
My question came more from a desire to minimize software running on the router itself from a manageability and security perspective than from a search to improve the performance of the router, coupled with a lack of experience on the effect on a switch of enabling port-mirroring.
Frankly, I think the router could probably handle a 10Gbe connection, although it would be very unlikely to be able to cope with anything other than a few very basic snort rules at that speed, if at all - the motherboard has a 10Gbe Intel X533 ethernet controller, although I bought the version of the motherboard that only has 1Gbe ethernet ports, since I didn't need the 10Gbe ones and the version with the 10Gbe ports was substantially more expensive.
I more concerned that if I go the port mirroring route on the switch that the switch is going to take a pounding and affect my network performance. While I can see and imperfectly measure the router's performance, I don't have any tools to look at and measure the switch's performance in a meaningful way...
I'm not sure what you mean. Do you mean send the data to two netflow collector programs on separate hosts? The answer to that question is, "I don't know." I guess I'd try configuring two separate option host_port ... lines... Here's the softflowd man page for Ubuntu I have no idea how far the OpenWrt package has drifted from it...
OK. That's why I asked the question about internet speeds (way faster than my link) and the effect on your router (measurable effect, but not causing problems).
I'm gonna invoke Rich's second rule of network troubleshooting - "If you're happy, I'm happy. " That is, I can tell you're deeply knowledgeable about your router; you see its CPU is hitting 40% (max) utilization when you're using it hard; and even with softflowd, snort, SQM, etc, it's doing the job.
My inclination would be to declare victory and leave the router alone. It has plenty of headroom if the demands of those applications increase.
Furthermore the router sounds as if it's "paid for" - both in dollars and in engineering time. Use your precious brain-cycles to optimize other parts of your network. Best regards.
Sure...I'm not looking to solve a performance bottleneck. It has headroom.
I think @richb-hanover-priv's comment is probably the right advice: "if it ain't broke don't fx it". I'd be exchanging a known and acceptable performance profile for one I can't measure in any meaningful way.
Sometimes it's hard to resist tinkering ....Thanks both for the comments.