-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 2:41 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] PPPoE bridging via a vlan? Am I losing my mind?
Thanks Mike,
NBN came back up on new provider today, so will get to play with bridging again tonight.
Is there a document somewhere which discusses CPU usage (especially for firewall/NAT rules) on RouterOS? I had thought it was a tunnelling CPU usage issue but I logged in remotely just to get connectivity via NBN for the wife and kids (we've been using Telstra Air with a Groove-52 and a 26dB dish
across the valley ;) ), and for now have my CRS simply doing NAT to the TPG VDSL router, and i'm hitting 100% CPU (profiler showing 80% in firewall, 20% in idle) while doing 60mbps on speedtest.net, so it looks like it's more to do with firewalling?
I noticed the default firewall config on the groove is using a forward action of 'fasttrack connection' rather than accept on the established forward rule??
On 14 April 2016 at 11:55, Mike Everest <mike@duxtel.com> wrote:
Hi,
Found http://www.nbnco.com.au/content/dam/nbnco2/documents/sfaa-wba2- produ ct- catalogue-nebs-product-tech-spec-fttb-fttn_20150824-to-FTTN-launch.p df, which suggests each DSL port will accept up to 8 mac addresses, and expire unseen mac's after 300 seconds. May be simply a modem limit then. Time for more playing!
But if you only have one interface attached to that broadcast domain, then pppoe client interface should be the only MAC that is presented to the modem.
BTW, keep meaning to ask.. How far up the expense (and physical footprint) ladder do I need to go, to get a MT device which will do 100mbps of PPTP traffic? (CRS109 tops out at 100% cpu at around the 45mbps mark..) Had been considering doing a RouterOS VM at home and DC with routing preferencing pushing traffic over PPTP/EOIP tunnel between them if they're up, and falling back to the CRS109's at each end if either VM is down, but if there is a MT router which doesn't take much space which will handle it, and doesn't cost the earth, it might just be easier to go that way :)
Don't know about that - pppoe should not consume so much CPU just to run the ppp interface - perhaps there is something else going on there. Try running profiler tool when CPU is pegged to try to find out what subsystem is using up CPU.
Cheers!
Mike.
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of
Hi Damien, If your CPU is pegging at just 60mbps, then there is something badly wrong with your firewall rules! ;-) First thing to look for is that you have permit established and permit related at the TOP of the filter list, otherwise your end up processing the entire ruleset for every single packet. Next thing to do is to look over the rules and try to make it more efficient by processing smallest number of rules possible for any given packet. Some strategies for that are: 1. put rules that will match the most number of packets at the start - for example, if most of the traffic is TCP, then check it first - no point checking packets against UDP rules if there are only a few of them. This is also why you would put allow established and related at the top of the list (i.e if the packet is part of a connection that has already passed the full rule-set, why test it again?) 2. use jump targets effectively - for example, rather than test that outbound traffic is TCP then port 25 then source from a known address list, test that it is from the known address list then jump to a custom chain - then complete further tests on the packet before determining the outcome. That way, if the packet is not within that address list (for example) then no further tests need to be done. Last thing to consider is whether fast-track is useful for you: http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack Fasttrack packet forwarding is optimised to make it low on CPU, so high on throughput! You should be able to get more than 200mbps on CRS125 with average 512 byte frames (almost 1 gbps with all full size 1500byte frames! :-) Hope it helps! Cheers, Mike. pointed thunder.
We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au