February 2018 - Public - talk.mikrotik.com.au

Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
by Mike Everest 31 May '19

31 May '19

Hi Harry, thanks for the comments! (have you tried subscribing to the public list? What happens when you try to add a subscription?) That is only the LIPD class license document but it does not list the relevant standards. The standards list some of the ETSI specifications which according to MT include radar detect operation. From MT perspective, they claim that DFS implies Radar Detect in the relevant standards. I have no doubt that it DOES make that link in the EU specification, but since our AU compliance requirements also refer to some ETSI standard then it is possible that our rules are also affected by the recent updates to relevant ETSI standards simply by association and since ACMA have not explicitly excluded that revision... This is what I am attempting to ascertain ;) So far, I have not been able to find the direct relationships and have been doing the rounds of some compliance folks to try to get to the bottom of it all. It may take some time :-1 Cheers, Mike. ---------------------------------------------------------------------------- -------- Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel ---------------------------------------------------------------------------- -------- Follow our tweets for news and updates: http://twitter.com/duxtel > -----Original Message----- > From: Harry Fiotakis [mailto:Harry.Fiotakis@tasmanet.com.au] > Sent: Monday, 23 October 2017 10:39 AM > To: Mike Everest (mike(a)duxtel.com) <mike(a)duxtel.com> > Cc: Philip Loenneker <Philip.Loenneker(a)tasmanet.com.au> > Subject: RE: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Morning Mike, Phil forwarded me the latest correspondence as I still have not > been approved on the mailing list :( > > https://www.legislation.gov.au/Details/F2015L01438 (Radiocommunications > (Low Interference Potential Devices) Class Licence 2015) > > 5250-5350 Must use DFS > 5470-5600 Must use DFS > 5650-5725 Must use DFS > > No Radar Detect required (it is not implied) > > We will have to seek official clarification on that if Mikrotik require it, but > with it forced on we are downgrading Mikrotik radios or simply not using > them. > > > Regards, > > Harry Fiotakis | TasmaNet > 40-50 Innovation Drive, Tas 7010, Australia > M: 0418 540 806 P: 1300 792 711 > Email: harry.fiotakis(a)tasmanet.com.au > > > -----Original Message----- > From: Philip Loenneker > Sent: Monday, October 23, 2017 10:30 AM > To: Harry Fiotakis <Harry.Fiotakis(a)tasmanet.com.au> > Subject: FW: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Mike Everest > Sent: Monday, 23 October 2017 9:50 AM > To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> > Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Further update on this issue, > > I've had a bit of correspondence with them, but they are 'fighting' it. Latest > comment from them is that "ETSI standard mentions when you use DFS and > those ranges you need to use the Radar-detect. Radar detect is happening > only for 1 minute." > > The line they are taking is that since our LIPD class license specification says > that DFS must be enabled for the sub 5785 channels, then radar detect must > also be enabled. I've been trying to pore through all the relevant ACMA > documentation so that I can find some definitive paragraph that clarifies the > situation, but so far have drawn a blank. > > I need someone who has some specific familiarity with the relevant rules and > standard that can find something that will convince them to turn it off - any > takers? :-} > > Cheers, Mike. > > > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

5 26

Fwd: xDSL SFPs
by Jason Hecker (Up & Running Tech) 27 Aug '18

27 Aug '18

