RouterOS v5 RC2

TKITFrank · Wed Oct 27, 2010 5:58 pm

What's new in 5.0rc2 (2010-Oct-27 16:20):

*) wireless nv2 - encryption support;
*) tool fetch - support ftp STOR;
*) ospf - fixed crash when working with external LSA that contain
forwarding addess;
*) ipsec - supports NAT-T drafts;
*) ipsec - added debug logging, to maintain same log verbosity as before with
'ipsec' topic now use topics 'ipsec,debug,!packet';
*) ipsec - make it work with EoIP, GRE, PPTP and L2TP;
*) support for Atheros AR9271 wireless chip;
*) added support for more Intel 82575/82576 PCI-Express Gigabit Ethernet cards;
*) added support for idle detection on RB1xx/RB5xx in /tool profile;
*) fixed Wireless manual tx power configuration for 11n rates in WinBox;
*) fixed torch;

alexspils · Wed Oct 27, 2010 7:51 pm

installed it on my home 411ah based ap.dynamic Dhcp+simple nat setup forking fine.Noticed Distance value in wireless status, cool

jcem · Wed Oct 27, 2010 7:59 pm

- Showing 28V constantly on RB433AH - showed correct 13V in rc1

- Somehow draws a lot more power. The RB433AH reboots with "power outage" even if I disable two radio cards
I know that I'm short on amperage to this site due to over 500m power-cord, but has never
been un issue before...
Had to rapidly downgrade to rc1 again

- CPU goes 100% randomly and reboots - this happens on all of my RB's

RGDS

Copper · Wed Oct 27, 2010 8:12 pm

SNMP bug still present.
PCQ not work properly.

rpress · Wed Oct 27, 2010 8:15 pm

Wow, support for ipsec NAT-T!

Still crashes WinBox when opening up an IPv6 route on my RB750. It has done this ever since the new WinBox GUI look. It did this even with a clean install.

gustkiller · Wed Oct 27, 2010 8:17 pm

finally,

going to test it tonight!

TKITFrank · Wed Oct 27, 2010 8:58 pm

The connection-mark / Mangle passthrough bug is gone as well.

Looks like the cpu on my RB800 can now be set to 1200MHz it was 1000Mhz as max before.

colebert · Wed Oct 27, 2010 9:05 pm

Missing dBs between v4.11 and 5.0rc2

http://forum.mikrotik.com/viewtopic.php ... 1&p=233528

ayufan · Wed Oct 27, 2010 9:20 pm

- bug in torch still present
- nat-t not working with windows xp

roadracer96 · Wed Oct 27, 2010 10:43 pm

- bug in torch still present
- nat-t not working with windows xp

I just tried it with a PSK and it worked on my Win7 laptop., Dunno about WinXP. But that is a step in the right direction. Gotta try it with multiple clients/certificates next.

ayufan · Wed Oct 27, 2010 11:02 pm

I just tried it with a PSK and it worked on my Win7 laptop., Dunno about WinXP. But that is a step in the right direction. Gotta try it with multiple clients/certificates next.

Did you try behind NAT?

colebert · Wed Oct 27, 2010 11:06 pm

When switching between v4.11 and rc2 the MCS rates increase one level.

For example, when I upgraded a link that was set for MCS5 the link came back up set for MCS6. I was able to reproduce this problem.

gustkiller · Wed Oct 27, 2010 11:11 pm

torch working here (x86)

w0lt · Thu Oct 28, 2010 2:00 am

The firewall is still acting goofy on the drop chain. This was preset on RC1 as well....

-tp

roadracer96 · Thu Oct 28, 2010 2:56 am

I just tried it with a PSK and it worked on my Win7 laptop., Dunno about WinXP. But that is a step in the right direction. Gotta try it with multiple clients/certificates next.
Did you try behind NAT?

Yep. From my laptop behind NAT.

Chupaka · Thu Oct 28, 2010 3:27 am

PCQ not work properly.

'properly'?..

ayufan · Thu Oct 28, 2010 3:29 am

Yep. From my laptop behind NAT.

I did test it a minute ago and it doesn't work. Neither with nat-t enabled nor disabled ;)

wispwest · Thu Oct 28, 2010 5:02 am

I wish we could really see the real rated TX power for the SR71-15. Looks like its only getting worse...as shown from Colberts screen shots.

mattx86 · Thu Oct 28, 2010 6:50 am

From the bugs I've reported in 5.0rc1 and from what I've re-tested and observed in 5.0rc2, it seems that the following changes are missing from the 5.0rc2 change log (correct me if I'm wrong):
*) ip packing - no longer locks up system;
*) log - now shows source IP address for SSH connections, like it used to;
*) log - now shows ethernet link status in the log (simple up/down status);

Regarding torch (on my RB532/mipsle system):
While running a web-based speed test with torch running and the LAN interface's traffic graph visible, I can see that the download portion of the speed test continues to be graphed, while the connection listing for it in torch will randomly disappear and reappear. I assume this occurs on the upload portion of the test as well.

Regarding NAT-T:
The changelog only seems to indicate support for NAT-T under IPSec, and not NAT-T for general use.

To be sure, I...
- setup a simple web server on my computer
- enabled a NAT rule for it
- disabled my Firewall drop rules on the input and forward chains
- made sure I could access it from my computer
- made sure that Google Translate could access it and translate it (I've even got the IP address where Google Translate connected - 74.125.75.17)
- attempted to access it using the same URL that I gave Google translate, and it did not work.

roadracer96 · Thu Oct 28, 2010 7:54 am

You are thinking about the wrong thing. Nat-T for ipsec has nothing to do with the firewall rules. It has to do with the client behind the firewall connecting to a IPSEC server out in the wild reporting a private IP but originating from a public IP.

Thu Oct 28, 2010 8:12 am

The firewall is still acting goofy on the drop chain. This was preset on RC1 as well....

Probably there is some issue with some specific option/value combination, you should go through your firewall - with disable/enable portions of rules (be carefull do not lock yourself out the router) and this way you should be able to find exact rule/option in the rule, that don't let your firewall start properly (that is the reason for these interesting numbers)

Please, keep us posted what option and what values were problematic.

Thu Oct 28, 2010 8:38 am

Regarding NAT-T:
The changelog only seems to indicate support for NAT-T under IPSec, and not NAT-T for general use..

Yep, you are right only IPSec:

Lets log winbox ---> IPsec ---> Peer tab ---> press "+" ----> and here it is " NAT Traversal" checkbox - enjoy

Thu Oct 28, 2010 9:32 am

When switching between v4.11 and rc2 the MCS rates increase one level.

For example, when I upgraded a link that was set for MCS5 the link came back up set for MCS6. I was able to reproduce this problem.

please provide us more info with the screenshots and description how did you test it. Send that info to support@mikrotik.com. Also include the support output files from both versions.

Thu Oct 28, 2010 10:30 am

The firewall is still acting goofy on the drop chain. This was preset on RC1 as well....

-tp

problem is with the 'content' matcher. Avoid using it and rest of the firewall will work fine. We will fix it in the next version.

hurley12345 · Thu Oct 28, 2010 11:12 am

I wish we could really see the real rated TX power for the SR71-15. Looks like its only getting worse...as shown from Colberts screen shots.

I have numerous SR-71's in Place. and would like to get the right TX power for these Wireless cards.

brianchrist · Thu Oct 28, 2010 12:39 pm

where i can download it?
the download link at http://www.mikrotik.com/download.html is broken

Thu Oct 28, 2010 12:41 pm

which link is broken? works for everyone else

Thu Oct 28, 2010 1:20 pm

What's new in 5.0rc2 (2010-Oct-27 16:20):

*) wireless nv2 - encryption support;

This is completely independent to security profile set in Interface->Wireless?
So when connecting with 802.11 or nstreme security profile is taken?
When connecting with nv2 the PSK set in NV2 is taken?

Thu Oct 28, 2010 1:21 pm

when you use Nv2 on the AP, then only Nv2 clients can connect anyway. No other settings matter. Yes, Nv2 security is configured separately in the Nv2 menu.

brianchrist · Thu Oct 28, 2010 1:55 pm

which link is broken? works for everyone else

got it. it's only available on czech and germany site

Thu Oct 28, 2010 2:02 pm

if you find mirror links that don't work, let us know please

Stanislav Hrncir · Thu Oct 28, 2010 6:05 pm

Poor stability than prerelase of rc2 - all things was ok on prerelase.. now its broken
1. Bios upgrade shows old bios "" upgrade bios "2.27" after upgrade all bios settings go to default and any change / console or manually in bios / doesnt have any change" only option is take "good" 2.27 bios and flash it
2. Unstable with full throughtput or btest - goes to reboot with kernel panic
3./system backup load file= ..... hangs rb
4. /system check-installation shows bad crc for kernel

All this bugs are on RB800 and x86

Chupaka · Thu Oct 28, 2010 6:26 pm

4. /system check-installation shows bad crc for kernel

maybe that's the reason? it's okay for me on x86

wildbill442 · Thu Oct 28, 2010 8:13 pm

My switch group 1 on my RB1100 seems to have stopped working after the upgrade... Had to move hosts to the other switch group in order to restore connectivity...

I haven't done much troubleshooting yet, I'll try resetting the configs and reconfiguring and report back.. Just wondering if anyone else had similar problems?

Stanislav Hrncir · Thu Oct 28, 2010 8:51 pm

4. /system check-installation shows bad crc for kernel
maybe that's the reason? it's okay for me on x86

but this is same problem for all rb800 that i have... and some x86

wildbill442 · Thu Oct 28, 2010 9:00 pm

My switch group 1 on my RB1100 seems to have stopped working after the upgrade... Had to move hosts to the other switch group in order to restore connectivity...

I haven't done much troubleshooting yet, I'll try resetting the configs and reconfiguring and report back.. Just wondering if anyone else had similar problems?

Downgrading to 5.0rc1 and then removing the switch configuration and re-adding it seemed to fix the problem.

After upgrading back to 5.0rc2 removing the switch configuration seemed to make my host lose connection even though I was connected through the second switch group. Trying to readd the ports to the switch again caused me to lose connection.

Under RC2 switch group 1 (ether1 - 5) will show physical links (based on router and host LAN LEDs) but when actual connectivity is tested it shows net unreachable as if there were no physical connection.

Downgrading to RC1 fixes the problem... I'll forward a supout.rif to support.

gustkiller · Fri Oct 29, 2010 1:42 am

here so far so good, dispite the rx drops about 3k a day..

Fri Oct 29, 2010 7:42 am

Poor stability than prerelase of rc2 - all things was ok on prerelase.. now its broken
1. Bios upgrade shows old bios "" upgrade bios "2.27" after upgrade all bios settings go to default and any change / console or manually in bios / doesnt have any change" only option is take "good" 2.27 bios and flash it
2. Unstable with full throughtput or btest - goes to reboot with kernel panic
3./system backup load file= ..... hangs rb
4. /system check-installation shows bad crc for kernel

All this bugs are on RB800 and x86

This is fixed in RC3, sorry about that. Wireless crashes on big throughput. I think all of your problems are actually one problem, but will check.

roddie · Fri Oct 29, 2010 8:21 am

Downgrading to 5.0rc1 and then removing the switch configuration and re-adding it seemed to fix the problem.

After upgrading back to 5.0rc2 removing the switch configuration seemed to make my host lose connection even though I was connected through the second switch group. Trying to readd the ports to the switch again caused me to lose connection.

Under RC2 switch group 1 (ether1 - 5) will show physical links (based on router and host LAN LEDs) but when actual connectivity is tested it shows net unreachable as if there were no physical connection.

Downgrading to RC1 fixes the problem... I'll forward a supout.rif to support.

Same problem here -- My interfaces were a big mess after going from RC1 to RC2. Most of them didn't come up properly; perhaps a negotiation issue. Downgrading to RC1 (and to 4.x) fixed it.

Fri Oct 29, 2010 9:00 am

SNMP bug still present.
PCQ not work properly.

clarify both please

Fri Oct 29, 2010 9:45 am

When switching between v4.11 and rc2 the MCS rates increase one level.

For example, when I upgraded a link that was set for MCS5 the link came back up set for MCS6. I was able to reproduce this problem.

MCS settings were messed up in Winbox in previous versions.

Winbox had mcs-1, mcs-2, etc
while console had mcs-0, mcs-1.

Fixed it in v5.0rc2. Winbox now has mcs-0, mcs-1, etc.

EMOziko · Fri Oct 29, 2010 11:53 am

Hello, I cant download rc2.
it said 404 - Not Found

Fri Oct 29, 2010 11:53 am

post link which didn't work! try other links (other mirror, or torrent)

EMOziko · Fri Oct 29, 2010 12:01 pm

