I would suggest talking to stig and an-cheng via either the ubnt forum,
or contact them in ##ubnt on freenode irc.
Rebooting like that is not normal behavior.
The only thing I can think of is maybe you have some very inefficient
firewall rules that could be cleaned up a bit? Do you have any
"external" packages installed that aren't natively on the router?
On 11/09/2014 04:58 AM, 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