Community discussions

 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 6:44 pm

RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
Or people had other RADIUS services (devices) connecting to it. You know, because that never happens. #genius. Depending on the IOS version Cisco will timeout at 5 seconds. MikroTik employees. If you are confronted with the choice between allowing something to be configurable with a sensible default vs a static unchanging value always choose configurable.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 880
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 7:49 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
 
User avatar
eworm
Member
Member
Posts: 354
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 10:44 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 10, 2017 11:34 am

When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.
 
kamillo
Member Candidate
Member Candidate
Posts: 154
Joined: Tue Jul 15, 2014 5:44 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 10, 2017 1:06 pm

To add to JimmyNyholm's comment: I'm still waiting for LACP hardware support (offload) in CRS125
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 11, 2017 5:00 am

When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.
Forum police @andirys will probably ask you to post in feature request.

But yes, this is definitely needed in urgency.
 
ryba84
just joined
Posts: 10
Joined: Sat Feb 07, 2015 1:18 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 12, 2017 3:38 pm

*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 10:37 am

*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.
The default firewall is using lists now. When you have upgraded from versions previous to 6.40 all the time and never
reset the configuration, your firewall is still using the old method. However, when you reset everything to defaults you
will find it uses lists WAN and LAN to identify the interfaces.
It depends on the amount of work you have put in your config if it is worth the trouble, of course.
 
ryba84
just joined
Posts: 10
Joined: Sat Feb 07, 2015 1:18 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 6:36 pm

Firewall uses interface lists, and this work for long time. But in new implementation You can include list in list, to use "master" list in firewall. This isn't working as expected. When Vpn clients are connecting, their dynamic interfaces are added to vpn-clients list. This list is included in some other list, which is used in firewall. Firewall should automaticly use this dynamic list to filter/nat/etc.., but this doesn't happen. Interfaces only from "master" list are working.

Wysłane z mojego SM-J710F przy użyciu Tapatalka
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5910
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 6:53 pm

@ryba84 report problem to support and attach supout rif file.
 
rac
just joined
Posts: 8
Joined: Fri Oct 15, 2010 4:47 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 12:09 pm

I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

/interface bridge port
add bridge=bridge interface=ether2 pvid=200
...
add bridge=bridge tagged=... untagged=ether02,.. vlan-ids=200
...
/interface bridge set bridge vlan-filtering=yes

I stuck in two tasks.
A) How to I secure the ports like "/interface ethernet switch port set ether3 vlan-mode=secure vlan-header=always-strip" on https://wiki.mikrotik.com/wiki/Manual:S ... Offloading?

I tried
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether03 pvid=200
but I do not really understand if it does what I want.

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 7:47 pm

I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

/interface bridge port
add bridge=bridge interface=ether2 pvid=200
...
add bridge=bridge tagged=... untagged=ether02,.. vlan-ids=200
...
/interface bridge set bridge vlan-filtering=yes

I stuck in two tasks.
A) How to I secure the ports like "/interface ethernet switch port set ether3 vlan-mode=secure vlan-header=always-strip" on https://wiki.mikrotik.com/wiki/Manual:S ... Offloading?

I tried
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether03 pvid=200
but I do not really understand if it does what I want.

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
you need to add your bridge interface to tagged ports.
 
raffav
Member Candidate
Member Candidate
Posts: 278
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 10:03 pm

Hi
i am unable set a untagged management ip address using a RB450G and a CRS125
i had followed the wifi but i dont get it

any one can help
 
marekm
Member Candidate
Member Candidate
Posts: 195
Joined: Tue Feb 01, 2011 11:27 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 12:05 am

*) w60g - general work on PtMP implementation for 60 GHz connections;
Devices in the Wireless Wire kit come with Level 3 licenses - will it work with more than one client, or is it necessary to buy a Level 4 license to test 60GHz PtMP?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 1:03 am

Been a long day.

I'm tasting my first time experience on 10gbit sfp+ on CRS326. I have a 10gbit nic (also first time) connected directly to the CRS326 and couldn't figure out why iscsi rates to a single client in my test environment were unstable 10-40MB/sec, at times less than 10MB/sec, FAR slower than gigabit nic. Rates are stable on the gigabit ports (80MB/sec). I tested samba transfers on the sfp+, and speeds appear quick. So it's just iscsi where transfer rates are quite quirky.

After a lot of testing, trying to figure out where the point of issue is -- ixgbe driver, iscsi initiator/target, etc etc.. it finally hit me it could be the 6.41 bridge implementation.

Simply reverting to 6.40.5 gave me good stable expected rates.

So I'm simply reporting that sfp+ DEFINITELY have some hw offload issues or some other sort of issues. Sorry if my feedback isn't as clear as can be.

I hope you fellas are able to solve this on your own because I will not be able to test this again as the switch will be in live production this week.

Update: Contacted support and MT is already aware of the issue.
Last edited by biatche on Wed Nov 15, 2017 8:27 pm, edited 1 time in total.
 
User avatar
blajah
Member Candidate
Member Candidate
Posts: 224
Joined: Fri Jun 12, 2015 8:58 pm
Location: Belgrade, Serbia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 7:15 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Same here, 951g2hnd
 routerboard: yes
             model: 951G-2HnD
     serial-number: 4F4********
     firmware-type: ar9344
  factory-firmware: 3.10
  current-firmware: 6.41rc52
  upgrade-firmware: 6.41rc50
I have bigger routing table.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 8:28 pm

I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.
Last edited by pe1chl on Thu Nov 16, 2017 3:07 pm, edited 1 time in total.
 
User avatar
eworm
Member
Member
Posts: 354
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:34 am

Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
Possibly a read-only property "upgrade-available" is the easiest way to solve this?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
kait
just joined
Posts: 15
Joined: Thu May 10, 2012 12:09 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:53 am

Hi, I raise a new topic Bridge HW-Offload and VLAN-Filtering with CRS226-24G-2S+RM at v6.41rc52 here viewtopic.php?f=1&t=127805 , maybe someone can explain issue.
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:49 pm

RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
This makes no sense to me whatsoever. We have had it happen several times (in a particular scenario documented further below) where we had the timeout at first set to 3000 ms and the customer could not connect (due to the unusually high latency for bidirectional satellite Internet), but immediately after increasing the timeout, the customer connected successfully (after repeated automated connection attempts up until the instant of change). You are saying this is a coincidence? It seems really hard to believe given how many times it failed before making the change (several hours) and how immediately the change corrected the issue (after hours of trying to connect every minute and failing, the first connection after the change (30 seconds later) was successful).

We are dealing with bi-directional satellite so we have 600ms latency just to get up into orbit and back again with a ping, and we are dealing with very limited bandwidth. We cannot do "network improvements" to fix this.

Here is the precise justification for why 3000 ms is not enough with all attainable 'network improvements' implemented:

The initial RADIUS request from the satellite site takes 300-400 ms to get to the radius server due to limitations of the speed of light, then it has to look up the customer etc, probably half a second or second later it sends a reply which takes another 300-400ms to get back to the satellite site (again due to the limitations of the speed of light). This is now two seconds. This part is fine with your new limit, but the next part is not:

If the RADIUS server thinks the customer is already logged in, it contacts the MikroTik with SNMP to find out if there is actually an interface named <pppoe-customername>, this contact begins to happen at around the 2000 ms mark.

At this point, the RADIUS server has to send the SNMP request over satellite, receive the SNMP response over satellite, parse the list to determine whether the customer is logged in or not, and send the Access-Accept or Access-Reject reply back to the MikroTik. This entire process cannot happen in 3000 ms total from the opening authentication, when the basic authentication already uses 2000ms, and where each one way satellite transit thereafter takes 300-400 ms due to the limitation of the speed of light.

Suggesting that we make "network improvements" to fix this is basically asking us to move the satellite in orbit closer to the planet, or make the speed of light faster. It is not something that we can do. We are already doing queueing everywhere to prioritize the RADIUS and SNMP requests. 3000 ms is just not enough when you start taking satellite setups like ours into account. We really need this change reverted, or at least a more reasonable maximum of 5000 or 6000ms used. We have fixed this issue successfully by increasing the timeout on our routers to 6000ms but you have removed this repair from us by limiting this setting.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 10:38 am

I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 11:48 am

I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.
It is not just one location - we have 15 such locations. We would need 15 RADIUS servers. These locations have no air conditioning and so the internal shelter goes up to 40C in the summer and down to -30C in the winter. Local RADIUS server is NOT a good idea.

What am I supposed to do, go and tell my manager "yes, it is great that MikroTik is forcing us to buy 15 local RADIUS servers for 15 sites that will probably fail within a year or two due to inadequate environmental controls, all because they decided to limit an integer to 3000 that previously allowed 6000"??

Every time there is a failure at one of those 15 sites we have to fly in for a cost of more than a thousand dollars round trip. There are only usually between 2 and 15 customers at a given site, so in many cases we are losing money because what we charge customers in total is much less than what we have to pay for service; although we are a non profit we should still be trying at least to break even.

Putting in a local RADIUS server is not a good solution, so if this is not reverted, we will need to stay at RouterOS 6.40.x and under permanently at 15 sites, never being able to upgrade. This makes me a bit nervous, but is preferable to the alternative of having to buy 15 RADIUS servers each of which will be put in remote areas in outdoor shelters with no environmental controls.
Last edited by mducharme on Fri Nov 17, 2017 12:15 pm, edited 1 time in total.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8291
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 12:03 pm

One more solution: if it works good - do not upgrade :)

Worked for me when MikroTik broke VLANs over bonding :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 12:35 pm

I atest to mducharme's complaints. There's no harm reverting the RADIUS timeout value change is there? Could issue a warning of some sort for those who set values in excess of recommended.

Waiting for MT's good news now.
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 9:48 pm

FYI, Cisco docs say the maximum RADIUS timeout on their gear is 1000 seconds. Juniper maximum is 90 seconds. Both seem a bit extreme, but that just shows how far from a 3 second maximum other vendors are.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 10:00 pm

These complaints are exactly why arbitrary hard setting a value is bad when it can be valid within a range. This includes what a developer personally feels is acceptable.
 
User avatar
neg2led
just joined
Posts: 8
Joined: Tue Feb 16, 2016 1:19 pm
Location: Melbourne, Australia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 4:58 am

I think we might be missing the forest for the trees here, guys.

MT say that the reduction here shouldn't make a difference. In this post by strods from page 7, strods says that neither of the routerOS RADIUS client processes will wait more than 3 seconds even if the timeout setting is greater than 3 seconds - important part in bold for emphasis;
RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
Ignoring the part about RADIUS taking more than 3 seconds being unacceptable for the time being, as described by strods, this change should not have resulted in a regression of functionality, as the RADIUS client inside routerOS was not honoring timeouts above 3 seconds to begin with. Based on what mducharme says above, this does not appear to be the case.

He reports that he's seeing different behavior with the timeout hard-set to 3sec, when compared to the 6sec available before. This is a regression in functionality and directly contrary to the information given by MT (strods) - in short, this is a bug. Either MT themselves are incorrect about the behaviour of the client when given timeouts above 3s (and mducharme's 6s timeout on older FW versions was making a difference), or something else has changed that otherwise breaks his admittedly unusual but completely valid configuration.

As mducharme has demonstrated, while unusual, it's not unreasonable for RADIUS to take some seconds to reply, and alternate vendors appear to have max timeouts in the 30-90 second range at the very least. We can argue about arbitrary configuration constraints until we're blue in the face, but it's not relevant to the issue at hand here.

MT: What's your explanation for why mducharme's configuration here works on 6.40 but not on 6.41?
mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.
 
User avatar
blajah
Member Candidate
Member Candidate
Posts: 224
Joined: Fri Jun 12, 2015 8:58 pm
Location: Belgrade, Serbia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 5:39 pm

I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.
Regarding all this with firmware, i have found this in changelog in RC channel:

!) routerboot - RouterBOOT version numbering system merged with RouterOS;
I have bigger routing table.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 10:12 pm

That is why I mention that there is an issue with the RB750 firmware - as this is the release candidate topic and developers are hopefully reading it before doing a release.
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 3:09 am

He reports that he's seeing different behavior with the timeout hard-set to 3sec, when compared to the 6sec available before. This is a regression in functionality and directly contrary to the information given by MT (strods) - in short, this is a bug. Either MT themselves are incorrect about the behaviour of the client when given timeouts above 3s (and mducharme's 6s timeout on older FW versions was making a difference), or something else has changed that otherwise breaks his admittedly unusual but completely valid configuration.
Exactly, my own observations of the behavior of earlier versions do not jibe with what strods claims to be the case. It seems extremely unlikely that it was coincidental that the issue vanished when I made the change, given the circumstances.
mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.
No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite). However I don't need a test to tell me what effect limiting the maximum value will have when we are currently using 6000 ms, and given my previous experiences. We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers. Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

We try to centralize as much as possible and minimize the equipment at the site, less equipment means less that can break - it is cheaper for me to fly to Hawaii than to go to some of our sites. The central RADIUS server is a necessity for us, and it is just not viable to optimize it more than we already have. We have already had to change some FreeRADIUS code to use snmpbulkwalk instead of snmpwalk to avoid needing 25-30 second timeouts, and I do not think we can reduce this any further given our previous efforts to provide QoS to prioritize RADIUS packets.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 11:24 am

No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite).
You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 9:05 pm

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
The dishes are 2.4 or 3.8 meters, so they are big (larger than a home satellite service). It is not easy like putting up an Xplornet dish on a home, these are very big and very heavy, they cannot be roof or wall mounted, unless maybe the roof was concrete and very thick, able to support the weight. So the dish would generally need to be on the ground with a concrete pad for stability and fencing to avoid people standing in front of the beam. Even if we had a place to install such a thing in our downtown urban office building, each dish has its own upload channel, so there would need to be one assigned to a "test dish" but all are in use since actual sites are priority. Therefore to operate a test dish with no channels we would need to shut down one of the 15 sites to free up a channel to bring up a test dish. It would be great to have a test system, it would make certain things easier, but it is just not feasible for all those reasons, so we have lived without it.
satellitepicture.PNG
You do not have the required permissions to view the files attached to this post.
 
msatter
Forum Guru
Forum Guru
Posts: 1166
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 11:54 pm

I see a lot of postings about the Radius timeout and maybe Mikrotik is willing to add an option to choose for extended timeout.

Normal 3 seconds and when the extended timeout option is ticked let's say 90 seconds.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.2.10
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
troffasky
Member
Member
Posts: 394
Joined: Wed Mar 26, 2014 4:37 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 20, 2017 7:18 pm

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Don't need a satellite dish to emulate the behaviour of a typical satellite link:

https://wiki.linuxfoundation.org/networking/netem
 
LynxChaus
just joined
Posts: 24
Joined: Tue Jul 08, 2014 2:24 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 20, 2017 11:10 pm

We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers.
125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?
Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

We try to centralize as much as possible and minimize the equipment at the site, less equipment means less that can break - it is cheaper for me to fly to Hawaii than to go to some of our sites. The central RADIUS server is a necessity for us, and it is just not viable to optimize it more than we already have. We have already had to change some FreeRADIUS code to use snmpbulkwalk instead of snmpwalk to avoid needing 25-30 second timeouts, and I do not think we can reduce this any further given our previous efforts to provide QoS to prioritize RADIUS packets.
You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.
 
mducharme
Trainer
Trainer
Posts: 788
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 21, 2017 1:19 am

125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?
Ping to the site across the satellite link is at least 600ms round trip, so 300ms each way. I have never seen latency drop below that. You are suggesting that round trip latency should be 250 ms or slightly higher, but that is just not realistic.
You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.
That requires extra programming, and won't work in some scenarios. The RADIUS server itself (FreeRADIUS) already has the SNMP check built in to poll the list of interfaces in event that it thinks the customer is already logged in - this did not need to be scripted as it is a built in feature, the RADIUS server does this SNMP check while the NAS is waiting for the 'accept' or 'reject'. What you are describing is an external script that would keep track of the uptime for each router and be able to tell if one went back and just disconnect the sessions for that router. It is certainly possible but such a script would have to be carefully tested. That also wouldn't help with a scenario where the router did not go down but the satellite lost power. A brief power outage would not knock the router offline, so the sysuptime would not go back. Unfortunately this also happens fairly frequently, so a solution that doesn't address this would not help.

A safer way would be to clear sessions if the interim-update interval is exceeded by, say, 4 times, but with an interim update interval of half an hour, customers could be down for up to two hours before the old session would clear.
 
sup5
Member
Member
Posts: 322
Joined: Sat Jul 10, 2010 12:37 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 21, 2017 4:20 am

Another issue with a max. of 3 seconds radius timeout is this:
When the NAS reboots or a bunch of users is handed over from one NAS to another (PPPoE failover scenarios), reauthentication of these users will take ages. So users will complain.

The NAS kicks the users before the radius was able to reply. With enhanced radius timout of like let's say 7 seconds the users are authenticated very quickly.

This 'issue' is caused by a quite loaded Radius and Database server during this peak duration (NAS reboots => several thousand users to aithenticate immediatelly). A radius timout of max. 3 seconds only makes things worse here. The load on the radius increases!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:09 pm

What's new in 6.41rc56 (2017-Nov-24 10:03):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
*) dhcp-client - limit and enforce DHCP client "default-route-distance" minimal value to 1;
*) dhcpv4-server - strip trailing "\0" in "hostname" if present;
*) filesystem - implemented additional system integrity checks on reboots;
*) firewall - added "tls-host" firewall matcher (CLI only);
*) hotspot - fixed "dst-port" to require valid "protocol" in "walled-garden ip";
*) ike2 - fixed PH1 lifetime reset on boot;
*) lte - fixed authentication for non LTE modes;
*) tr069-client - fixed "/interface lte apn" configuration parameters;
*) userman - allow to generate more than 999 users;
*) wireless - added passive scan option for wireless scan mode;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8291
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:14 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 156
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:24 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
+1 :D
Pietro Scherer
http://www.tchesolutions.com.br [ISPs Consulting and Training]
http://www.routermage.com [Backup and Automation System]
:D
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:23 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 880
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:27 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tls
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2278
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:46 pm

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
LAN, FTTx, Wireless. ISP operator
 
troffasky
Member
Member
Posts: 394
Joined: Wed Mar 26, 2014 4:37 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 12:53 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
No need for SNI, CN of certificate is in plaintext whether SNI is used or not.
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 12:59 am

Upgrading a CRS326-24G-2S+ to 6.41rc56 broke DHCP relaying through it, the requests are passed through but the responses (OFFERs) are never seen by the client. Reverting to rc52 fixed this issue.

Don't know exactly what caused this, but if it helps identifying the issue I'm employing VLANs, bonding interfaces, and DHCP relaying. Configs or supout can be available upon request.
 
Paternot
Long time Member
Long time Member
Posts: 578
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 3:28 am

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1810
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 11:47 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tls
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
nkourtzis
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 27, 2017 12:24 pm

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
If this is it, then we only now have to wait for spectral scan and power adjustment in 802.11ac and we will be seeing sweet dreams.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
nkourtzis
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 28, 2017 3:07 pm

Dear all, has the development of ROS slowed down or is it my wrong impresion? One RC sub-version every one to two weeks where it used to be every two to three days and even then, very sparse changelog. Even this thread has become relatively quiet.

Can it possibly be that we approaching the end of v6 development? Just wondering...
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 28, 2017 3:28 pm

nkourtzis wrote:
Can it possibly be that we approaching the end of v6 development? Just wondering...

I am wondering when they dare to release 6.41 as a "current" version with this risky "New bridge implementation" that will likely cause problems once it is widely deployed into many different field configurations (that combine VLAN tagging on switch and bridge now).
You may be right in that this could actually be released as part of "v7" so people are aware there are many changes and testing (rather than routine updating) is required.

Who is online

Users browsing this forum: No registered users and 5 guests