post link which didn't work! try other links (other mirror, or torrent)

http://download.mikrotik.com/routeros-mipsbe-5.0rc2.npk

i ll try torrent now.

EMOziko · Fri Oct 29, 2010 12:04 pm

yeah thank you serbia, finnaly i downloaded from serbian mirror

martini · Fri Oct 29, 2010 12:20 pm

fixed issue with torch and intel ethernet, but now if i enable QUEUE i cant see TX traffic on interface )) because queue catch traffic before torch )) and if i disable queue i can see all traffic )

Fri Oct 29, 2010 12:26 pm

post link which didn't work! try other links (other mirror, or torrent)
http://download.mikrotik.com/routeros-mipsbe-5.0rc2.npk
i ll try torrent now.

works for me

martini · Fri Oct 29, 2010 3:14 pm

http://download.mikrotik.com/routeros-mipsbe-5.0rc2.npk

dont work for me

Chupaka · Fri Oct 29, 2010 3:16 pm

works for me =)

npyoung · Fri Oct 29, 2010 5:04 pm

Tried it on several of our RB433AH...serial kernel failures and reboots. Had to roll back to rc1.

npyoung · Fri Oct 29, 2010 5:15 pm

BTW, noticed that as long as there wasn't much traffic going through the RB433AH's that were undergoing serial kernel failures with rc2 they would stay up long enough for me to upload rc1 and downgrade. So...if you are testing on a board that isn't in production (of course you are), you may not see this problem. Systems under load wouldn't stay up for more than a few minutes at a time before crashing.

wildbill442 · Fri Oct 29, 2010 6:37 pm

Poor stability than prerelase of rc2 - all things was ok on prerelase.. now its broken
1. Bios upgrade shows old bios "" upgrade bios "2.27" after upgrade all bios settings go to default and any change / console or manually in bios / doesnt have any change" only option is take "good" 2.27 bios and flash it
2. Unstable with full throughtput or btest - goes to reboot with kernel panic
3./system backup load file= ..... hangs rb
4. /system check-installation shows bad crc for kernel

All this bugs are on RB800 and x86
This is fixed in RC3, sorry about that. Wireless crashes on big throughput. I think all of your problems are actually one problem, but will check.

*) fixed problem - bad boot/kernel crc was reported on powerpc boards
when in fact it was good;

Normis,

Does RC3 fix the problem with the switch chip / interfaces I described above?

w0lt · Fri Oct 29, 2010 7:46 pm

The firewall is still acting goofy on the drop chain. This was preset on RC1 as well....

-tp
problem is with the 'content' matcher. Avoid using it and rest of the firewall will work fine. We will fix it in the next version.

The problem still exists with RC3.

-tp

Fri Oct 29, 2010 8:33 pm

Poor stability than prerelase of rc2 - all things was ok on prerelase.. now its broken
1. Bios upgrade shows old bios "" upgrade bios "2.27" after upgrade all bios settings go to default and any change / console or manually in bios / doesnt have any change" only option is take "good" 2.27 bios and flash it
2. Unstable with full throughtput or btest - goes to reboot with kernel panic
3./system backup load file= ..... hangs rb
4. /system check-installation shows bad crc for kernel

All this bugs are on RB800 and x86
This is fixed in RC3, sorry about that. Wireless crashes on big throughput. I think all of your problems are actually one problem, but will check.
*) fixed problem - bad boot/kernel crc was reported on powerpc boards
when in fact it was good;

Normis,

Does RC3 fix the problem with the switch chip / interfaces I described above?

No,the fix for the switch chips will be only in the RouterOS v5.0rc4 which will me next week. Sorry

Fri Oct 29, 2010 8:33 pm

The firewall is still acting goofy on the drop chain. This was preset on RC1 as well....

-tp
problem is with the 'content' matcher. Avoid using it and rest of the firewall will work fine. We will fix it in the next version.

The problem still exists with RC3.

-tp

The fix will be only in RC4, sorry

Fri Oct 29, 2010 8:34 pm

BTW, noticed that as long as there wasn't much traffic going through the RB433AH's that were undergoing serial kernel failures with rc2 they would stay up long enough for me to upload rc1 and downgrade. So...if you are testing on a board that isn't in production (of course you are), you may not see this problem. Systems under load wouldn't stay up for more than a few minutes at a time before crashing.

