Queue Tree basics.... ping times goes up, priority ignored?

RouterOS Beginner Basics
1

Ok, here is a problem.

I use a 450g for my office and today something started syncing up the traffic.

My ping time to our cluster went from 46ms to unstable 200ms. Remote desktop became unusable.

The problem: I Have queues, and traffic DID get properly seaprated.

I HAve 5 queues in the queue tree, all children of global-out:
timed, prioerity 1, for stuff like icmp
interactive, priority 3, for things like rdp.
requested, prioerity 5, for request burst stuff (http)
slomo, priority 7, for slow motion things
unmarked, priority 8.
All queues are pdq, limit 128, total limit 8192. No rate. classifier by all 4 items.

Traffic goes over a PPTP link (no real other traffic during that time). I would see the bulk (470kbit - we have a 512kbit uplink) being classified as either slomo or unmarked (playing around with it on my end).

interface queues are left unchanged (tthernet default to the outgoing ethernet links, default for the pptp link).

STILL - remote desktop was hardly usable, pings around 200ms and higher, occasional drops.

This is not acceptable as priority 1 is supposed to also contain, soon, voip traffic - and I want that stable.

What did I do wrong? It was my impression that higher pirority traffic would go in first. Should under those circumstances no the priority 1 ping keep it’s delay latency stable? I basically need timed traffic to run as undisturbed as possible, interactive traffic next. Bandwidth can use up pretty much everything, with “the rest” going to lower bands. Otherwise I can forget people using pptp or voip while a file upload is in progress.

Regards

2

What limits do you have there?

I hope you realize that priority doesn’t work without limits on all queues.

3

No, but i have this sprted out now. With one bug report.

My queueus now all have limits (why the heck do they not work without?) and the tree works perfectly.

Except it fails. Aftaer a minute or so, priorities seem to be ignored, high prioerity traffic (prio 1, pings) goes up to 2000ms:

I have basicall this PPTP link (only real traffic) where the queues are.

  • I log into a remote machine on the other end and start a file upload via SMB from my local servers. SMBtraffic is low priority (slomo mark).

Everything is fine. Ping is stable. I can work on remote desktop. Like a charm.

“only” negative side is that the queued traffic in slomo slowly fills up. To be expected.

At one point, it seems a threshshold is reached. The queued bytes reset, and I am in priority hell. You can see this on the attached screenshot - ping just gets bad. Nothing changed queue wise, transfer “in progress”. Unless you have another idea I don’t see anything that I do here. Otherwise - queues work perfectly now on that one level :wink:

Any idea?

4

Why you need limits for priority? Its easy - there are no such thing as packet sequence rearrangement, it is too slow and you need to be able to predict future to do it properly. Every time packet comes to HTB it needs to get instant decision ether pass this packet or drop it. This is where limits comes in - as trigger when to drop or pass packet. Priorities and double limitation are there to ensure proper handling of different traffic distribution.


About issue you seeing - do you have some kind of tunnel? i got something similar when i was limiting traffic on public interface and tunnel interface that was on the same public interface at same time.

5

I have limits because I have been told without limits things wont work. I personally dont undertand this. I could work with having sub-queues that basically JUST are based on priority. I want higher priority items ALWAYS to have priority, without bandwidth restrictions, but obviously this does not work in RouterOS. I was told you must have limits, and without limits it never worked.

Yes, there is a tunnel. PPTP, the queue is inside it. The main interface had close to zero traffic at this point. This is also a requirement. At the end of the day, traffic over the tunnel HAS to have priority over ALL non tunnel traffic with SOME limitations (that are not bandwidth hogs, like ping and DNS requests). At the end, in the tunnel I have things like VOIP servers in a data center and remote desktop.

I need this to be stable. I can not have remote desktops turn unusable when a file transfer is running in the background.

6

sorry, maybe i was not clear - in previous post i asked myself question and explained it, so you can understand why limits was necessary. It looks like you need to do lots of reading and understanding in the RouterOS manual.

7

The problem is that there is no manual, only a collection of pages called wiki that obviously partially is not made by someone speaking english and in gneral lacks a global frame and explanations a proper manual should have.

I tried all combos now.

  • no pptp queue, I can qos traffis on the out interfaces. Bad news: queue traffixc is GRE → no internal qos within the tunnel, useless.
  • global out queue… ok, but all traffic counts twice and per interface I can not limit bandwidths on specific ports again → useless.
  • qos on pptp → no traffic visible in queue tree for interfaces (grats, useless, no shaping possible when vpn and normal traffic mixes). And qos drops out after a minute → totally useless.

