Re: Best qdisc for interfaces of a firewall?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Surely pfifo is the least resource intensive? If the device is already overloaded then I could not recommend any qdisc that does additional processing...

Alan

On 09/11/14 13:58, Dennis Jacobfeuerborn wrote:
The firmware is the current 1.5 release (well current before the very
recent 1.6 one) so it's not really old.

fq_codel is not in use and all interface use a noqueue qdisc.

We are only using zone based firewalling, NAT and network/port groups so
basically just iptables+ipset and a couple of vlan interfaces.

In its default configuration both cpus are pegged at 95% soft-irq usage.
Enabling vlan offloading reduces that quite a bit...but apparently make
the system reboot itself about once every two days.

On 09.11.2014 07:29, josh Reynolds wrote:
There is an issue on older firmware with edgerouterand fq_codel, Dave
would be the one to talk about that.. it's a codel/kernel thing though.

I know wisps running full line rate and thousands of customers through
edgerouter pros with no problems. What are you having issues with?

On 11/08/2014 03:57 PM, Dennis Jacobfeuerborn wrote:
Hi,
I just looked at the interfaces of our EdgeRouter Pro appliance that we
plan to replace (due to it apparently being overloaded at 150Mbit) and
see that they all have a qdisc of "noqueue".

What is the best qdisc to select for a pure firewall system? I can't
find any decent information about the various qdiscs and which to chose
in specific situations. For example there seems to exist a multiq
scheduler but I cannot find a lot of information about its
characteristics plus I already assigned the irq of each queue of the nic
to individual cores so I wonder if something like multiq is even
necessary.

I'm also wondering about fairness and if that might be a legitimate
reason to chose somehting like noqueue so one flooding flow cannot hog
the queue and penalize all other flows.

Any ideas what would be a well performing yet fair choice here?

Regards,
    Dennis
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux