I want to upgrade my gateway rb1000 with some 600 simple queues throttling clients data streams.

I had a go overnight to 6.1 and 6.0 but the new v6 simple queues don't catch any traffic any more.....! so rolled back to 5.24. to keep my network in the air....

But now,how to migrate? I really would like to use the new simple queue system....

simple queue example presently running:
Do I need to make some translation into some new settings?

I hope this doesn't mean manual job......

the target-addresses parameter is merged with the interface paramter for version 6
you now should use target instead for both these old V5 parameters

Little quote from the wiki pages.

Note: Since RouterOS v6 these settings are combined in the option target where you can specify either of the above. Target is to be viewed from perspective of the target. If you want to limit your users's upload capability, set "target upload".

the target-addresses parameter is merged with the interface paramter for version 6
you now should use target instead for both these old V5 parameters

Little quote from the wiki pages.

Note: Since RouterOS v6 these settings are combined in the option target where you can specify either of the above. Target is to be viewed from perspective of the target. If you want to limit your users's upload capability, set "target upload".

well, before I rolled back to 5.24 I did play a little with the queues to see if I could get them to work... because I could see now the queues had both the clients LAN IP as target and the LAN facing etherinterface where this traffic was coming from. I removed the interface so only the clients IP was left as target but it still didn't catch any traffic.
I even changed the interfaces to see if the upgrade might have renamed the interfaces, no luck.

So there must be more that I have to change. Anybody else with suggestions?

don't you use bridging?

Most common mistake that i have seen while moving from v5 to v6.
is forgetting that
Traffic can be captured only by once, so if one queue captures it it will never get to the rest of the queues.

so queue with target 0.0.0.0/0 just captures all the traffic in its upload and othet queues doesn''t work
so queues are translated to target=<client IP>, <interface> so queue captures all the traffic on that <interface> so nothing is left for other <client IP> queues

don't you use bridging?

? No, why the question?

don't you use bridging?

? No, why the question?

AFAIR, there were some issues with Simple Queues on the bridge with use-ip-firewall=no

queues are translated to target=<client IP>, <interface> so queue captures all the traffic on that <interface> so nothing is left for other <client IP> queues

so, in v6 it's impossible to directly use Simple Queues for matching IPs only on selected interface(s)?

queues are translated to target=<client IP>, <interface> so queue captures all the traffic on that <interface> so nothing is left for other <client IP> queues

so, in v6 it's impossible to directly use Simple Queues for matching IPs only on selected interface(s)?

When do have situation when IP address is jumping interfaces and you need to filter out one of the interfaces?

Both options in v5 was used to specify queue direction, if those options point on opposite directions queue doesn't capture any traffic, so from both you need to choose the most precise one mostly that is IP address of the client.

in any case if you need that, you can always create parent queue with target=<interface>
and then child queues for individual IPs

just make sure that all traffic is captured by child queues, or ese it will be skipped by parent.

Most common mistake that i have seen while moving from v5 to v6.
is forgetting that
Traffic can be captured only by once, so if one queue captures it it will never get to the rest of the queues.

so queue with target 0.0.0.0/0 just captures all the traffic in its upload and othet queues doesn''t work
so queues are translated to target=<client IP>, <interface> so queue captures all the traffic on that <interface> so nothing is left for other <client IP> queues

Ok, so here is my possible problem?

I have 500+ simple queues to limit my clients. But in the transfer to v6. all these queues get also their interface assigned? Now I understand why when I did so, only two queues showed traffic. Both they had a different interface.

I also have some simple queues at the bottom of v5. s.queue list, "END QUEUE". This is a queue without any target address (which than means 0.0.0.0/0 wasn't it?) to catch any traffic not catch by one of the previous queues.

I actually even have for each of my AP's (with their own IP network) /24 or segment queues made, to catch any traffic that is not catched by a client queue. (Because sometime I forget to make a queue. Or sometimes a Queue is just not catching its traffic, but the general one does...)


So, in translating my v5. s.queues I now need to manually erase all the 'interface' targets? And I need to erase all the simple queues that catches traffic not targeted by its specific IP address?

Pffffff. I only have 500+ simple queues. What if you would have a couple of thousands....... Is there no other way?

To WirelessRuby,

1) update your 500 queues to v6
2) export them to a file
3) open a file with text editor that have "Find and replace" feature
4) from "target=<ip>,<interface>" replace ",<interface>" part with space
5) replace all "disable=yes" with "disabled=no"
6) save and copy export file to the router
7) delete all your queues and import queues from file