That's flat out wrong. Have a look at the PDF on http://www.acma.gov.au/ Industry/Suppliers/Regulatory-arrangements/EMC- Electromagnetic-compatibility/emc-standards-list and see page 5. All IT equipment - no exceptions - must be tested (by an approved tester) to and comply with CISPR-32 and get a C-Tick for use in Australia. Upshot is don't import and use or sell the SPF modules unless the supplier has ensure it's complied. Duxtel know all about this - they supply all their Mikrotik gear (including boring old routers with no Wifi) with pretty little compliance stickers. On 9 August 2017 at 17:05, Paul Julian <paul(a)oxygennetworks.com.au> wrote: > Agreed, the VC-231's are Tick approved, PSU and Bridge, we use a lot of > them when deployed as a NTU for a VDSL2 DSLAM Implementation or as a point > to point VDSL2 link. > > C tick or A tick approval is only required when connecting > telecommunication devices to public communication networks, C tick or A > tick approval is required for radio communications devices, so if it's a > telecommunications device connected to a private wire you don't need > approval, if it's a radio communications device you need approval no matter > what. > > The ACMA make it pretty clear on their website if you aren't sure. > > http://www.acma.gov.au/theACMA/bringing-communications- > equipment-into-australia > > Regards > paul > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Jason Hecker (Up & Running Tech) > Sent: Wednesday, 9 August 2017 4:52 PM > To: MikroTik Australia Public List > Subject: Re: [MT-AU Public] xDSL SFPs > > That's partly true. As it's an active device it still needs C-Tick > approval for electromagnetic compatibility and susceptibility reasons. > There are likely even considerations for electrical isolation as it can > connect two sites on different AC phases and potentials. Considering it's > pumping HF energy into a long wire it's like a radio transmitter anyway so > it definitely needs to comply. > > On 9 August 2017 at 16:45, Paul Julian <paul(a)oxygennetworks.com.au> wrote: > > > If it's a private CAT3 cable there are no approvals required as it's > > just a private link. > > > > We use the Planet VC-231 bridges for that sort of thing, they are > > pretty good and will do 100/100 over a couple of hundred metres with > good cable. > > > > Regards > > Paul > > > > -----Original Message----- > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > > Jason Hecker (Up & Running Tech) > > Sent: Wednesday, 9 August 2017 4:41 PM > > To: MikroTik Australia Public List > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > Yes the belt and braces and correct way is to find a version that > > someone has had approved for use in Australia. I don't think anyone > > has done that yet! It'd be nice if the manufacturer did the legwork > > but they only do FCC and CE. > > > > On 9 August 2017 at 16:33, Russell Hurren > > <russell(a)zeropointnetworks.com> > > wrote: > > > > > I've just had a client call me and ask for a WiFi repeater to go in > > > the house next to their motel. There's already CAT3 running between > > > the buildings, so something like that would be a good option for me. > > > I'd be willing to order a pair and give it a try, but I'm not sure > > > about the legality - I presume it'd need an A-Tick approval? > > > > > > I've got a CRS125 in the main building and I could put a hAP ac in > > > the house and it'd be a nice clean option, compared to using > > > something like a Planet VC-231. > > > > > > -----Original Message----- > > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf > > > Of Jason Hecker (Up & Running Tech) > > > Sent: Wednesday, 26 July 2017 8:37 > > > To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> > > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > > > That said, the http://www.proscend.com/en-gb/product/sfp/180cr.html > > > looks interesting for linking buildings that have old CAT3 cabling > > > in between. I reckon I could have used that sort of thing in a few > > > places instead of wireless. Has anyone tried these sort of VDSL2 > > bridges? > > > > > > On 26 July 2017 at 10:20, Philip Loenneker <Philip.Loenneker@tasmanet. > > > com.au > > > > wrote: > > > > > > > If anyone would care to donate a unit, I have a service I can test > > > > it > > on. > > > > And as an RSP, we have direct access to the NBN portal to request > > > > reactivation if it gets blocked :) > > > > > > > > -----Original Message----- > > > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On > > > > Behalf Of Jason Hecker (Up & Running Tech) > > > > Sent: Wednesday, 26 July 2017 10:17 AM > > > > To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> > > > > Subject: Re: [MT-AU Public] xDSL SFPs > > > > > > > > I think we're all pretty excited about the prospects of those > > > > VDSL2 and G.Fast SFP modules (I am getting FTTC so G.Fast is > > > > probably on the cards one day). I guess you can be the guinea pig > > > > and be the one to risk explaining to your ISP why your port should > be unlocked. > > > > ;) > > > > > > > > On 26 July 2017 at 10:09, Damien Gardner Jnr <rendrag(a)rendrag.net> > > > wrote: > > > > > > > > > If you plug in a modem which does not support G.vector, the port > > > > > will get shut down within ~10 minutes, and requires a support > > > > > request from your > > > > RSP > > > > > to NBNco to have the port re-enabled. They don't specifically > > > > > detect > > > > modem > > > > > model and shut down if they don't know the model though, as far > > > > > as I > > > > know. > > > > > > > > > > IPOE on ADSL is an interesting one, that'd make setup very easy! > > > > > > > > > > On 26 July 2017 at 10:05, Jason Hecker (Up & Running Tech) < > > > > > jason(a)upandrunningtech.com.au> wrote: > > > > > > > > > >> Be careful, I remember reading that modems not tested and > > > > >> authorised for NBN use can cause the port to be locked. Until > > > > >> someone goes to the expense of having them tested and approved > > > > >> for use in Australia (cough .. Mike?) you may not get much joy. > > > > >> They might work on a bog standard ADSL line. > > > > >> > > > > >> Speaking of which, I might be late to the party but I noticed > > > > >> that > > > > Telstra > > > > >> ADSL now supports IPoE as well as PPPoE/A. I reset an old > > > > >> cheapie/dodgy TPLink modem the other day for someone and > > > > >> without doing anything the PC connected did a DHCP request and > > > > >> got a public IP/DNS! When I set the modem up to do IPoE it > > > > >> picked all that up as well but for some reason wouldn't NAT or > > > > >> proxy the DNS. Wrote the modem off and we proceeded to order an > NBN service. > > > > >> > > > > >> On 26 July 2017 at 09:57, Damien Gardner Jnr > > > > >> <rendrag(a)rendrag.net> > > > > wrote: > > > > >> > > > > >> > Anyone else ordered one of the 180-T's yet? innet24.de are > > > > >> > now > > > > selling > > > > >> > them, but are waiting on a firmware update (due out next > > > > >> > week) before they're shipping more units. Looking forward to > > > > >> > getting one and > > > > seeing > > > > >> how > > > > >> > they go on NBN, if I can remove one device from the network > > > > >> > at home, > > > > >> I'll > > > > >> > be very happy! > > > > >> > > > > > >> > On 19 May 2017 at 08:08, Thomas Jackson > > > > >> > <thomas(a)thomax.com.au> > > > wrote: > > > > >> > > > > > >> > > Thanks for the responses everyone > > > > >> > > > > > > >> > > Looks like we're using the double-sided tape again this > > > > >> > > time around > > > > :) > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > Sent from mobile > > > > >> > > > > > > >> > > Thomas Jackson > > > > >> > > Managing Director > > > > >> > > +61 2 8378 5555 > > > > >> > > > > > > >> > > > On 18 May 2017, at 12:54 pm, Mike Everest > > > > >> > > > <mike(a)duxtel.com> > > > > wrote: > > > > >> > > > > > > > >> > > > Hi Everyone, > > > > >> > > > > > > > >> > > > I thought I'd chip in some commentary here since there is > > > > obviously > > > > >> > > plenty > > > > >> > > > of interest :-} > > > > >> > > > > > > > >> > > > There are at least two products around that implement > > > > >> > > > some form of > > > > >> vDSL > > > > >> > > in > > > > >> > > > an SFP module, but there are lots of hurdles preventing > > > > >> > > > release to > > > > >> AU > > > > >> > > market > > > > >> > > > which are partly commercial (vendor requests significant > > > > >> > > > - circi > > > > >> > USD100K > > > > >> > > - > > > > >> > > > commitment prior to even proving viable operation on any > > > > >> > > > given > > > > >> network) > > > > >> > > and > > > > >> > > > partly technical (vDSL definition is somewhat 'loose' in > > > > >> implementation > > > > >> > > such > > > > >> > > > that there is no guarantee that something that works well > > > > >> > > > with one > > > > >> > vendor > > > > >> > > > DSLAM will also work with every other) > > > > >> > > > > > > > >> > > > At DuxTel, we've been trying to work out a solution for > > > > >> > > > many > > > > months, > > > > >> > and > > > > >> > > > although we are closing on a potential outcome, there is > > > > >> > > > no firm > > > > >> date > > > > >> > for > > > > >> > > > market readiness. > > > > >> > > > > > > > >> > > > One thing that we know of thus far: > > > > >> > > > - devices are real, and actually exist ;) > > > > >> > > > - devices work with MikroTik RouterOS to the extent that > > > > >> > > > they are > > > > >> > > recognised > > > > >> > > > by SFP drivers and 'inserted module' parameters are > > > > >> > > > reported > > > > >> correctly > > > > >> > > > - MikroTik are 'on board' to develop further support to > > > > >> > > > implement > > > > >> some > > > > >> > > form > > > > >> > > > of configuration interface for routerOS and this type of > > > > >> > > > device > > > > >> > > > > > > > >> > > > Here is what we don't have yet: > > > > >> > > > - commercial agreement with manufacturing vendor/s to > > > > >> > > > support > > > > >> > > development of > > > > >> > > > solution to work with any given vDSL service (read: NBN) > > > > >> > > > - compliance testing documentation to support RCM > > > > >> > > > eligbility for > > > > AU > > > > >> > > > environment > > > > >> > > > > > > > >> > > > What needs to happen before they are made available to > > > > >> > > > the AU > > > > >> market: > > > > >> > > > - compliance testing and certification > > > > >> > > > - testing (and probably some driver/firmware development) > > > > >> > > > to work > > > > >> with > > > > >> > > NBNCo > > > > >> > > > DSLAMs and other DSLAM vendors > > > > >> > > > > > > > >> > > > The big hurdle to the above is in coming to some > > > > >> > > > commercial > > > > >> agreement > > > > >> > > with > > > > >> > > > one or more vendors that satisfies their need to cover > > > > >> > > > costs of > > > > >> final > > > > >> > > stages > > > > >> > > > of development and compliance testing. > > > > >> > > > > > > > >> > > > My assessment of where this is all at is that the > > > > >> > > > manufacturer/s > > > > >> have > > > > >> > > > developed some 'proof of concept' hardware that seems to > > > > implement a > > > > >> > > general > > > > >> > > > form of vDSL (with ADSL fallback) BUT (and that's a big > > > > >> > > > BUT) there > > > > >> is a > > > > >> > > lot > > > > >> > > > of technical work to be done to deliver sufficient > > > > >> > > > confidence that > > > > >> they > > > > >> > > will > > > > >> > > > work reliably over any particular or general vDSL network. > > > > >> > > > That > > > > is > > > > >> not > > > > >> > > even > > > > >> > > > beginning to consider whether they are likely to meet any > > > > particular > > > > >> > > > regulatory compliance requirements for AU or any other > > > > jurisdiction > > > > >> ;) > > > > >> > > > > > > > >> > > > So short story is: they are coming, perhaps, but probably > > > > >> > > > not any > > > > >> time > > > > >> > > soon > > > > >> > > > :-J > > > > >> > > > > > > > >> > > > Questions (on or off list) are welcome! > > > > >> > > > > > > > >> > > > Cheers, Mike. > > > > >> > > > > > > > >> > > > > > > > >> > > > _______________________________________________ > > > > >> > > > Public mailing list > > > > >> > > > Public(a)talk.mikrotik.com.au > > > > >> > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk. > > > > >> > mikrotik.com.au > > > > >> > > > > > > >> > > _______________________________________________ > > > > >> > > Public mailing list > > > > >> > > Public(a)talk.mikrotik.com.au > > > > >> > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mi > > > > >> > > k > > > > >> rotik.com.au > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > -- > > > > >> > > > > > >> > Damien Gardner Jnr > > > > >> > VK2TDG. Dip EE. GradIEAust > > > > >> > rendrag(a)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(a)talk.mikrotik.com.au > > > > >> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mik > > > > >> rotik.com.au > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> <https://www.upandrunningtech.com.au> > > > > >> _______________________________________________ > > > > >> Public mailing list > > > > >> Public(a)talk.mikrotik.com.au > > > > >> http://talk.mikrotik.com.au/mailman/listinfo/public_talk. > > > > mikrotik.com.au > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Damien Gardner Jnr > > > > > VK2TDG. Dip EE. GradIEAust > > > > > rendrag(a)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 > > > > > > > > > > > > > > > > > > > > > -- > > > > <https://www.upandrunningtech.com.au> > > > > _______________________________________________ > > > > Public mailing list > > > > Public(a)talk.mikrotik.com.au > > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mik > rotik.com. > > > > au > > > > > > > > > > > > > > > > -- > > > <https://www.upandrunningtech.com.au> > > > _______________________________________________ > > > Public mailing list > > > Public(a)talk.mikrotik.com.au > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > > au > > > > > > _______________________________________________ > > > Public mailing list > > > Public(a)talk.mikrotik.com.au > > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > > au > > > > > > > > > > > -- > > <https://www.upandrunningtech.com.au> > > _______________________________________________ > > Public mailing list > > Public(a)talk.mikrotik.com.au > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > > au > > > > > > > -- > <https://www.upandrunningtech.com.au> > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > -- <https://www.upandrunningtech.com.au> -- <https://www.upandrunningtech.com.au>