Please upgrade to RouterOS v5.0rc3 - it will fix the crashing.

jcem · Fri Oct 29, 2010 9:02 pm

BTW, noticed that as long as there wasn't much traffic going through the RB433AH's that were undergoing serial kernel failures with rc2 they would stay up long enough for me to upload rc1 and downgrade. So...if you are testing on a board that isn't in production (of course you are), you may not see this problem. Systems under load wouldn't stay up for more than a few minutes at a time before crashing.
Please upgrade to RouterOS v5.0rc3 - it will fix the crashing.

I can confirm it works fine and doesn't crash on the links 3 links I've tested so far

RGDS

Copper · Sat Oct 30, 2010 2:33 pm

SNMP bug still present.
PCQ not work properly.
clarify both please

I test x86 -

Seems like PCQ is OK.
It was my mistake in queue tree config.

SNMP OIDs of "CPU load" return null or not correct values.
SNMP OIDs RFC1213-MIB::ipRouteDest not present at all (in v4 works fine).
SNMP OIDs of Queue Tree counters works only when i connect to router with Winbox and open window Queue Tree. As soon as I disconnect Winbox all OIDs of Queue Tree return null.

RC3 not tested yet.

Chupaka · Sat Oct 30, 2010 3:57 pm

SNMP OIDs of Queue Tree counters works only when i connect to router with Winbox and open window Queue Tree. As soon as I disconnect Winbox all OIDs of Queue Tree return null.

I can't see such behaviour neither on rc2, nor rc3 (x86)

Copper · Sat Oct 30, 2010 4:44 pm

SNMP OIDs of Queue Tree counters works only when i connect to router with Winbox and open window Queue Tree. As soon as I disconnect Winbox all OIDs of Queue Tree return null.
I can't see such behaviour neither on rc2, nor rc3 (x86)

But i see. On pre1-RC2, pre2-RC2, RC2.

And we really need an RFC1213-MIB::ipRouteDest.
When will it be available in v5 ?

When i downgrade to v4 SNMP is work fine.

What additional information is needed from me to discover this problems?

Chupaka · Sat Oct 30, 2010 6:21 pm

But i see. On pre1-RC2, pre2-RC2, RC2.

with no Active Users I do

snmpwalk -v2c -c public ROUTER 1.3.6.1.4.1.14988.1.1.2.2.1.7

- it shows correct results:

SNMPv2-SMI::enterprises.14988.1.1.2.2.1.7.16777216 = Counter64: 0
SNMPv2-SMI::enterprises.14988.1.1.2.2.1.7.16777217 = Counter64: 0
SNMPv2-SMI::enterprises.14988.1.1.2.2.1.7.16777218 = Counter64: 259317068

Copper · Sat Oct 30, 2010 7:04 pm

Just tested.
Strange.

For monitoring i use ZABBIX and with v4 ROS all fine.
On v5 - was as I explained earlier (WinBox trick).

Indeed, snmpwalk in command line works, but ZABBIX did`t receive any data of Queue Tree OIDs without WinBox.
Miracles.
Where to find the cause?

Chupaka · Sat Oct 30, 2010 7:09 pm

run Wireshark, check for exact SNMP queries...

Copper · Sat Oct 30, 2010 8:01 pm

run Wireshark, check for exact SNMP queries...

I found the error !
Chupaka, try

tshark -V -Ttext ip host ROUTER and port 161 | grep Counter64

Return values are always the same, they do not change!
They begin to change only when you run WinBox and open Queue Tree window.
That is why I've seen zero flow rate in ZABBIX.

Mikrotik, I'm doing for you your job

When you fix this error
and CPU OIDs
and RFC1213-MIB::ipRouteDest OID
?

Chupaka · Sat Oct 30, 2010 8:30 pm

Return values are always the same, they do not change!
They begin to change only when you run WinBox and open Queue Tree window.

actually, that was the second thing I checked... values were changing =)

Copper · Sat Oct 30, 2010 8:32 pm

Return values are always the same, they do not change!
They begin to change only when you run WinBox and open Queue Tree window.
actually, that was the second thing I checked... values were changing =)

No.
For PCQ queues they do not change.

Copper · Sat Oct 30, 2010 8:52 pm

Chupaka, when

snmpwalk -v2c -c public ROUTER 1.3.6.1.4.1.14988.1.1.2.2.1.7

values changing.

but if request for one queue counter

snmpwalk -v2c -c public ROUTER 1.3.6.1.4.1.14988.1.1.2.2.1.7.16777218

values always the same.

Try.

Chupaka · Sat Oct 30, 2010 9:46 pm

now I can confirm that on rc3 =)

data refreshes only when Queues window is opened in WinBox or when you do snmpwalk over the whole tree... have you opened a support ticket?

p.s. I must use rc3 in production - previous versions do not see most of the hardware of that server... how many 'features' will I face on that way?..

p.p.s. as a workaround, I will use that:

/system scheduler
add disabled=no interval=4s name=schedule1 on-event="/queue tree print stats" \
    policy=read start-date=jan/01/1970 start-time=00:00:00

Copper · Sun Oct 31, 2010 12:21 am

No, i did`t open a support ticket.