At the end of the day I have a ton of options, none of which result in usable QOS for something as trivial as shaping traffic over a PPTP uplink to the company HQ. And no manual worth a cent - sorry to say. There is no clear example for simple situations like this. And yes, I see QOS with a tunnel standard situations. We plan putting a small router on every of our employees handling exactly this scenario - acting as their local endpoint for a dsl uplink and also prioritizing corporate time critical traffic.

So waht now? Pay a consultant more money than the equipment is worth because Mikrotik does not consider a manual part of the deliveries, or pack up and return to sender as faulty good (no manual = faulty product). Sorry if I sound pissed - i am a little.

8

  1. in mangle use mark-connection rule, than based on connection-mark and in-interface mark upload and download packets with separate marks, safest place to do all this is mangle chain forward

  2. then you can use any HTB that are after your mangle chain for both or any limitation, safest bet is to place both (upload queue tree, and download tree) is in global-out.

when creating queues make sure that:
a) sum of child’s limit-at is less or equal to parent max-limit
b) children queue max-limits is less or equal to parent max-limit
c) on parent max-limit should be as close to real traffic availability as possible

9

QOS and Prioritisation have so many variables and ways to do that you couldn’t possible include it in a printed manual. The wiki is good as it lets you know what everything does and basic examples. It can also be upgraded to reflect the software changes. I’m pretty sure if you go and buy a Cisco you wont get a manual with instructions for every situation with them. Just my 2 cents.

10

Ok, I have some equestions for that:

  • What do I sensible set as bandwidth limitation if I have an internal interface, 2 external uplinks and a tunnel? If I use global-out… finding a sensible limit seems nearly impossible. Given that I dont have multi link PPP and no real split between the two uplinks, I would not know what to put in as limit. In my example, I have an inner interface that doesn ot really count against traffic. 2 outer interfaces with 512 kbit uplink capacity and a tunnel with 512 (as it is limited to one interface). Which number goes in for the top level queue, “as close as possible to the real bandwidth”?

  • SO basically you tell me not to have a mark by priority, but by priority AND connection tunnel (i.e. not am ark “real time” but a mark “tunnel real time”). I have to look at it.

Any documentation of:

  • How marks are handled / Propagated for tunnels? I mean, I still dont see how this could work as I would have unmarked GRE traffic floating around, or?
  • Adding to that: Can i only ever ahve ONE tree? IT seems taht only the first element in the queue tree ever gets any traffic. Just put my QOS tree on ether2-uplink and then anothe one on ether3-uplink, and the later one showed 0 all while traffic was flowing.

I will give it some thoughts and see that I put that in later today. Interesting approach.

Anyone can put a price on walking me through that configuration? :wink:

11

No offense, but it looks like you jumped in configuration that is way over your head.
Now it turns out there are several gateways and load balancing.

I can’t help you cause solution, that i can explain to you, is based on principles that you don’t know yet . So try consultant or trainer, or strip down your setup to simplest 1 public and 1 private port solution and try it out.

12

Actually on another thread I got it working. It ran down to a couple of STUPID problems:

  • Queue trees attached to interfaces did not see traffic due to no limits assigned and no subtree.
  • I was not aware how “stupid” (as in not intelligent) bandwidth handling is in a queue. Without max bandiwdth it will overload and then create a clusterfuck in priorities. So, basically, you HAVE to assign max limit and it HAS to be low enough. I now run 464kbit on the PPTP tunnel over a 512kbit physical link that is limited to 640k and it works fine.

Once that was cleared - guess what :wink: Worked. Even under full file transfer load I now have relatively stable ping times (varying between 35 and 55ms, to be expected as in the end large packets are clocking the one link I currently use). Prioritisation works perfectly.

The second one really is an issue here. I would ahve expected some smarter behavior - basically keeping a small queue on the interface, then always pulling the highest priority items from the queue tree would allow one to NOT set a maximum if it means “up to wire speed”. This triggers thigns gtting lost, though. And then somehow the whole queueing thigns get nasty - this iws when ping times started going up to 2000ms. It seems to be a bug, but one that is well hidden.

On top of that, sorry, dthe documentation is a piece of crap. Obviousy written by tech people. Mikrotik should fork out the money for a manual and a TECH WRITER. THere are people who make a job out of writing documentation one can read without knowing the stuff first.

I will put up on the weekend a WIki article explaining how to make this scenario in a “simple” way. Not going in every fglory detail, but explaining the problems step by step.