8 19

Mikrotik - Wireless Issue on hAP and hAP ac lite
by Ben Farmer 06 Mar '18

06 Mar '18

Hi guys, Hoping any of you can help. We're seeing weird issues with our Mikrotik client routers in deployment, specifically with the 2.4GHz wireless on the hAP and hAP ac lites. This issue we're seeing seems to affect the 2.4GHz wireless card (Atheros AR9300 in both models) but does not affect the 5GHz card in the ac lite. Customers are reporting to us the inability to connect to wireless at times, such as invalid security key or failure to connect messages (depending on the customer device). The wireless interface itself will show as running, but with no clients connected. No error messages are indicated in the log about exchange key timeouts or anything similar, like you'd expect. Doing anything that performs a soft-reset like operation on the wireless interface will allow the customer to connect again for a period of time. This can include: - Doing a wireless scan. - Doing a frequency usage scan. - Changing channel. - Changing SSID. Basically any option you can change will fix it, even rebooting the router. We've tried all different types of software from 6.39 through 6.41, even the latest rc (6.42rc35). We've seen this issue for at least three months now, if not longer. It's not isolated to a particular site either, as we receive reports daily from other customer locations with the same issue. Initially we thought it was interference, but even then we have customers with very low utilisation and still seeing this issue. We have reported a case with Mikrotik, but their most recent suggestion was to post in the forums to see if anyone else was experiencing this issue (which surprised me, generally they direct you to support if you write this sort of stuff in the forums). Below I've included a brief output from the router showing the way this interface is currently set up. Have any of you seen this type of issue on either this wireless card or others? /interface wireless security-profiles add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=wlan1 supplicant-identity=room-403 /interface wireless set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=2ghz-b/g/n country=australia disabled=no distance=indoors frequency=2462 mode=ap-bridge security-profile=wlan1 ssid="Room 403" wireless-protocol=802.11 Regards, Ben

