-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Thursday, 14 April 2016 11:14 AM 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?

Hmm, weird then. I wonder why the mAP won't do it? Do you know how the PPPoE Scan works? Is it an active process? or does it just watch the network for broadcasts?

I'm wondering if it's an active process, and NBNco have a maximum number of MAC addresses they'll learn on a port in a given amount of time? Though not sure why it would accept three different VDSL modems, but only the two CRS109's in that case.

On 14 April 2016 at 11:04, Mike Everest <mike@duxtel.com> wrote:

...

Apart from possible MTU overheads, it should work ok - so long as the modem is capable of bridging layer 2 frames transparently...

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Thursday, 14 April 2016 9:25 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] PPPoE bridging via a vlan? Am I losing my mind?

Hi Folks,

I don't know if I'm doing something wrong, or just losing my mind. We've finally (6 week wait) had FTTN connected at home, and as I had it connected through work, I was able to connect it the same way as my ADSL used to be - static IP with /28 routed down it. I wanted to 'simplify' my routing a little though, and instead of doing everything on my main CRS109, and using a VRF for my internal routing (to keep them separated from the DMZ, and make sure the DMZ can't route down the VPN to work, etc), I figured I'd temporarily use one of my mAP's for the internet routing.

So connection was VDSL modem (Netcomm NF4V) -> port one on CRS, with ingress/egress VLAN translations to put it on vlan 99. DMZ is on vlan 101, both of which are tagged onto a port going to the mAP-2n. Configured the vlans on the ether1 on the mAP, brought up an IP to test connectivity, and I could ping the private IP of the VDSL modem. But PPPoE connection would not come up, and PPPoE scan showed nothing. Bringing up that vlan on the CRS109, and doing a PPPoE scan showed two AC's.

So I then plugged the cable from the VDSL modem directly into ether2 on the mAP. And still nothing on the PPPoE scan. Put the cable back and

...

...

the vlan across to a routerOS VM. Nothing on PPPoE Scan. Trunked

...

...

vlan to the CRS109 in the garage - and PPPoE scan worked from there (although only showed one AC, not two)

I've also tried two other VDSL modems (draytek Vigor 130, and TP-Link TD- W8977), with the same results.

Have I missed something? is there a limitation in the mAP (and RouterOS for x86 for that matter?) that would stop PPPoE from working? or does PPPoE bridging need some special config on switching/vlans to let it work?

Thanks,

Damien

--

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 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.co m.au

_______________________________________________ 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

I believe that pppoe scan is active - something like this: https://nmap.org/nsedoc/scripts/broadcast-pppoe-discover.html Maybe you can pcap some traffic between switch and modem to see if anything gets through as expected? Cheers! Mike. trunked the 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

Hi,

Found http://www.nbnco.com.au/content/dam/nbnco2/documents/sfaa-wba2-product- catalogue-nebs-product-tech-spec-fttb-fttn_20150824-to-FTTN-launch.pdf, 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.

-----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

Is fasttrack new?? Just read the wiki page sounds good. Might have to try it as well. Alex -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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? OMG :D Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's! Thanks Mike! On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

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.

...

-----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 pointed 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-laun ch.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 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.co m.au

_______________________________________________ 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 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

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:33 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?

Is fasttrack new??

Just read the wiki page sounds good. Might have to try it as well.

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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?

OMG :D

Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's!

Thanks Mike!

On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

...

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.

...

-----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 pointed 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-la un ch.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 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. co m.au

_______________________________________________ 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

Any idea how this works with vlans and bonded (LACP) interfaces Alex -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 19 April 2016 3:48 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? Alex, Damien, "aint it cool"? :-D It is /relatively/ new - there was a lot of talk about it at the last MUM in Melbourne, about imminent release at that time. So it's probably been 'in the wild' for almost 1 year now. Each routerOS revision seems to have some additional support for fasttrack - I noticed that release notes for latest version includes implementation of fasttrack for pppoe connections too (which were not possible before!) Cheers! Mike. 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

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

Haha, just discovered - fasttrack'd packets bypass simple queue's, so now I have a catch-22 - I can opt to not use fasttrack, and have a 70mbps limit on my desktop PC, so that a steam update does not kill our TV streaming.. But then the CRS CPU maxes out around the 60mbps mark. Or I can use fasttrack - but then my steam update happily comes down at 100mbps and kills the TV. Hmm, if only RouterOS did something like CARP alongside VRRP, so I could offload routing/nat to an x86 VM most of the time, but have NAT fail over to the CRS cleanly if the VM goes down. Though that's getting disturbingly complex for a home office setup ;) On 19 April 2016 at 16:24, Mike Everest <mike@duxtel.com> wrote:

Hi Alex,

For VLANs and LACP, it should deliver the same performance improvements to routing and firewall processes. When implemented using hardware switch, though, it will make no difference at all because those functions are related to switch hardware and do not use CPU :-}

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:58 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?

Any idea how this works with vlans and bonded (LACP) interfaces

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 19 April 2016 3:48 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?

Alex, Damien, "aint it cool"? :-D

It is /relatively/ new - there was a lot of talk about it at the last MUM in Melbourne, about imminent release at that time. So it's probably been 'in the wild' for almost 1 year now. Each routerOS revision seems to have some additional support for fasttrack - I noticed that release notes for latest version includes implementation of fasttrack for pppoe connections too (which were not possible before!)

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:33 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?

Is fasttrack new??

Just read the wiki page sounds good. Might have to try it as well.

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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?

OMG :D

Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's!

Thanks Mike!

On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

...

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.

...

-----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 pointed 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-la > un ch.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 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. co m.au

_______________________________________________ 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 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

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

_______________________________________________ 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 thunder. We danced among the lightning bolts, and tore the world asunder

