Community discussions

  • 1
  • 3
  • 4
  • 5
  • 6
  • 7
  • 12
 
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!

Tue Sep 19, 2017 5:11 pm

I'll just wait for the stable version.
Weak. Be brave!
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Tue Sep 19, 2017 5:26 pm

I can't, I have over 400 RB with USB LTE MODEM in production and the RC version has STP bridge bugs. While it is not stable I can wait another year :lol:
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
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!

Tue Sep 19, 2017 7:11 pm

Just to be on the safe side. Running CRS317-1G-16+ On the 6.41rc30 looking in switch menu there is no ports and no switch is that correct?
The New implementation is doing "switchy stuff" in bridge section but should I make switch settings in switch section and does that work when Ros doesn't find any chip or ports in this menu.

Where does the Dynamic Vlan of 3501 come from?
This bridge1 port is this the routeros entry point? (ie: if I add Ip adtress or vlan interface in interface section?)
bridge1 doesn't need to be in a vlan for that vlan to forward frames to the member ports?.

Why do I ask this silly questions... because I'm experiencing strange behaviour. And the Wiki is utterly outdated on this developing area and there is no other source for this kind of information.
 
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!

Tue Sep 19, 2017 8:47 pm

Wiki has been updated. The links are in the thread. I think it's under interface bridge.

You are correct. The switch menu is a thing of the past. It is all done via the new HW offload VLAN aware bridge.

This provides a single consistent way to use RouterOS and it manages leveraging underlying hardware dynamically. This is visible by the H flag in interface bridge port.

Now let's go to school. A VLAN is a layer 2 technology like a switch. Therefore a VLAN interface is not required for a bridge to forward a frame. The switch simply has to know which ports are a member of that VLAN and whether it should traffic tagged or untagged on that port.

A VLAN interface is a way to perform routing for traffic on a VLAN in RouterOS.

A VLAN interface should have it's master interface set to the bridge interface.

The bridges VLAN and port tables are where you manage which ports transmit tagged and untagged frames on which ports. A dynamic entry is sourced from an entry in one table that's not present in another. This could be seen by placing a bridge ports PVID in a VLAN not present in the VLAN table. A dynamic entry is created in the VLAN table to express that.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8280
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Wed Sep 20, 2017 9:06 am

By the way, maybe it's possible to add an action (probably to Bridge DST-NAT - it's suitable, according to Packet Flow diagram) to set/unset VLAN tag on the packet (to do kind of MAC-based/protocol-based VLAN)?
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.
 
mszru
just joined
Posts: 14
Joined: Wed Aug 10, 2016 10:42 am

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

Wed Sep 20, 2017 10:44 am

...bridge1 doesn't need to be in a vlan for that vlan to forward frames to the member ports?.
It didn't work for me until I added the bridge1 itself to the tagged ports list.

I have temporarily setup hAP lite (RB941-2nD) as a VLAN aware switch which forwards both untagged and tagged (vlan=100) frames. I didn't do anything in the "Switch" menu. The configuration was done in the "Bridge" menu only:
1) Added ether1, ether2, ether3 and ether4 as member ports for bridge1 in "Bridge" -> "Ports" and for each member port I set pvid=1 and frame-types=admit-all
interface bridge port 
add interface=ether1 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether2 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether3 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether4 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
2) In the "Bridge" -> "VLANs" made all members ports aware of vlan 100 tagged frames (including bridge1 itself).
interface bridge vlan add bridge=bridge1 vlan-ids=100 tagged=bridge1,ether1,ether2,ether3,ether4 untagged=""
3) Enabled VLAN Filtering for bridge1 in the "Bridge" -> "Bridge" menu.
interface bridge set bridge1 vlan-filtering=yes pvid=1
4) [optional] Added vlan100 interface to the bridge1 to be able to manage the router from that VLAN.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Sep 20, 2017 4:42 pm

What's new in 6.41rc31 (2017-Sep-20 06:56):

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:

*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C with additional "/port" for GPS usage;
*) lte - automatically add "/ip dhcp-client" configuration on interface;
*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
*) ppp - fixed serial port loading (introduced in v6.41rc);
*) sfp - fixed temperature readings for various SFP modules;
*) snmp - fixed "/system license" parameters for CHR;
*) wireless - improved reliability on "rx-rate" selection process;

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.
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

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

Thu Sep 21, 2017 12:27 am

What's new in 6.41rc31 (2017-Sep-20 06:56):

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:

*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C with additional "/port" for GPS usage;
*) lte - automatically add "/ip dhcp-client" configuration on interface;
*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
*) ppp - fixed serial port loading (introduced in v6.41rc);
*) sfp - fixed temperature readings for various SFP modules;
*) snmp - fixed "/system license" parameters for CHR;
*) wireless - improved reliability on "rx-rate" selection process;

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.
strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.

I know I'm not the only one very eager for it.
 
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!

Thu Sep 21, 2017 12:58 am


strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.

I know I'm not the only one very eager for it.
one thing that i've never understood about mikrotik is why they add new features to RC.there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)

this would make far more sense
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

Thu Sep 21, 2017 2:24 am

One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.
 
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!

Thu Sep 21, 2017 6:53 am

One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.

Mmmmm hacker bait. :)
 
andriys
Forum Guru
Forum Guru
Posts: 1079
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Thu Sep 21, 2017 9:52 am

there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
This is just a naming convention, you just have to get used to it.

In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
 
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!

Thu Sep 21, 2017 10:37 am

there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
This is just a naming convention, you just have to get used to it.

In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable". why do you think cheeze asked if its down to polishing and bugfixes? its because rc naming convention makes it confusing for some users. no one would have to question if rc actually meant rc, alpha meant alpha, beta meant beta, and then we won't be having this discussion.

and thanks to polluted nonsense or not, we finally received MSTP after so many years, have you forgotten, mr forum police?
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Thu Sep 21, 2017 10:47 am

Just updated a CRS125 test unit to 6.41rc31 (from 6.40.3); firmware upgrade and master-port-TO-new-bridge config auto-conversion went smoothly.
NOTE: CRS125 config has custom MAC addresses set for all interfaces and this has not compromised upgrade/conversion, on CRS326 instead custom MAC addresses can be set but IMHO the device hang at first reboot (pay attention).
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 23998
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

Thu Sep 21, 2017 10:59 am

to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable"
We are aware of this, but in RouterOS world, "stable" is the only version you should use in important locations where you don't want new features. We update this branch rarely and only after long and rigorous testing. Current is more like RC (current = running release), and RC is more like Beta or "nightly build" in Windows land.
No answer to your question? How to write posts
 
willglynn
just joined
Posts: 2
Joined: Mon May 01, 2017 4:18 pm

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

Fri Sep 22, 2017 4:37 am

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
 
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 Sep 22, 2017 12:36 pm

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
Not as faar as I can se for the moment..
And while we speak of it would it be Possible to add this to the new implementation and possibly enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Sep 22, 2017 2:24 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

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 development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
*) console - do not stop "/certificate sign" process if console times out in 1 minute;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) traceroute - improved "/tool traceroute" results processing;
*) wireless - log "signal-strength" when successfully connected to AP;

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.
 
dschn
newbie
Posts: 25
Joined: Wed Nov 16, 2016 2:22 pm

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

Fri Sep 22, 2017 5:10 pm

With v6.41rc31 my LTE connection was very slow, max. 7-10mbit/s and high pings >200ms. Also the E3372 LTE modem (still) loses connection when downloading larger amounts of data (via Steam for example) so you have to reboot the RB.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3423
Joined: Mon May 31, 2004 2:55 pm

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

Fri Sep 22, 2017 5:12 pm

With v6.41rc31 my LTE connection was very slow, max. 7-10mbit/s and high pings >200ms. Also the E3372 LTE modem (still) loses connection when downloading larger amounts of data (via Steam for example) so you have to reboot the RB.
What version you had before on your router where it was working ok?
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

Fri Sep 22, 2017 5:52 pm


The previous switch settings supported MAC learning limits:
/interface ethernet switch port set ether6 learn-limit=1
Is this feature still available with the new bridge implementation?
While we are speaking about this, could we enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer?
Yes, please. Cisco calls a learned MAC on reboot sticky (I think). Replace after a timeout is good too.
 
w0lt
Member
Member
Posts: 480
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

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

Fri Sep 22, 2017 6:30 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
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 Sep 22, 2017 10:17 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.
 
w0lt
Member
Member
Posts: 480
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

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

Sat Sep 23, 2017 2:44 am

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.
Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping . :D

-tp
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2274
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

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

Sat Sep 23, 2017 12:32 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?
LAN, FTTx, Wireless. ISP operator
 
Paternot
Long time Member
Long time Member
Posts: 573
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

Sat Sep 23, 2017 3:40 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?
Excelent idea!
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

Sat Sep 23, 2017 4:48 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. Would it be possible to add the last signal when the state was disconnected?
That might be extremely useful, if the data correlates to client's disconnecting around full power. We could point blame at something other than coverage.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8280
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Mon Sep 25, 2017 10:47 am

Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping . :D
interface bridge set bla-bla igmp-snooping=yes
:)
This entry in changelog just means that there were some improvements in already implemented snooping.
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.
 
dschn
newbie
Posts: 25
Joined: Wed Nov 16, 2016 2:22 pm

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

Mon Sep 25, 2017 11:24 am

What version you had before on your router where it was working ok?
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...
 
uldis
MikroTik Support
MikroTik Support
Posts: 3423
Joined: Mon May 31, 2004 2:55 pm

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

Mon Sep 25, 2017 12:06 pm

What version you had before on your router where it was working ok?
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...
Please contact support@mikrotik.com for more information (include the modem number and revision). Also check what lte band it uses when you have normal speed and when you have slow speed.
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Wed Jan 09, 2013 8:26 am

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

Mon Sep 25, 2017 2:11 pm

have you planned add HW offload with vlan-filtering function?
 
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!

Mon Sep 25, 2017 6:17 pm

have you planned add HW offload with vlan-filtering function?
careful now, forum police andyris might warn you to post in feature request thread.
 
User avatar
eworm
Member
Member
Posts: 339
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Mon Sep 25, 2017 6:20 pm

I am having issues with CAPsMAN on 6.41rc13... Looks like cap interfaces with CAPsMAN forwarding do not pass any traffic.
The issue persists with 6.41rc16... Just downgraded to 6.41rc11 and wireless is up and running.
Updated to 6.41rc32 and everything works as expected. I can not tell what intermediate version fixed the issue though.
Thanks Uldis!
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Wed Jan 09, 2013 8:26 am

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

Mon Sep 25, 2017 7:11 pm

have you planned add HW offload with vlan-filtering function?
careful now, forum police andyris might warn you to post in feature request thread.
this is not a feature request, it's a question
will return the functionality that was lost in the new version.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4048
Joined: Wed May 11, 2011 6:08 pm

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

Wed Sep 27, 2017 12:23 am

I just put 6.41rc32 onto an RB2011UAS-2HnD and have a question.

The pre-upgrade configuration was with a bridge name=LAN with ports=ether2 and ether6, with those set as masters in the switch menu to ports ether3-5 and ether7-9 respectively.
ether1, ether10, and sfp1 were all stand-alone interfaces.

Long story short: after the upgrade, the bridge ports menu still only lists ether2 and ether6 as ports of the LAN bridge, but I am still able to reach the router from ether3 as if it were a member of the bridge. The bridge > hosts displays my laptop's MAC address on ether3 (correctly) but I can't see anything that would tell me ether3 should be bridged with ether2.

Am I missing something obvious that would show me ether3 as a member of the LAN bridge? (or as a member of some other hardware-accelerated bridge?)
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

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

Wed Sep 27, 2017 3:54 am

I just put 6.41rc32 onto an RB2011UAS-2HnD and have a question.
I had a similar issue with a 951G. First boot with upgrade, was still able to connect from port 5. Rebooted one more time and lost connection until I switched to port 2.

Maybe the initial config needs one more reboot or switch reset to behave as expected.
 
rapidsky
just joined
Posts: 2
Joined: Wed Sep 20, 2017 9:33 am

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

Wed Sep 27, 2017 7:55 am

On the CRS326 running 6.41rc32 and firmware 3.41, adding some ports to bridge2 disables their hardware offload. This is Is this expected?
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                BRIDGE                               HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0   H ether1                                   bridge1                              yes    1     0x80         10                 10       none
 1 I H ether2                                   bridge1                              yes    1     0x80         10                 10       none
 2 I H ether3                                   bridge1                              yes    1     0x80         10                 10       none
 3 I H ether4                                   bridge1                              yes    1     0x80         10                 10       none
 4 I H ether5                                   bridge1                              yes    1     0x80         10                 10       none
 5 I H ether6                                   bridge1                              yes    1     0x80         10                 10       none
 6 I H ether7                                   bridge1                              yes    1     0x80         10                 10       none
 7 I H ether8                                   bridge1                              yes    1     0x80         10                 10       none
 8 I H ether9                                   bridge1                              yes    1     0x80         10                 10       none
 9 I H ether10                                  bridge1                              yes    1     0x80         10                 10       none
10 I H ether11                                  bridge1                              yes    1     0x80         10                 10       none
11 I H ether12                                  bridge1                              yes    1     0x80         10                 10       none
12 I H ether13                                  bridge1                              yes    1     0x80         10                 10       none
13 I H ether14                                  bridge1                              yes    1     0x80         10                 10       none
14 I H ether15                                  bridge1                              yes    1     0x80         10                 10       none
15 I H ether16                                  bridge1                              yes    1     0x80         10                 10       none
16 I H sfp-sfpplus1                             bridge1                              yes    1     0x80         10                 10       none
17 I   ether17                                  bridge2                              yes    1     0x80         10                 10       none
18 I   ether18                                  bridge2                              yes    1     0x80         10                 10       none
19 I   ether19                                  bridge2                              yes    1     0x80         10                 10       none
20 I   ether20                                  bridge2                              yes    1     0x80         10                 10       none
21 I   ether21                                  bridge2                              yes    1     0x80         10                 10       none
22 I   ether22                                  bridge2                              yes    1     0x80         10                 10       none
23 I   ether23                                  bridge2                              yes    1     0x80         10                 10       none
24 I   ether24                                  bridge2                              yes    1     0x80         10                 10       none
25 I   sfp-sfpplus2                             bridge2                              yes    1     0x80         10                 10       none
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1142
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Wed Sep 27, 2017 9:03 am

Not sure if this is related to RC build or its a general problem for MikroTik

I have a RB941-2nD for testing. Upgraded to latest RC and its running fine.
Then I see that there are new firmware available. So I click the upgrade button.
RB tells me "Do you really want to upgrade the firmware?"
I click yes, and nothing more happens.
Firmware is still the same, no changes anywhere.
So I did go to Terminal and did try the same.
There I got this message: 07:56:59 echo: system,info,critical Firmware upgraded successfully, please reboot for changes to take effect!
Ahh, Its need a reboot!!

1. Remove the really, its telling me "are you really so stupid that you like to upgrade?", change to "Do you want to upgrade firmware"
2. Add information that reboot is needed after the web upgrade.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
User avatar
floeff
newbie
Posts: 36
Joined: Sat Jan 28, 2017 6:39 pm
Location: Germany
Contact:

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

Wed Sep 27, 2017 11:40 am

I might have hit a bug wrt. the bridge conversion.
hAP lite, RouterBOOT 3.41, RouterOS 6.40.
Device completely resetted, export only showed configuration of ether interfaces, nothing else (as intended).
ether1 not configured further, ether2 not configured further. ether3-4 configured with ether2 as master port.
My understanding is that the update to 6.41rc should create a HW offload bridge with ether2-5 in
It did create the bridge with a comment that this was created due to the upgrade, but that bridge contained no port at all.
Trivial to fix, but IMHO not as expected?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Sep 27, 2017 2:33 pm

What's new in 6.41rc34 (2017-Sep-27 10:05):

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:

*) crs3xx - improved packet processing in slowpath;
*) defconf - fixed RouterOS default configuration (introduced in v6.40.3);
*) ethernet - removed "master-port" parameter;
*) log - fixed "unknown" interface name in log messages;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - do not reset modem when it is not possible to access SMS storage;
*) snmp - fixed "ifHighSpeed" value of VLAN, VRRP and Bonding interfaces;
*) snmp - fixed "/caps-man registration-table" uptime values;
*) tile - improved hardware encryption processes;
*) vlan - do not allow VLAN MTU to be higher than L2MTU;
*) wireless - fixed rate selection process when "rate-set=configured" and NV2 protocol is used;

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
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Wed Sep 27, 2017 8:14 pm

Board: CRS326-24G-2S+
Previous ROS: 6.41rc32
Status: quite stable, all port in bridge w/ RSTP enabled and 2 active link to CRS125 (active/alternate)

