I think in 6.31 the leases page gets eventually emptied. I downgraded to 6.30.4

And you did right.

Hello Folks!

Issue with CCR1016, after some days of operation suddenly port ether1 at random stop forwarding traffic for intervals and comes back on-line again. There is nothing in the log files or any other logs either, no support file or something like that.

I restarted the CCR1016 and situation calmed down and went back to normal operations.

I am unable to upgrade/downgrade off the broken v6.32 on a RB911 as every attempt to reboot the unit will result with a hard freeze. Is there a way to set the upgrade process to ignore the reboot requirement and be happy with a plain power restore?

Hi Normis

I am trying to update my script. I have upgraded to 6.31 but i do not see any options in the terminal to change channel= "" and it is always on current channel.

Am i missing something?

I found it
But now the upgrade feature works slightly differently.
This still reboots automatically just like upgrade command in earlier versions

Noticed that 6.30.4 doesn't support channel feature. So we will have to wait until a new 6.31.x version before implementing channel selection into script upgrades.

Thanks!!

Unless I missed something, is my recap of Fast Track aspects below correct? Please chime in. Especially Jarda.

FAST TRACK:
Objective: Just to recap the issues in respect to Fast Track feature from 6.29 (from memory).

How: To speed up subsequent incoming traffic packets ONCE the initial few from SAME source to destination have been already authenticated as legitimate. (I don't think people care about bittorrents not being fast tracked).

Constraints: VoIP queue priorities need to be preserved. Simple reason is that speeding up of packets (by fast tracking) should not render existing VoIP queue priorities useless when bandwidth is full with packets incoming and outgoing. Simply put, Fast Track does not make the size of the bandwidth pipe bigger. It only removes processing at internal 'checkpoint'.

From this angle, it's clearly desirable to preserve the intended working of QoS of VoIP (via queue priorities) for obvious reason. It's why queue priorities were setup in the first place.

Challenges: How to make packets fast tracked STILL subject to queue priority. It's kinda ironic, as I understand it.

Consideration: But what is the benefit in fast tracking normal connections (e.g. downloading a file) while it breaks yous VoIP conversation? It happened on my VoIP line despite having a 100mbps down and 2.4mbps up bandwidth at home. The other party could not hear me properly on the phone when Fast Track was on. I had to turn Fast Track off in the end.

In certain circumstances, Fast Track, while in its early stage of development (still a way to go before reaching maturity), does have its value.

My two cents. With respect.

Just an FYI: Using AES with GCM still causes a kernel crash in 6.33rc3

MTeeker, I am on mobile for couple of days now, so sorry for my short answer. Generally your post should be rather in fasttrack thread then in this version related discussion. But anyway. Fasttrack says not to process selected packets by firewall at all. If the queuing is part of firewall, these packets bypassing queues as well so you cannot calculate the qos at all. The reason for using the fasttrack is to lower the workload of the router and be able to push more thru. So. If your router is not working on the edge before you reach your pipes limits, you don't need to use fasttrack at all. If your router isn't able to pass so much traffic, you can buy more powerful one or spare money and try fasttrack. There are some applications where you can benefit from it. Maybe it isn't your case but you can try to think what kind of traffic you can let pass around the firewall if you need to.

I don't think people care about bittorrents not being fast tracked.

Fasttrack reduce CPU load at times (50-70 -> 30) on my RB951G-2HnD while downloading torrents at 100Mbit.

Jarda,

I tried to post where Fast Track was discussed but the thread was closed. It crossed my mind that it was somehow a bit odd as your sharp eyes detected it. .

My VoIP queue tree is based on mangle marking packets at pre-routing chain. And while Fast Track was on, my conversation was broken on the other party's receiver if I initiated the call.

So it seems Fast Track neutralizes my VoIP QoS settings. (With relatives in the US, I need VoIP to contact them without paying an arm and a leg).

I believe your reply basically confirms my understanding of Fast Track. My router is right behind my ISP's modem which is bridged.

I do like Fast Track. It has its usefulness in allowing more incoming traffic passing through.

But I think the real challenge for MikroTik is: Is it possible to have Fast Track features functioning only in the 'remaining nominal bandwidth' therefore RouterOS preserves QoS for VoIP while a VoIP is in progress.

I agree with you that a faster routerboard helps processing packets faster. But I'd also think a faster routerboard also benefits from Fast Track.

Cheers

hatred,
Sure. I was simply making the comparison point that users would be concerned about the breaking up of a VoIP conversation but it would not be critical if bittorrents are not fast tracked.

Generally I have nothing against the fasttrack itself too. I just do not consider the situation around the counters to be clever enough. I believe that the counters could be corrected so even the qos could be used when fasttracked traffic will be counted into total queues one day. Seems we have pretty close opinions. Now I am fasttracking intersubnet traffic and torrent traffic on some routers in order to be able to utilise the connectivity. Without fasttrack I wouldn't be able to reach the limits.

I upgrade RB750UP from 6.15 to 6.32 and I did not have any problem. RB750UP is powering up 4 devices (1 RB Metal5, 2 RB912, 1 NetMetal). Do I have to downgrade in any case?

The very same question!

I needed to swap my RB750UP 6.31 (AFAIK) devices due to unexpected huge port flapping/constantly rebooting one nasty morning (after some days worked OK! http://forum.mikrotik.com/viewtopic.php ... 36#p495636)... did not help at all, so I've tried and finally catched a moment between reboots and loaded 6.32rc5 into it... well, it looks stable. Then I've read "*) fix port flapping RB750UP blabla" in changelog (GREAT! Just in time, saving me), but some minutes later I saw "6.32 current" with the same bug fix and installed it too.

Well, my RB750UP works rock solid as PoE, Bridging Firewall with Simple Queues and some NAT rules for 5+ days uptime! But it can't see neither 6.32 nor in 6.32rcX with that magic RB750UP port flapping bugfix (and my special "management process 100% CPU", hanging Bridging Firewall bugfixes http://forum.mikrotik.com/viewtopic.php ... 95#p493595) in MT download area...

So, I use officially unsupported 6.32 as most stable after 6.28 for now. Why that so important bugfixes are not included into 6.30.4? I don't want to destroy all my network by that downgrade.

JFYI, I've firmware 3.25.1, but able to "upgrade" only to 3.24 now -- may be it's important too.

marting - Now you can not change dynamic queues also through CLI. Dynamic items should not be editable.

What???? Why? My whole system relies on this. And it works great, so why do you remove a feature??? It is necessary for me to change rate limit on dynamic pppoe queues as ROS is still not able to change rate limit by CoA with Radius and PPPoE server.
My intention at this bug report was to make the change possible also via Winbox and Web. Not to make it impossible the other way around.
Man, please undo this change. If it´s too much effort to implement it for web and winbox, then leave it with CLI.

Didn´t read anything from this "fix" in the changelog.

+1 undo this
we also use pppoe with dynamic queues and IPs, we have scripts that double speeds between 00 and 10 and now this not working

Hello Folks!

Usually I stay away from RC versions in production, this time there was no other way out.
RB750 started to flap ports and one CRS fully locked and had to be power cycled.
Only way out was to upgrade to RB6.33rc3, we tried to downgrade to latest stable below 6.31 but it did not help.
Result was a fully outage for 15 minutes at one site and multiple days problems on the site with RB750 till flapping was discovered in some logs.

New 6.32.1 is out with all important fixes included. It is in the current release chain, Bugfix (Stable) is still v6.30.4
http://forum.mikrotik.com/viewtopic.php?f=21&t=100290