Thanks for the workaround solution.

Copper · Sun Oct 31, 2010 11:34 am

No, the PCQ error is present - http://forum.mikrotik.com/viewtopic.php?f=2&t=46206

I thought that the case is not the optimal settings, but no.
PCQ still does not work as expected.
And I noticed that immediately after reboot PCQ works about well, but over time begins to run from bad to worse.

Previously, I used v3.30 RB1000 as PCQ-shaper. All works fine.
Then I had to use the x86, because high CPU load on RB1000.
And the problems with shaper started.
I test 4.11, 4.12, 5.pre1-RC2, 5.pre2-RC2, 5.RC2 - PCQ not work as in 3.30.

Chupaka · Sun Oct 31, 2010 2:03 pm

how can one repeat that behaviour?

Copper · Sun Oct 31, 2010 2:58 pm

how can one repeat that behaviour?

Create 2-4 PCQ queues in Queue Tree and test rate on sub-streams and look at drops.
One queue works OK, but if they are several, and the traffic goes through them at the same time, the problems begin.
Even though the packet rate is small, below the limit-at, multiple drops occur and rate of sub-streams like a sawtooth form and is not approaching its pcq-rate.

English is not my native language, so I sometimes difficult to clearly explained to.

Copper · Sun Oct 31, 2010 4:12 pm

27k packet drops within 5 minutes, although none of the limits are not exceeded and sub-streams is not approaching its pcq-rate!
On RB1000 v3.30 nothing like this was not observed.

Chupaka · Sun Oct 31, 2010 11:06 pm

what type does that rule have?

Copper · Mon Nov 01, 2010 12:32 am

what type does that rule have?

kind=pcq pcq-rate=500k pcq-limit=75 pcq-classifier=dst-address pcq-total-limit=20000
kind=pcq pcq-rate=1M pcq-limit=75 pcq-classifier=dst-address pcq-total-limit=20000
kind=pcq pcq-rate=2M pcq-limit=75 pcq-classifier=dst-address pcq-total-limit=5000

Chupaka · Mon Nov 01, 2010 1:22 am

so, if one user greatly exceeds it's limit (1 or 2 megs) and has over 75 packets in queue, it can lead to drops - nothing unusual for now... I see it in my v3.28 =)

Copper · Mon Nov 01, 2010 11:50 am

Chupaka, I have works fine on v3.30 too. Just test v5.

... Even though the packet rate is small, below the limit-at, multiple drops occur and rate of sub-streams like a sawtooth form and is not approaching its pcq-rate.