3 5

queue noob
by Karl Auer 05 Feb '18

05 Feb '18

I bought an HAP ac lite, intending to use it as a throttle between a bunch of evil leeching wifi users and a client's tender defenseless Internet router. I have had a test unit (an older 951 unit) in there and used the bandwidth command on the relevant ethernet port. That worked a treat. Turns out none of the interfaces on the HPA ac line support the set bandwidth command :-( So I have turned to queues. I cannot figure them out. This command should IMHO limit the total bandwidth coming IN to ether1 to 1 megabit, and the total bandwidth for traffic LEAVING ether1 to 500 kilobits: /queue simple add target=ether1 queue=ethernet-default/ethernet-default max-limit=500K/1M But when I do that, nothing moves over ether1 (which is the link between the HAP and the Internet router). So I deleted that queue and tried this (192.168.100.0/24 is the network containing the leeches - wlan1, wlan2, ether2/3/4 bridged): /queue simple add target=192.168.100.0/24 queue=ethernet-default/ethernet-default max-limit=500K/1M Traffic flows over ether1, but this in no way limits the bandwidth to anything like those values. If I use 10K/10K instead and then download a file in Firefox, I see the transfer rate start at 12KB/s (kilobytes per second) and creep steadily up to around 100KB/s by the time the whole 50MB file has been downloaded. That's in stark contrast to the 1 or 2 megabytes per second I get without the queue, so *something* is happening, it just doesn't seem very predictable. Ideas would be very welcome... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB

3 6

Re: [MT-AU Public] queue noob
by Michael Junek 03 Feb '18

03 Feb '18

Hi Karl, If you're using a bridge, the IP should be assigned to the bridge interface, not to one of the members. That might be your issue. M ________________________________ From: Karl Auer <kauer(a)nullarbor.com.au> Sent: Saturday, 3 February 2018 2:31 pm To: MikroTik Australia Public List Subject: Re: [MT-AU Public] queue noob On Sat, 2018-02-03 at 13:43 +1100, Mike Everest wrote: > if the interface is configured as a bridge port, then define the > bridge as the interface for queue not the physical port. Thanks - but still no go. The bridge has three interfaces in it - ether2, wlan1, wlan2. ether3 and ether4 are slaved to ether2. ether5 has been split off as a management port, nothing on it for these tests. The network on the bridge (actually on ether2) is 192.168.100.0/24. The bridge settings are: use-ip-firewall: yes use-ip-firewall-for-vlan: no use-ip-firewall-for-pppoe: no allow-fast-path: yes bridge-fast-path-active: no bridge-fast-path-packets: 0 bridge-fast-path-bytes: 0 bridge-fast-forward-packets: 0 bridge-fast-forward-bytes: 0 My queue looks like this (formatting edits only): Flags: X - disabled, I - invalid, D - dynamic 0 name="test" target=bridge parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=10k/10k burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 With target=ether1, nothing moves. With target=bridge, the queue has no effect at all. With target=192.168.100.0/24, the queue seems to slow down interactive access to the router dramatically (leading to unfounded optimism), but a file transfer in Firefox scoots up to 100 kiloBYTES per second average over a 50 megabyte download. The thing is, without the queue the transfer happens at 1.2 megabytes per second, so clearly the queue is doing something! Just not remotely like what I am expecting. In desperation I set max-limit to 1000/1000 and things almost stopped :-) Interaction with the router CLI involved multi-minute delays. The browser was rendered unusable, so could not see whether the download was any slower. What am I missing? This seems like a totally simple thing to want, it must be a common requirement, how come it is so danged hard to achieve? "That link there - allow no more than X bps inbound and Y bps outbound". Regards, K. > > > > -----Original Message----- > > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf > > Of Karl > > Auer > > Sent: Friday, 2 February 2018 11:21 PM > > To: MikroTik Public <public(a)talk.mikrotik.com.au> > > Subject: [MT-AU Public] queue noob > > > > I bought an HAP ac lite, intending to use it as a throttle between > > a bunch of > > evil leeching wifi users and a client's tender defenseless Internet > > router. I > > have had a test unit (an older 951 unit) in there and used the > > bandwidth > > command on the relevant ethernet port. That worked a treat. > > > > Turns out none of the interfaces on the HPA ac line support the set > > bandwidth > > command :-( > > > > So I have turned to queues. I cannot figure them out. This command > > should > > IMHO limit the total bandwidth coming IN to ether1 to 1 megabit, > > and the > > total bandwidth for traffic LEAVING ether1 to 500 kilobits: > > > > /queue simple > > add target=ether1 queue=ethernet-default/ethernet-default max- > > limit=500K/1M > > > > But when I do that, nothing moves over ether1 (which is the link > > between the > > HAP and the Internet router). > > > > So I deleted that queue and tried this (192.168.100.0/24 is the > > network > > containing the leeches - wlan1, wlan2, ether2/3/4 bridged): > > > > /queue simple > > add target=192.168.100.0/24 queue=ethernet-default/ethernet-default > > max- > > limit=500K/1M > > > > Traffic flows over ether1, but this in no way limits the bandwidth > > to anything > > like those values. If I use 10K/10K instead and then download a > > file in Firefox, > > I see the transfer rate start at 12KB/s (kilobytes per second) and > > creep > > steadily up to around 100KB/s by the time the whole 50MB file has > > been > > downloaded. > > That's in stark contrast to the 1 or 2 megabytes per second I get > > without the > > queue, so *something* is happening, it just doesn't seem very > > predictable. > > Ideas would be very welcome... > > Regards, K. > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ > > Karl Auer (kauer(a)nullarbor.com.au) work +61 2 > > 64957435 > > http://www.nullarbor.com.au mobile +61 428 > > 957160 > > > > GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D > > Old > > fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB > > > > > > > > _______________________________________________ > > Public mailing list > > Public(a)talk.mikrotik.com.au > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.c > > om.au > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com > .au -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB _______________________________________________ Public mailing list Public(a)talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

2 5

CRS-109, Vlan Translations, and SFP's.. Am I missing something?
by Damien Gardner Jnr 02 Feb '18

02 Feb '18

Hi Folks, (Sorry, this is a bit long, but hoping I'm just missing something bleedingly obvious..) Playing with one of the VDSL SFP's this evening, working quite nicely. However hitting a weird snag. On the Huawei HG658 i was using, I had vlan100 set on the PTM bridge, so was simply doing ingress/egress translations of vlan 0 to vlan 99 on the switch chip in the CRS109. (Vlan100 is already in use in my network, so my PPPOE bridge network ended up on vlan 99) Something like: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=0 ports=ether2-huawei-bridge service-vlan-format=untagged-or-tagged /interface ethernet switch ingress-vlan-translation add new-customer-vid=99 ports=ether2-huawei-bridge That way the bridged VDSL traffic on native VLAN from the huawei ends up in VLAN99 on the RouterOS CPU interface (And ether1-master-local which goes to my other CRS-109 which sometimes brings up a separate PPPOE session). Plugging in the VDSL SFP, I knew I needed to do the vlan 100 tagging myself, so figured I can simply do VLAN translations 100<>99, instead of 0<>99 on the sfp1-slave-local interface (ether1-master-local is master port to all ports on the CRS-109). I'm using similar to this on another CRS at work doing Vlan translations on my uplink port, and it's working fine on the ether1 port.. Is the SFP port special in any way? Adding the appropriate rules similar to above to add vlan 99 being re-written as vlan 100 on SFP side as below, doesn't end up with any traffic passing: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=100 ports=sfp1-slave-local bridge service-vlan-format=untagged-or-tagged /interface ethernet switch ingress-vlan-translation add customer-vid=100 new-customer-vid=99 ports=sfp1-slave-local I'd have thought this SHOULD work? If I pull the SFP1 interface out of the switch chip (i.e. master=none), and create vlan100 under it, and then assign the pppoe interface to sfp1_vlan100, it comes up instantly. If I leave it IN the switch chip, and instead just add vlan 100 to sfp port, and then use vlan100 for the pppoe dialler, it also works - but I don't want PPPOE traffic on vlan100 internally, as that's the LAN.. Is this maybe a hiccup with the CRS109's switch chip vlan translations, that you can't do translations between two vlan ID's which it's using internally or somesuch? Thanks, Damien -- Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag(a)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

4 4