Done! 500 1000 or 10000 - same amount of time and effort

having 0.0.0.0/0 even at the end is problem, cause all traffic is both upload and download for target 0.0.0.0/0, and in simple queues one is captured before other, so you need at least specify network that is considered as target.

To WirelessRuby,

1) update your 500 queues to v6
2) export them to a file
3) open a file with text editor that have "Find and replace" feature
4) from "target=<ip>,<interface>" replace ",<interface>" part with space
5) replace all "disable=yes" with "disabled=no"
6) save and copy export file to the router
7) delete all your queues and import queues from file

Done! 500 1000 or 10000 - same amount of time and effort

having 0.0.0.0/0 even at the end is problem, cause all traffic is both upload and download for target 0.0.0.0/0, and in simple queues one is captured before other, so you need at least specify network that is considered as target.

OK, that makes sense. It does need a good 'find and replace' command because single errors are hard to find in big amounts of data...

Lets say I have an AP that is assigning clients to a /24 network. So we have clients ending with .2, .3, .4 etc. Each of these clients get a simple queue. But sometimes in the havoc I forget to make a new simple queue for a new client. So I made a general queue (in pre-v6) that at least catches traffic of any target from that network, so also the forgotten client. This would have been a queue with target /24 and was set after ('below') the other clients specific queues for that network. (Now at least this 'unknown' client's traffic would be catched by this basic queue. If not it would get 'unlimited'. And I can see happening so I know where to look for this 'forgotten client'. I have 25 AP's.....)

How in v6 queues do I now catch traffic from targets that are not specified with their own queue where a generic queue should then not catch traffic from already specified queues?

Don't use network - use interfaces, Even unknown client will have to log in via one of them

Anyway bottom line is v6.x is very similar and even easier than v5.x , the only problem might be transition from one to other, if that is done - everything else remains the same.

Don't use network - use interfaces, Even unknown client will have to log in via one of them

Anyway bottom line is v6.x is very similar and even easier than v5.x , the only problem might be transition from one to other, if that is done - everything else remains the same.

Now you're confusing me.
If I use the interface as target, wasn't it that then that queue would 'catch' ALL traffic entering through that interface? That's 500+ clients...... How do I give them a different queue? I mean, I have about 20 different contracts running with as many different speed limits and priorities....

Don't use network - use interfaces, Even unknown client will have to log in via one of them

Anyway bottom line is v6.x is very similar and even easier than v5.x , the only problem might be transition from one to other, if that is done - everything else remains the same.

Now you're confusing me.
If I use the interface as target, wasn't it that then that queue would 'catch' ALL traffic entering through that interface? That's 500+ clients...... How do I give them a different queue? I mean, I have about 20 different contracts running with as many different speed limits and priorities....

IF you use it in proper place (at the very end), then worse solution is to create queue for 0.0.0.0/0 cause it doesn't show direction at all, better than that you can create target as interface - at least there you will be able to determine simple queue direction, and even better when you can use whole network.


This stuff is unchanged since RouterOS v3 came out, only before v6 it was divided into 2 options, now both are under same one - so simpler.

Anybody have a v5.24 (or 5.25/5.26) TILE version of ROS?
I can't find it on the website...

tile is not supported by v5

OK,
Internet gateway 'old' = rb1000 v5.24 with 545 queues and passing traffic of clients...

Queues exported to a file, loaded in text editor, stripped all interfaces. Disabled all general network queues suppose to 'catch' traffic from non-registered (they have no queue) and and loaded this bit by bit into another rb1000 running v5.24 that is not passing any traffic (Not to disturb running network.)

[I had to select, copy and paste some 80 rules per times into the router since more just made that remote rb1000 (or even my CCR I found out the hardway!) ]

After this I upgraded this rb1000 to v.6.2 (stable version. 6.3 and 6.4 have issues.)
Checked if the queues 'looked' good and exported them into a file.
Downloaded this file into PC and uploaded it to CCR running 6.3.
Checked again if the queues looked fine.

This CCR is now running traffic and it seems queues run fine.....

fingers crossed...