Upgraded to 6.41rc34, every 3-5 minutes my laptop (direct patch cord to a CRS326 port) detects lost link; on a separate windows I've constant ping to my firewall and I can see ping fail (General Error = link down / no laptop eth conn). After some seconds link is back and ping go normal.

On 6.41rc32 (tested in the last 3 days) I've not seen any similar behaviour (and I've made no topology changes).
Now I've disabled RSTP (and removed redundant link to CRS125) and it'seems to be stable again (consider it's only 30 minutes now I'm testing this).

Even if these are lab equipments, I'm considering going back to 6.40.3 and stay there for some weeks ..probably this switch_2_bridge conversion is something which needs time to consolidate.
Some days ago I've netinstalled 2 time the CRS326 because it doesn't like MAC changes.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Thu Sep 28, 2017 1:03 am

(see previous post) Confirmed.. after some hours, disablig RSTP it's now stable.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Thu Sep 28, 2017 3:12 am

I've noticed one more thing (CRS326 - 6.41rc34 - RSTP now enabled):
>> keeping winbox logged to CRS326 the problem does not show up
>> closing winbox .. flapping starts
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

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

Sat Sep 30, 2017 10:07 am

Hw. Offload
After reboot I have this in log...

hardware offloading activated on bridge "bridge1" ports: wlan1,ether2
hardware offloading activated on bridge "bridge1" ports: wlan1,ether3

But port wlan1 status is inactive and not Hw. Offload... Is is correct?

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none 
2 H ether3 bridge1 yes 1 0x80 10 10 none 
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none 
 
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!

Sat Sep 30, 2017 8:33 pm

Hw. Offload
After reboot I have this in log...

hardware offloading activated on bridge "bridge1" ports: wlan1,ether2
hardware offloading activated on bridge "bridge1" ports: wlan1,ether3

But port wlan1 status is inactive and not Hw. Offload... Is is correct?

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none 
2 H ether3 bridge1 yes 1 0x80 10 10 none 
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none 
Not stating your board but from what I can tell wlan1 is a wlan interface right? this interface maybe is not connected in hardware to the same switch chip. Hence it's not hardware enabled. Look att the Block diagrams of your unit an you will se how it's built.
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

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

Sat Sep 30, 2017 9:09 pm

I think You are right (RB951Ui-2HnD), but I don't understand the log message including wlan1 port...
 
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!

Sat Sep 30, 2017 10:53 pm

MikroTik can correct me on Monday but that's probably referring to the bridge level hardware offload feature or the port hw=yes setting. You can set it to yes regardless of it being a wlan or Ethernet interface.
 
teleweb
just joined
Posts: 2
Joined: Fri Jul 15, 2016 5:11 am

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

Mon Oct 02, 2017 3:56 am

Hi, we have a question about the new bridge / hw offloading implementation in CRS 317-1G-16S+

I have created 2 bridges: most ports added to bridge1, two ports added to bridge2.
Now I only see the H (or "Hw offload" checked) with the ports of bridge1.
Can you only have one bridge making use of hw offloading?
We have enabled "Fast forward" at the bridge level, and "Hardware offload" at the port level.

Thanks!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Oct 02, 2017 11:23 am

What's new in 6.41rc37 (2017-Oct-02 06:47):

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 development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - initial support for "/interface list" as a bridge port (CLI only);
*) fetch - accept all HTTP 2xx status codes;
*) ike2 - fixed initiator DDoS cookie processing;
*) ike2 - fixed responder DDoS cookie first notify type check;
*) lte - fixed modem initialization after reboot;
*) ntp-client - properly start NTP client after reboot if manual server IP is not configured;
*) sfp - fixed OPTON module DDM information readings;
*) wireless - added "etsi1" regulatory domain information;
*) wireless - improved WPA2 key exchange reliability;
*) wireless - updated "norway" regulatory domain information;

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
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Oct 02, 2017 2:11 pm

Upgraded CRS326-24G-2S+ to 6.41rc37 , after reboot in the log I've noticed all ports have been removed from bridge hw-offloading and re-inserted.
I've also noticed Firmware 3.43 was available for CRS326-24G-2S+ and I've upgraded it also and rebooted.

Now I've enabled RSTP again and I'm going to re-insert the redundant patch cord to CRS125 ..and see what happen now
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7
  • 12

Who is online

Users browsing this forum: No registered users and 2 guests