Ahh, sweet, I look forward to it :) Yep, VLAN FP is working nicely - my CRS is setup using the switch chip, so RouterOS sees one ether interface with 10 vlan's on it. Three are actually in use - external, DMZ, and internal - and fastpath is working nicely between them :) On 19 April 2016 at 19:41, Andrew Thrift <andrew@networklabs.co.nz> wrote:

FastPath/Track will have simple-queue support soon :) On 19/04/2016 9:13 pm, "Damien Gardner Jnr" <rendrag@rendrag.net> wrote:

...

Haha, just discovered - fasttrack'd packets bypass simple queue's, so now I have a catch-22 - I can opt to not use fasttrack, and have a 70mbps limit on my desktop PC, so that a steam update does not kill our TV streaming.. But then the CRS CPU maxes out around the 60mbps mark. Or I can use fasttrack - but then my steam update happily comes down at 100mbps and kills the TV.

Hmm, if only RouterOS did something like CARP alongside VRRP, so I could offload routing/nat to an x86 VM most of the time, but have NAT fail over to the CRS cleanly if the VM goes down. Though that's getting disturbingly complex for a home office setup ;)

On 19 April 2016 at 16:24, Mike Everest <mike@duxtel.com> wrote:

...

Hi Alex,

For VLANs and LACP, it should deliver the same performance improvements to routing and firewall processes. When implemented using hardware switch, though, it will make no difference at all because those functions are related to switch hardware and do not use CPU :-}

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:58 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?

Any idea how this works with vlans and bonded (LACP) interfaces

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 19 April 2016 3:48 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?

Alex, Damien, "aint it cool"? :-D

It is /relatively/ new - there was a lot of talk about it at the last MUM in Melbourne, about imminent release at that time. So it's probably been 'in the wild' for almost 1 year now. Each routerOS revision seems to have some additional support for fasttrack - I noticed that release notes for latest version includes implementation of fasttrack for pppoe connections too (which were not possible before!)

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:33 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?

Is fasttrack new??

Just read the wiki page sounds good. Might have to try it as well.

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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?

OMG :D

Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's!

Thanks Mike!

On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

...

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.

> -----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 pointed > 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-la > > > un ch.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 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. > co > m.au

_______________________________________________ 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 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

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au

http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.

...

au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au

http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

...

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au

http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

_______________________________________________ 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 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

_______________________________________________ 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 thunder. We danced among the lightning bolts, and tore the world asunder

Why not only fasttrack the video stream ? A -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 7:11 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? Haha, just discovered - fasttrack'd packets bypass simple queue's, so now I have a catch-22 - I can opt to not use fasttrack, and have a 70mbps limit on my desktop PC, so that a steam update does not kill our TV streaming.. But then the CRS CPU maxes out around the 60mbps mark. Or I can use fasttrack - but then my steam update happily comes down at 100mbps and kills the TV. Hmm, if only RouterOS did something like CARP alongside VRRP, so I could offload routing/nat to an x86 VM most of the time, but have NAT fail over to the CRS cleanly if the VM goes down. Though that's getting disturbingly complex for a home office setup ;) On 19 April 2016 at 16:24, Mike Everest <mike@duxtel.com> wrote:

Hi Alex,

For VLANs and LACP, it should deliver the same performance improvements to routing and firewall processes. When implemented using hardware switch, though, it will make no difference at all because those functions are related to switch hardware and do not use CPU :-}

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:58 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?

Any idea how this works with vlans and bonded (LACP) interfaces

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 19 April 2016 3:48 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?

Alex, Damien, "aint it cool"? :-D

It is /relatively/ new - there was a lot of talk about it at the last MUM in Melbourne, about imminent release at that time. So it's probably been 'in the wild' for almost 1 year now. Each routerOS revision seems to have some additional support for fasttrack - I noticed that release notes for latest version includes implementation of fasttrack for pppoe connections too (which were not possible before!)

Cheers!

Mike.

...

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:33 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?

Is fasttrack new??

Just read the wiki page sounds good. Might have to try it as well.

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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?

OMG :D

Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's!

Thanks Mike!

On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

...

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.

...

-----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 pointed 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-FTT > N-la un ch.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 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. co m.au

_______________________________________________ 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 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

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au

_______________________________________________ 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 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

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Alex Samad - Yieldbroker Sent: Tuesday, 19 April 2016 3:33 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?

Is fasttrack new??

Just read the wiki page sounds good. Might have to try it as well.

Alex

-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 19 April 2016 3:26 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?

OMG :D

Fasttrack makes a huge difference! Speedtest doing 95/40 with no more than 30% cpu in use :) Now I need to look at implementing it on my other CRS's!

Thanks Mike!

On 19 April 2016 at 15:07, Mike Everest <mike@duxtel.com> wrote:

...

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.

...

-----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 pointed 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-la un ch.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 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. co m.au

_______________________________________________ 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 Alex, There is currently working support for VLAN FastPath/Track, and limited support for bonding FastPath/Track (rx-only) Hopefully bonding gets tx/rx support soon. On 19/04/2016 5:58 pm, "Alex Samad - Yieldbroker" < Alex.Samad@yieldbroker.com> wrote: Any idea how this works with vlans and bonded (LACP) interfaces Alex -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 19 April 2016 3:48 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? Alex, Damien, "aint it cool"? :-D It is /relatively/ new - there was a lot of talk about it at the last MUM in Melbourne, about imminent release at that time. So it's probably been 'in the wild' for almost 1 year now. Each routerOS revision seems to have some additional support for fasttrack - I noticed that release notes for latest version includes implementation of fasttrack for pppoe connections too (which were not possible before!) Cheers! Mike. 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

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au