In v5 i`ve never seen that bandwidth of PCQ-queue once approached to its max-limit.
I can set 100M limit-at or max-limit, can set 250M - queue rate does not change and rate of drops remain the same.

All I am saying applies to the situation when running a lot of subscribers, more than 50-100 per PCQ-queue.
The impression is that the shaper runs into some inner-limiting and begins to drop packets even in streams that have not reached their pcq-rate.

Copper · Mon Nov 01, 2010 1:31 pm

I test RC3 - seems PCQ works even worse then in RC2.

Chupaka · Mon Nov 01, 2010 1:55 pm

I mean, I have drops on v3.28 too. the reason is not max-limit, but pcq-limit - if user's subqueue is too short to shape peak traffic, the rest packets will be dropped

Copper · Mon Nov 01, 2010 2:13 pm

Look at one stream with
kind=pcq pcq-rate=1000000 pcq-limit=100 pcq-classifier=dst-address pcq-total-limit=15000
Its one file downloading via http from server near the router (not from Internet).

Chupaka · Mon Nov 01, 2010 4:36 pm

and what if you change pcq-limit to, for example, 1000?

Copper · Mon Nov 01, 2010 6:58 pm

and what if you change pcq-limit to, for example, 1000?

Я устал издеваться над своими абонентами и проводить на них тесты.
Совесть уже заела.

Тестируйте сами, если интересно.
Но вообще-то это работа Mikrotik.
Жаль что никто из компании даже не удосужился хоть что-то сказать и дать совет по поводу проблем о которых я тут уже неделю пишу.

Видимо придётся другие решения искать и отказываться от ROS.

Chupaka · Mon Nov 01, 2010 7:10 pm

if you have found a bug - write to support@

this is Community Forum

Copper · Mon Nov 01, 2010 7:27 pm

If you still want to test, create two PCQ-queue and make sure that limit-at in Queue Tree does not work.
Enough to make the same priority and let the traffic through both the queues.
After that, try changing priorities, you ensure that the limit-at not working.

The second thing - the calculation of the free bandwidth and value pcq-rate.
Looks like max-limit simply divides by the current value pcq-sub-stream-count and the pcq-rate decreases to this result. And no matter what there is a lot of free bandwidth, and even limit-at value is not reached.
Or vice versa - pcq-rate multiplied by the pcq-sub-stream-count and the value is said to be occupied bandwidth.

Frankly, I'm tired to try to understand what is happening with PCQ.
I'd love to hear words from Mikrotik.

Chupaka · Mon Nov 01, 2010 7:38 pm

if you have limit-at=10M, pcq-rate=1M and huge traffic in that queue for particular user, packets will be dropped - PCQ will shape/drop it by pcq-rate, HTB's limit-at value will not affect the situation

The second thing - the calculation of the free bandwidth and value pcq-rate.
Looks like max-limit simply divides by the current value pcq-sub-stream and the pcq-rate decreases to this result

I already posted - I cannot repeat this behaviour...

Copper · Mon Nov 01, 2010 7:48 pm

if you have limit-at=10M, pcq-rate=1M and huge traffic in that queue for particular user, packets will be dropped - PCQ will shape/drop it by pcq-rate, HTB's limit-at value will not affect the situation

I've said a hundred times - subscribers do not approaching its pcq-rate!
I even brought a picture of rate the one pcq-substream.

I already posted - I cannot repeat this behaviour...

So what?
You are tested on hundreds of threads with a version v5?

rmichael · Mon Nov 01, 2010 7:53 pm

Copper's experience seems to mirror mine. I did notice a change in PCQ behavior between v4.5 to v4.10. Not to repeat myself here's what I wrote in another thread:

Have anyone noticed PCQ dropping packets or unnecessary queuing even though the packet rate is small, way below any of the limits (even limit-at)? Cpu is below 20%, queue size is 50/300, 1-3 PCQ streams.

I see it on RB750 with ROS4.11 and ROS4.10 (150 HTB queues) but I don't see it on RB493AH ROS4.5-same traffic, same rules, queue sizes etc.

Btw, PCQ , per MT, is designed to reach about 80% of bandwidth of max-limit with single stream. This is so new TCP sessions have a room to increase their TCP window sizes and grab more bandwidth and compete with already established streams. In my tests PCQ could never reach max-limit with only one stream. On larger scale, perhaps PCQ reserves a percentage of bandwidth for each stream outright - even if stream does not need as much.

Copper · Mon Nov 01, 2010 8:03 pm

What channels do you work?
You tried to pass through ROS pcq-shaper the flow of more than 100 megabits?

gustkiller · Mon Nov 01, 2010 9:43 pm

Is snmp working when running full bgp table, and just for monitor interface traffic?

Copper · Mon Nov 01, 2010 9:57 pm

Is snmp working when running full bgp table, and just for monitor interface traffic?

I do not use full bgp, just 2 peer and default route, with that, SNMP interface counters works fine.

Copper · Thu Nov 04, 2010 11:25 am

My problem with the shaper resolved by replacing the network card.
Losses at the interface was not, CPU load was low, but the network card was faulty.
x86-based selection and testing equipment for the ROS is an important matter.

Shaper was not guilty.

Chupaka · Thu Nov 04, 2010 2:47 pm

wow, thanks. nice to hear that =)

Who is online