Community discussions

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

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

Wed Jul 26, 2017 2:36 pm

What's new in 6.41rc3 (2017-Jul-26 09:32):

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.

!) bridge - implemented software based vlan-aware bridges;
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (CLI only);
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) CRS3xx - switch VLAN configuration integrated within bridge VLAN configuration with hw-offload;
*) arp - fixed invalid static ARP entries after reboot on interfaces without IP address;
*) bonding - improved relialibility on bonding interface removal;
*) bridge - fixed ARP setting (introduced in v6.40rc36);
*) bridge - fixed multicast forwarding (introduced in v6.40rc36);
*) bridge - implemented dynamic entries for active MST port overrides;
*) bridge - implemented software based "igmp-snooping" (CLI only);
*) bridge - implemented software based MSTP (CLI only);
*) bridge - removed "frame-types" and "ingress-filtering" for bridge interfaces (introduced in v6.40rc36);
*) certificate - show "Expired" flag when initial CRL fetch fails;
*) e-mail - do not show errors when sending e-mail from script;
*) firewall - properly remove "address-list" entry after timeout ends;
*) hotspot - improved user statistics collection process;
*) interface - improved interface state change handling when multiple interfaces are affected at the same time;
*) ippool6 - try to assign desired prefix for client if prefix is not being already used;
*) lte - allow to specify the MAC address for passthrough mode;
*) ppp - added client support for Sierra MC7750;
*) rb2011 - fixed possible LCD blinking along with Ethernet LED;
*) rb922 - restored missing wireless interface on some boards;
*) sftp - added functionality which imports ".auto.rsc" file or reboots router on ".auto.npk" upload;
*) trafficgen - fixed "lost-ratio" showing incorrect statistics after multiple sequences;

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.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Wed Jul 26, 2017 2:52 pm

Hello everyone
I'm confused on the crs 125 series what is the best way,
Use the new vlan on bridge or stay using the switch menu?
Thanks.

Enviado de meu XT1580 usando Tapatalk
 
49er
Member
Member
Posts: 409
Joined: Tue Sep 27, 2011 7:55 am

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

Wed Jul 26, 2017 3:19 pm

raffav,

I Understand you.
I have the same.
VLAN on Mikrotik is very confussing
 
raymondr15
Member Candidate
Member Candidate
Posts: 119
Joined: Fri Sep 05, 2014 1:11 am
Location: East London, South Africa
Contact:

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

Wed Jul 26, 2017 4:38 pm

Hi,

I am sitting in my office at work and have just update my RB2011UiAS-RM remotely, after rebooting the router am not able to access my router from the WAN side, my internet service provider is a WISP so I logged into my CPE and tried to SSH my router, I am able to login to the router but as soon as I login, the router stops responding for a few minutes and then comes back, same thing keeps happening when trying to SSH to the router. Will have to check the router when I get home.

Folks, don't upgrade your router if it is on a remote location 8)
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Jul 26, 2017 7:44 pm

New bridge is back!!!!!!! Super excited to test IPv6 pool prefix hinting assignments too. Might not be until next week though.
 
User avatar
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

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

Thu Jul 27, 2017 1:09 am

RB2011UAS v6.41rc3
Bridge hardware offload is fine. :D
IPv6 address assignment is broken :-( State is 'invalid'

/ipv6 address
add address=::1/64 from-pool=netdsl-ipv6 interface=bridge-local advertise=yes
[admin@migo] /ipv6 address> print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-POOL INTERFACE                                                                                                    ADVERTISE
 0 IG ::1/64                                      netdsl... bridge-local                                                                                                 yes      
 1 DL fe80::d6ca:6dff:fea0:ff93/64                          bridge-local                                                                                                 no       
 2 DL fe80::d/64                                            pppoe-out1                                                                                                   no       
 3 DL fe80::d6ca:6dff:fea0:ff92/64                          ether1-gateway                                                                                               no       
DHCPv6 prefix delegation from ISP is OK.
[admin@migo] /ipv6> dhcp-client print
Flags: D - dynamic, X - disabled, I - invalid 
 #    INTERFACE         STATUS        REQUEST        PREFIX                                                           ADDRESS                                                     
 0    pppoe-out1        bound         prefix         2001:4dd2:8c78::/48, 1d1h47m23s                                 
Supout file was sent.
Last edited by boldsuck on Sun Jul 30, 2017 12:45 am, edited 1 time in total.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Jul 27, 2017 1:53 am

Hello everyone
I'm confused on the crs 125 series what is the best way,
Use the new vlan on bridge or stay using the switch menu?
Thanks.

Enviado de meu XT1580 usando Tapatalk
My understanding from the 6.40rc36 and 38 releases was that the switch chip menu was to not be used for ports not in a new bridge and ideally all configurations should move to the new VLAN aware hw-offload bridges.

I do recall a conflicting post from a MikroTik poster so clarification from own of the MikroTik folks would be great.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Thu Jul 27, 2017 2:04 am

Hello everyone
I'm confused on the crs 125 series what is the best way,
Use the new vlan on bridge or stay using the switch menu?
Thanks.

Enviado de meu XT1580 usando Tapatalk
My understanding from the 6.40rc36 and 38 releases was that the switch chip menu was to not be used for ports not in a new bridge and ideally all configurations should move to the new VLAN aware hw-offload bridges.

I do recall a conflicting post from a MikroTik poster so clarification from own of the MikroTik folks would be great.
I asked this because on here on wiki


https://wiki.mikrotik.com/wiki/Manual%3 ... Offloading

If you see the table of crs 1xx/2xx series
It have a - on bridge vlan filter



Enviado de meu XT1580 usando Tapatalk
 
romihg
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

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

Thu Jul 27, 2017 3:43 am

Upgrade from 6.40 last rc to 6.41.3 my 2011UiAS-2HnD all leds on active interfaces are off, Except led on eth10 is on witch is POE Out and is active. Is this normal or something wrong with this.
 
romihg
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

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

Thu Jul 27, 2017 4:05 am

Upgrade from 6.40 last rc to 6.41.3 my 2011UiAS-2HnD all leds on active interfaces are off, Except led on eth10 is on witch is POE Out and is active. Is this normal or something wrong with this.
Leds work on boot. But after router come in working state they switch off.
 
proximus
Member Candidate
Member Candidate
Posts: 121
Joined: Tue Oct 04, 2011 1:46 pm

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

Thu Jul 27, 2017 4:43 am

Upgrade from 6.40 last rc to 6.41.3 my 2011UiAS-2HnD all leds on active interfaces are off,
Same here, LED's are dead (RB2011UiAS).
 
becs
MikroTik Support
MikroTik Support
Posts: 501
Joined: Thu Jul 07, 2011 8:26 am

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

Thu Jul 27, 2017 9:18 am

Hello, we are aware that Ethernet LEDs do not work on RouterBoards with AR8327/QCA8337 switch chips in v6.41rc3 and look forward to fix it soon.
 
becs
MikroTik Support
MikroTik Support
Posts: 501
Joined: Thu Jul 07, 2011 8:26 am

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

Thu Jul 27, 2017 9:31 am

My understanding from the 6.40rc36 and 38 releases was that the switch chip menu was to not be used for ports not in a new bridge and ideally all configurations should move to the new VLAN aware hw-offload bridges.
Currently, it is implemented only for CRS3xx series switches.
If you see the table of crs 1xx/2xx series
It have a - on bridge vlan filter
On CRS125 VLANs still have to be configured in "/interface ethernet switch" menu to keep hw-offload working. If they are configured in "/interface bridge vlan", the hw-offload will turn off.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Jul 27, 2017 12:12 pm

My understanding from the 6.40rc36 and 38 releases was that the switch chip menu was to not be used for ports not in a new bridge and ideally all configurations should move to the new VLAN aware hw-offload bridges.
Currently, it is implemented only for CRS3xx series switches.
If you see the table of crs 1xx/2xx series
It have a - on bridge vlan filter
On CRS125 VLANs still have to be configured in "/interface ethernet switch" menu to keep hw-offload working. If they are configured in "/interface bridge vlan", the hw-offload will turn off.
Becs, thanks for the clarification! While we're chatting. How do we mere mortals edit the wiki?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26912
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

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

Thu Jul 27, 2017 1:02 pm

Only staff can edit the wiki
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1092
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Fri Jul 28, 2017 12:06 pm

Successfully updated a CRS109-8G-1S-2HnD. Looks great, can't wait for this to be released in current! :D
!) bridge - implemented software based vlan-aware bridges;
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
Before changing my configuration... Does MAC-based-VLAN work with this implementation?
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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

Fri Jul 28, 2017 5:52 pm

The VLAN does not work on the Atheros 8327 chip switch.
I create Bridge1 and add Ethernet1 and Ethernet2.
I'm creating VLAN20 on Bridge1 - there's still ok.
But when I add VLAN20 to Bridge2, RB is unavailable on these two ports.

Sorry about my English.
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

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

Fri Jul 28, 2017 6:53 pm

Shouldn't VLAN be created on Ethernet port, not the bridge ...
Or you are trying Bridge VLAN Filtering and vlan-ids ...
I'm creating VLAN20 on Bridge1 - there's still ok.
But when I add VLAN20 to Bridge2, RB is unavailable on these two ports.
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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

Fri Jul 28, 2017 8:54 pm

Shouldn't VLAN be created on Ethernet port, not the bridge ...
Or you are trying Bridge VLAN Filtering and vlan-ids ...
I'm creating VLAN20 on Bridge1 - there's still ok.
But when I add VLAN20 to Bridge2, RB is unavailable on these two ports.
It does not work even if I put my vlan on ether1 or 2.
I want to get the old way tagged vlan20 on ports ether1,2,3 ... n (before master port1 and slave ether2,3, ... n)
Bridge strip Taging. I have DHCP server for vlan20.

It works great on chip switch Atheros 8227.
Simplified Example:
/interface bridge
add name=bridge1
add name=bridge2
add name=bridge3
/interface vlan
add interface=bridge1 name=vlan20 vlan-id=20
add interface=bridge1 name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=vlan20
add bridge=bridge3 interface=vlan30
 
JanezFord
Member Candidate
Member Candidate
Posts: 270
Joined: Wed May 23, 2012 10:58 am

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

Fri Jul 28, 2017 10:55 pm

If you see the table of crs 1xx/2xx series
It have a - on bridge vlan filter
On CRS125 VLANs still have to be configured in "/interface ethernet switch" menu to keep hw-offload working. If they are configured in "/interface bridge vlan", the hw-offload will turn off.
Will there be shift to new syntax also for CRS125 series? It is a bit confusing to have to use different syntax for each product to get things done ...

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

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

Sat Jul 29, 2017 2:55 am

If you see the table of crs 1xx/2xx series
It have a - on bridge vlan filter
On CRS125 VLANs still have to be configured in "/interface ethernet switch" menu to keep hw-offload working. If they are configured in "/interface bridge vlan", the hw-offload will turn off.
Will there be shift to new syntax also for CRS125 series? It is a bit confusing to have to use different syntax for each product to get things done ...

JF.
+1, one would hope it continues to move towards a singular syntax for VLAN configuration and let MikroTik ninja's translate that as needed in middleware into any fidgety model specific configuration options.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Sat Jul 29, 2017 5:33 am

+1
Agree, need to be more simple, no offense but the Cisco way it very simple
Switch port mode trunk/access
Switch port access vlan x
Switch port trunk allow vlan x,y,z



Enviado do meu iPad usando Tapatalk
 
Safic
just joined
Posts: 4
Joined: Sun Jun 19, 2016 10:26 am

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

Sat Jul 29, 2017 8:32 am

Shouldn't VLAN be created on Ethernet port, not the bridge ...
Or you are trying Bridge VLAN Filtering and vlan-ids ...
I'm creating VLAN20 on Bridge1 - there's still ok.
But when I add VLAN20 to Bridge2, RB is unavailable on these two ports.
It does not work even if I put my vlan on ether1 or 2.
I want to get the old way tagged vlan20 on ports ether1,2,3 ... n (before master port1 and slave ether2,3, ... n)
Bridge strip Taging. I have DHCP server for vlan20.
Grickos, just put your vlan interfaces at bridge1 and add bridge1 to tagged ports in
/interface bridge vlan
Last edited by Safic on Sat Jul 29, 2017 9:49 am, edited 1 time in total.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3343
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Sat Jul 29, 2017 9:43 am

+1
Agree, need to be more simple, no offense but the Cisco way it very simple
Switch port mode trunk/access
Switch port access vlan x
Switch port trunk allow vlan x,y,z
+1

I have worked with HP: very simple vlan setup, Cisco: simple VLAN and others
On Mikrotik I have still not used VLAN, since I have problem to understand how it works.
Its way to complicated.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Sat Jul 29, 2017 1:21 pm

Vlan is Hard to understand IF you used HP as they use the term tag/untagged (Their Ports are all hybrid and can't be trunk or access from the cisco perpspective.)

AccessPort = A port that is only accepting untaged frames on ingress and only output untaged frames on egress. All other frametypes is silently droped
TrunkPort = A port that only accepts tagged frames, all untaged frames is silently droped. it only egress taged frames.

Other have then invented shortcuts of that:

Hybrid = A port that accept both taged and untaged frames on ingress, untaged frames are assumed to belong to a native vlan. the same vlan can even recieve frames taged as beloning to it. Egres a hybrid port outputs as a trunk on all vlans and as an access port on the native vlan.

HP's implementation of only hybrid have stirred quit a few it guys in the field. The cisco way is cleaner and less error prone.

This is a Mikrotik forum and I who claims to understand .1q or qinq or qinqinqinq for one loves the freedom in mikrotik bridge being software layer, switch being hardware layer or at least I assume. Here i'm am currently not sure due to 6.41rc work.... but that will clear when it's done.
 
User avatar
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

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

Sat Jul 29, 2017 1:32 pm

- ipv6 - fixed IPv6 address request from pool (introduced in 6.41rc1);
RB2011UAS v6.41rc1 - rc20
IPv6 address assignment is broken :-( State is 'invalid'
Just for INFO:
MikroTik have managed to reproduce the problem. The error only occurs with me and a few others. MikroTik are working on it. But I fear this will remain an eternal bug.
:wink: I can live with the router not to reboot.

Since 6.41rc13 the DHCPv6 client has no more prefix. The IPv6 address could therefore not be assigned manually. Since 6.41rc20 gets the DHCPv6 client again a prefix which I then manually assigned.

I can not test the feature with the dynamic subprefix.
- Ippool6 - try to assign the requested prefix for client if prefix is not being already used;

Edit:
Damn, I'm stupid! I wanted to answer, do not edit. The forum is unfortunately not in the wayback machine so I can reverse that again. Sorry.
Last edited by boldsuck on Wed Aug 30, 2017 1:28 pm, edited 2 times in total.
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

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

Sat Jul 29, 2017 2:13 pm

It does not work even if I put my vlan on ether1 or 2.
It should be like this ... (if your vlans 20 and 30 are on ether2):
/interface bridge
add name=bridge1
add name=bridge2
add name=bridge3
/interface vlan
add interface=ether2 name=vlan20 vlan-id=20
add interface=ether2 name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether3
add bridge=bridge2 interface=vlan20
add bridge=bridge3 interface=vlan30
Check https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN ...
 
Eduardo
newbie
Posts: 45
Joined: Thu Aug 18, 2016 12:20 pm

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

Sat Jul 29, 2017 5:52 pm

On CRS125 VLANs still have to be configured in "/interface ethernet switch" menu to keep hw-offload working. If they are configured in "/interface bridge vlan", the hw-offload will turn off.
Beginners question: I am not using VLANs on CRS125, but was using masterport. Can I still use this masterport functionality? Or I need to go via VLANs now, to get hardware switching?!

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

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

Sun Jul 30, 2017 6:05 am

Vlan is Hard to understand IF you used HP as they use the term tag/untagged (Their Ports are all hybrid and can't be trunk or access from the cisco perpspective.)

AccessPort = A port that is only accepting untaged frames on ingress and only output untaged frames on egress. All other frametypes is silently droped
TrunkPort = A port that only accepts tagged frames, all untaged frames is silently droped. it only egress taged frames.

Other have then invented shortcuts of that:

Hybrid = A port that accept both taged and untaged frames on ingress, untaged frames are assumed to belong to a native vlan. the same vlan can even recieve frames taged as beloning to it. Egres a hybrid port outputs as a trunk on all vlans and as an access port on the native vlan.

HP's implementation of only hybrid have stirred quit a few it guys in the field. The cisco way is cleaner and less error prone.

This is a Mikrotik forum and I who claims to understand .1q or qinq or qinqinqinq for one loves the freedom in mikrotik bridge being software layer, switch being hardware layer or at least I assume. Here i'm am currently not sure due to 6.41rc work.... but that will clear when it's done.
JimmyNyholm, a Cisco trunk port will pass both tagged or untagged traffic depending on the allowed VLAN list assigned to the trunk port (by default all VLANs are allowed). This is the "hybrid" behavior you're describing. Leaving the native VLAN routable on trunks is what exposes people to double tagging VLAN hop methods for what it's worth.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Sun Jul 30, 2017 6:07 am

The VLAN does not work on the Atheros 8327 chip switch.
I create Bridge1 and add Ethernet1 and Ethernet2.
I'm creating VLAN20 on Bridge1 - there's still ok.
But when I add VLAN20 to Bridge2, RB is unavailable on these two ports.

Sorry about my English.
Grickos, I've not used VLANs in that fashion in any configurations. Looking at the new bridges I have been creating a single bridge and I add the interfaces as bridge ports. I also add all VLANs to this central bridge and adjust ports for tagged or an untagged VLAN as needed. I wouldn't expect two bridges to share information regarding the same VLAN without another bridge to glue them together.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Sun Jul 30, 2017 8:22 am

Running the command:
/export
Hardware I tested against:
  • RouterBOARD 750G r3
  • RouterBOARD wAP G-5HacT2HnD
  • RouterBOARD cAP L-2nD
The result I see in the print-out:
#error exporting /system routerboard mode-button
I'm pretty sure it's benign but just thought I'd post it.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Sun Jul 30, 2017 6:58 pm

JimmyNyholm, a Cisco trunk port will pass both tagged or untagged traffic depending on the allowed VLAN list assigned to the trunk port (by default all VLANs are allowed). This is the "hybrid" behavior you're describing. Leaving the native VLAN routable on trunks is what exposes people to double tagging VLAN hop methods for what it's worth.
Idlemind: you are right when talking to later 802.1q adaptations from cisco side. switchport mode trunk will still only accept taged frames on ingress (leaning back from the isl days before 802.q was ratified). You have to tell it to process untagged frames as well and that command is only available after certain version of the ios. We do agree upon that this will make even ciscos implementation leaning to hybrid.
My writing was to open up peoples mind to the idea of what is happening ingress and egress of a switchport, and to set some acronyms. To many techs think vlan is difficult when it's actually not just with the right mindset.

never connect vlan 0 from different vendors, never use spanning tree. Allways know what you are doing. ;-)
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Sun Jul 30, 2017 8:47 pm

JimmyNyholm, a Cisco trunk port will pass both tagged or untagged traffic depending on the allowed VLAN list assigned to the trunk port (by default all VLANs are allowed). This is the "hybrid" behavior you're describing. Leaving the native VLAN routable on trunks is what exposes people to double tagging VLAN hop methods for what it's worth.
Idlemind: you are right when talking to later 802.1q adaptations from cisco side. switchport mode trunk will still only accept taged frames on ingress (leaning back from the isl days before 802.q was ratified). You have to tell it to process untagged frames as well and that command is only available after certain version of the ios. We do agree upon that this will make even ciscos implementation leaning to hybrid.
My writing was to open up peoples mind to the idea of what is happening ingress and egress of a switchport, and to set some acronyms. To many techs think vlan is difficult when it's actually not just with the right mindset.

never connect vlan 0 from different vendors, never use spanning tree. Allways know what you are doing. ;-)
Ahh, ISL has been removed in the newer IOS XE based switching lines and you no longer have to express which encapsulation method you want to use.

I would disagree with you. I haven't been bit by the spanning-tree devil and am a firm proponent in it's use. It's definitely a best practice to use spanning-tree in switched networks. It will layer appropriately on top of other redundancy technologies like port-channels as well as protect you from loops.

Like you finished with though, knowing how to use the tool is critical. Spanning-tree with it's many variants and implementations can be difficult to master but it's absolutely essential for any portion of a network that's switched. I'll take slow (fast honestly with RSTP/MSTP) automated failover of my links any day of the week.
 
vacari
just joined
Posts: 10
Joined: Fri Mar 04, 2016 2:56 am

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

Mon Jul 31, 2017 3:52 am

Hello,
I have a RouterBOARD 3011UiAS
Firmware 3.35 version 6.41rc3
The activity led was disabled.

Thanks a lot.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Jul 31, 2017 9:54 am

What's new in 6.41rc4 (2017-Jul-28 06:48):

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 - implemented software based vlan-aware bridges;
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (CLI only);
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - show "admin-mac" only if "auto-mac=no";
*) rb922 - restored missing wireless interface on some boards;

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.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Mon Jul 31, 2017 7:28 pm

What's new in 6.41rc3 (2017-Jul-26 09:32):
*) ippool6 - try to assign desired prefix for client if prefix is not being already used;
Strods, this is implemented in the IPv6 pool code now but it doesn't seem to be implemented in the address assignment code yet, correct?
[admin@rtr1] > ipv6 address add    
address  advertise  comment  copy-from  disabled  eui-64  from-pool  no-dad  interface
I'm hoping we'll be getting an option to like "pref-prefix" where we can hint what prefix we'd like. Think a prefix of 11 for VLAN11 when getting a /56 assignment from the ISP for that networks /64. Ensuring devices remain some semblance of consistent IPs and keep us administrators sane.
 
bruins0437
newbie
Posts: 33
Joined: Thu Jul 13, 2017 4:30 am
Location: New Hampshire

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

Tue Aug 01, 2017 6:05 am

Running the command:
/export
Hardware I tested against:
  • RouterBOARD 750G r3
  • RouterBOARD wAP G-5HacT2HnD
  • RouterBOARD cAP L-2nD
The result I see in the print-out:
#error exporting /system routerboard mode-button
I'm pretty sure it's benign but just thought I'd post it.

Same issue on RouterBoard 2011. Also "Run After" appears to be broken too,it will not load exported .rsc file. Mikrotik ends up rebooting with no config at all.


-Eric
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Aug 01, 2017 3:07 pm

What's new in 6.41rc6 (2017-Aug-01 11:30):

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:

*) btest - improved reliability on Bandwidth Test when device`s RAM is almost full;
*) dhcpv6-client - do not run DHCPv6 client when IPv6 package is disabled;
*) ipv6 - fixed IPv6 address request from pool (introduced in 6.41rc1);
*) lte - fixed LTE not passing any traffic while in running state;
*) ppp - added support for Sierra MC7750, Verizon USB730L;
*) torch - fixed Torch on PPP tunnels (introduced in 6.40);

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
slimmerwifi
just joined
Posts: 17
Joined: Tue Aug 01, 2017 6:05 pm
Location: Netherlands

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

Tue Aug 01, 2017 6:16 pm

We have tested a freshly configured Hap AC with 6.41rc4 and getting large amounts of Radar detect in Regulatory domain.

Accespoint is only usable in super channel mode.

We are in a bank building so no actual radar here ;-)

Available for debugging.
 
User avatar
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

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

Tue Aug 01, 2017 8:08 pm

*) ipv6 - fixed IPv6 address request from pool (introduced in 6.41rc1);
To the half it goes. ;-)
[admin@migo] /ipv6 address> add address=::1/64 from-pool=netdsl-ipv6 interface=bridge-local advertise=yes
[admin@migo] /ipv6 address> print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-POOL INTERFACE                                                                                                                                                                                                ADVERTISE
 0 DL fe80::d6ca:6dff:fea0:ff93/64                          bridge-local                                                                                                                                                                                             no       
 1 DL fe80::d6ca:6dff:fea0:ff92/64                          ether1-gateway                                                                                                                                                                                           no       
 2 DL fe80::d/64                                            pppoe-out1                                                                                                                                                                                               no       
 3  G 2001:4dd2:a7c1::1/64                        netdsl... bridge-local                                                                                                                                                                                             yes      
It works :-D ...but...
[admin@migo] /system> reboot
...
[admin@migo] /ipv6 address> print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-POOL INTERFACE                                                                                                                                                                                                ADVERTISE
 0 IG 2001:4dd2:a7c1::1/64                        netdsl... bridge-local                                                                                                                                                                                             yes      
 1 DL fe80::d6ca:6dff:fea0:ff93/64                          bridge-local                                                                                                                                                                                             no       
 2 DL fe80::d/64                                            pppoe-out1                                                                                                                                                                                               no       
 3 DL fe80::d6ca:6dff:fea0:ff92/64                          ether1-gateway                                                                                                                                                                                         no       
Damn it! After reboot again invalid. :cry: :evil:
[admin@migo] /ipv6 address> remove
numbers: 0
[admin@migo] /ipv6 address> add address=::1/64 from-pool=netdsl-ipv6 interface=bridge-local advertise=yes
[admin@migo] /ipv6 address> print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-POOL INTERFACE                                                                                                                                                                                                ADVERTISE
 0 DL fe80::d6ca:6dff:fea0:ff93/64                          bridge-local                                                                                                                                                                                             no       
 1 DL fe80::d/64                                            pppoe-out1                                                                                                                                                                                               no       
 2 DL fe80::d6ca:6dff:fea0:ff92/64                          ether1-gateway                                                                                                                                                                                           no       
 3  G 2001:4dd2:a7c8::1/64                        netdsl... bridge-local
It works again.
Workaround. Don't reboot router :lol: Or delete and re-add after each reboot.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

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

Tue Aug 01, 2017 11:47 pm

*) ippool6 - try to assign desired prefix for client if prefix is not being already used;
So how do I use this feature?

Suppose my pool prefix is 2001:db8:abcd::/48 and I wish to assign subprefix 1234::1/64 from this pool onto interface ether1. How do I enter this?
Suppose further that I wish to define this in such a way that if the prefix changes in the future that I don't need to change anything in the router.
I.e. if tomorrow, my dhcpv6-client receives pool 2001:db8:4567::/48, then ether1 should change automatically:
from 2001:db8:abcd:1234::1/64
to 2001:db8:4567:1234::1/64

Or does this feature only apply to dhcpv6 PD server?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 02, 2017 2:32 pm

What's new in 6.41rc7 (2017-Aug-02 09: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:

*) export - fixed export for different parameters where numerical range or constant string is expected;
*) ovpn-client - fixed incorrect netmask usage for pushed routes;
*) pppoe-client - fixed incorrectly formed PADT packet;
*) winbox - added "none-dynamic" and "none-static" options for "address-list-timeout" parameter under NAT, Mangle and RAW rules;
*) winbox - do not show duplicate filter parameters "Published" in ARP list;
*) winbox - show warnings under "/system routerboard settings" menu;

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
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

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

Wed Aug 02, 2017 8:42 pm

*) ippool6 - try to assign desired prefix for client if prefix is not being already used;
So how do I use this feature?

Suppose my pool prefix is 2001:db8:abcd::/48 and I wish to assign subprefix 1234::1/64 from this pool onto interface ether1. How do I enter this?
Suppose further that I wish to define this in such a way that if the prefix changes in the future that I don't need to change anything in the router.
I get a new dynamic IPv6 prefix every time from my ISP after each reconnect or after 26 hours. (with IPv6-DHCP-Client)
Adding ::1/64 to this dynamic IPv6 prefix runs here over 4 years. A subprefix abcd::1/64, I have not yet tested. I will try the days. (If 'IPv6 address request from pool' is fixed in the rc version)

This works, the dynamic prefix is added automatically:
/ipv6 address> add address=::1/64 from-pool=ISP-pool-ipv6 interface=bridge-local advertise=yes

2001:db8:abcd::1/64
2001:db8:0123::1/64
2001:db8:4567::1/64
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Aug 03, 2017 10:19 am

Everyone who is experiencing issues with DHCPv6 client - we will have a potential fix for this problem in next 6.41rc version. Please test it when it comes available and report to support@mikrotik.com with results. If fix will help, then we will also include in upcoming current versions.
 
th0massin0
Member Candidate
Member Candidate
Posts: 156
Joined: Sun May 11, 2014 4:16 am
Location: Poland

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

Thu Aug 03, 2017 2:17 pm

*) lte - fixed LTE not passing any traffic while in running state;
Problem with reliability of SXT LTE still exists (now: PLMN search in progress) - ROS 6.41rc7.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Aug 03, 2017 4:06 pm

What's new in 6.41rc9 (2017-Aug-03 12:02):

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:

*) certificate - fixed SCEP "get" request URL encoding;
*) dhcpv6-client - fixed IA evaluation order;
*) l2tp-server - fixed PPP services becoming unresponsive after changes on L2TP server with IPSec configuration;
*) lcd - fixed LCD blinking on RB2011 (introduced in 6.40);
*) lte - added initial passthrough support for wAP LTE;
*) pppoe-client - fixed wrong auto MRU detection over VLAN interfaces;
*) pppoe-server - fixed situation when PPPoE servers become invalid after reboot;
*) sfp - fixed invalid temperature readings when ambient temperature is below 0C;

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.
 
proximus
Member Candidate
Member Candidate
Posts: 121
Joined: Tue Oct 04, 2011 1:46 pm

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

Thu Aug 03, 2017 5:07 pm

LED's on RB2011 were working again on rc7. With rc9, there are on solid (with link), no activity blinking.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Aug 03, 2017 10:30 pm

LEDs will be fixed again in the next rc release.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Thu Aug 03, 2017 11:44 pm

Does the mikrotik development team have no change control? (Cvs)
Bugs always return.....
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Fri Aug 04, 2017 8:04 am

RB2011. pppoe-client from my provider was stop working after upgrade on rc9. Downgrade to stable release.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Aug 04, 2017 10:12 am

heaven - Please send supout file to support@mikrotik.com. Generate it while PPPoE client is not working. We have tested it locally and in general PPPoE client is working as suspected. There must be something very specific.
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Fri Aug 04, 2017 7:38 pm

heaven - Please send supout file to support@mikrotik.com. Generate it while PPPoE client is not working. We have tested it locally and in general PPPoE client is working as suspected. There must be something very specific.
I was already send it! Thank you for your job, guys! :-)
 
romihg
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

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

Sat Aug 05, 2017 10:21 am

Reseting router with /system reset-configuration is the same as /system reset-configuration no-defaults option. So no defaults loaded on boot.

2011UiAS-2HnD with 6.41.9rc
 
manyyy
just joined
Posts: 3
Joined: Wed Nov 30, 2016 5:52 pm

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

Sat Aug 05, 2017 3:52 pm

I have an issue with 6.41.rc9 on RB751G-2HnD.

After upgrade from channel=current 6.40 there is no interface pppoe-client created.
Even if I add this manualy, it wont connect to the DSL BRAS.
Seems that something is wrong with Link Control Protocol.

Log debug below:
14:17:45 pppoe,ppp,debug netia: LCP lowerdown
14:17:45 pppoe,ppp,debug netia: LCP down event in initial state
14:17:45 pppoe,ppp,info netia: disconnected
14:17:55 pppoe,ppp,info netia: initializing...
14:17:55 pppoe,ppp,info netia: connecting...
14:18:05 pppoe,ppp,info netia: terminating... - disconnected
Downgrading to 6.40.1 everything goes back to operational.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Mon Aug 07, 2017 9:35 pm

Working on a new RB750Gr3 (hex). I installed 6.41rc9 and I'm unable to get an access port working for a VLAN on the new VLAN aware bridges. A similar configuration is working on a RB750Gr3 running 6,41rc6.
  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.41rc9 (c) 1999-2017       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level

[admin@rtr1] > export
# aug/07/2017 13:27:40 by RouterOS 6.41rc9
# software id = 247N-DPAI
#
# model = RouterBOARD 750G r3
# serial number = xxxxxxxxxxxx
/interface bridge
add admin-mac=6C:3B:6B:bb:xx:yy auto-mac=no fast-forward=no igmp-snooping=no name=br1 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name=eth1
set [ find default-name=ether2 ] name=eth2
set [ find default-name=ether3 ] name=eth3
set [ find default-name=ether4 ] name=eth4
set [ find default-name=ether5 ] name=eth5
/ip neighbor discovery
set eth1 discover=no
/interface vlan
add interface=br1 name=br1-vlan11 vlan-id=11
add interface=br1 name=br1-vlan12 vlan-id=12
add interface=br1 name=br1-vlan999 vlan-id=999
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=vlan11 ranges=10.214.11.100-10.214.11.199
add name=vlan12 ranges=10.214.11.100-10.214.11.199
add name=vlan13 ranges=10.214.11.100-10.214.11.199
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=br1 name=defconf
add address-pool=vlan11 disabled=no interface=br1-vlan11 name=vlan11
add address-pool=vlan12 disabled=no interface=br1-vlan12 name=vlan12
/interface bridge port
add bridge=br1 hw=no interface=eth2 pvid=11
add bridge=br1 hw=no interface=eth3
add bridge=br1 hw=no interface=eth4
add bridge=br1 hw=no interface=eth5
/interface bridge vlan
add bridge=br1 untagged=eth2 vlan-ids=11
/ip address
add address=192.168.88.1/24 comment=defconf interface=br1 network=192.168.88.0
add address=10.214.11.254/24 interface=br1-vlan11 network=10.214.11.0
add address=10.214.12.254/24 interface=br1-vlan12 network=10.214.12.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=eth1
/ip dhcp-server network
add address=10.214.11.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.11.254
add address=10.214.12.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.12.254
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=eth1
/system package update
set channel=release-candidate
#error exporting /system routerboard mode-button
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
A packet capture shows STP frames and discovery frames from the relevant VLAN interface, in this case br-vlan11, but does not seem to forward other traffic. I'm unable to mac-telnet into the router despite allowing it on the br1-vlan11 interface. I cannot ping the IP address assigned to br-vlan11 despite seeing it in the CDP message in WireShark (both interface and IP).
Last edited by idlemind on Thu Aug 17, 2017 3:38 am, edited 1 time in total.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 09, 2017 12:37 pm

What's new in 6.41rc11 (2017-Aug-08 09:32):

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 - added initial support for hardware "igmp-snooping" on CRS1xx/2xx (CLI only);
*) bridge - automatically turn off "fast-forward" feature if both bridge ports have "H" flag;
*) export - fixed interface list export;
*) ike1 - release mismatched PH2 peer IDs;
*) ike2 - check identities on "initial-contact";
*) ike2 - use peer configuration address when available on empty TSi;
*) interface - fixed corrupted "/interface list" configuration after upgrade;
*) ipsec - allow to specify remote peer address as DNS name (CLI only);
*) ipsec - renamed "firewall" argument to "notrack-chain" in peer configuration;
*) led - fixed "modem-signal" LEDs (introduced in 6.40);
*) modem - added initial support for Alcatel IK40 and Olicard 500;
*) rb2011 - fixed possible LCD blinking along with ethernet LED (introduced in 6.40);
*) rb750gr3 - show warning and do not allow to use "protected-bootloader" feature if "factory-firmware" older than 3.34.4 version;
*) ups - fixed duplicate "failed" UPS logs;
*) winbox - added certificate settings;
*) winbox - added support fro certificate CRL list;
*) winbox - do not show duplicate "Template" parameters for filter in IPSec policy list;
*) winbox - fixed bridge port sorting order by interface name;
*) winbox - hide "level" and "tunnel" parameters for IPSec policy templates;
*) winbox - hide FAN speed if it is 0RPM;
*) wireless - added "russia3" country settings;

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
osc86
Member Candidate
Member Candidate
Posts: 203
Joined: Wed Aug 09, 2017 1:15 pm

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

Wed Aug 09, 2017 1:47 pm

*) ipsec - allow to specify remote peer address as DNS name (CLI only);
does this mean ipsec tunnels can be established between 2 sites with dynamic ip addresses, so I can get rid of the additional L2TP Tunnel?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7187
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Wed Aug 09, 2017 2:01 pm

In road warrior setups, yes.
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Wed Aug 09, 2017 5:12 pm

PPPoE Client problem that I was wrote earlier is not solved in new RC. The Mikrotik support in mail was promised to me that it was been solved in future new rc((((
P.S. don' t use remote upgrade. pppoe client will not start automatically. After upgrade need to turnoff/turnon pppoe physical interface. Than pppoe client will work.
 
User avatar
PeterFreeman
just joined
Posts: 21
Joined: Tue Aug 02, 2011 10:26 pm
Location: United Kingdom
Contact:

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

Wed Aug 09, 2017 9:32 pm

Hi all,

The LED issue on the SXT LTE is still not fixed in 6.41.rc11 but it is getting a little closer...
The LED's on the back of the SXT LTE now respond to signal strength but the scale is off. Without moving our bench SXT LTE device, it shows 3-4 LEDs of signal whilst running 6.39.2. Post upgrade to 6.41.rc11 the LEDs only show 2 bars and it does not fluctuate when the signal is either improved or degraded with any significance.
The webfig interface graphs are also still broken. The graph scale is between -40 and -120 dB but eh signal is being metered in 65xxx figures. Chupaka previously noted in the 6.40 release notes that this is probably due to using the wrong DWORD in the code?

Over to you MikroTik ;-)

Many thanks

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

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

Thu Aug 10, 2017 1:46 am

New bridge with VLANs still appears broken on my test RB750Gr3 for anything later than 6.41rc6. I can't seem to get NetInstall to work on Windows 10 to try jumping backwards to 6.41rc6 to confirm 100% that is the case. I'm holding off upgrading a production RB750Gr3 past 6.41rc6 where a similar configuration is working without issue.

Packets are received on an interface at the Ethernet level and I can see the counters increment. I do not see it increase the counters on the VLAN interface though.
/interface bridge vlan add bridge=br1 untagged=eth2 vlan-ids=11
/interface vlan add add interface=br1 name=br1-vlan11 vlan-id=11
/interface bridge port add bridge=br1 hw=no interface=eth2 pvid=11
/ip address add interface=br-vlan11 address=10.214.11.254/24
 
snowflake
just joined
Posts: 11
Joined: Thu Oct 25, 2012 1:53 pm

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

Fri Aug 11, 2017 10:37 am

[quote="manyyy"]I have an issue with 6.41.rc9 on RB751G-2HnD.

I have similar problem with PPPoE on RB751G-2HnD with
6.41rc11. Even after reboot the PPPoE link does not activate.
I reconfigured it manually. Still did not work.

I tried unplugging and replugging the Ethernet cable
and the link sprang into life, so it's partially solved.
 
snowflake
just joined
Posts: 11
Joined: Thu Oct 25, 2012 1:53 pm

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

Fri Aug 11, 2017 10:38 am

[quote="manyyy"]I have an issue with 6.41.rc9 on RB751G-2HnD.

I have similar problem with PPPoE on RB751G-2HnD with
6.41rc11. Even after reboot the PPPoE link does not activate.
I reconfigured it manually. Still did not work.

I tried unplugging and replugging the Ethernet cable
and the link sprang into life, so it's partially solved.
 
User avatar
erreferre
just joined
Posts: 21
Joined: Mon Sep 08, 2014 2:29 pm

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

Fri Aug 11, 2017 10:45 am

*) sftp - added functionality which imports ".auto.rsc" file or reboots router on ".auto.npk" upload;
How can I test this new feature?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26912
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

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

Fri Aug 11, 2017 10:57 am

make a new plain text file with contents:
/system identity set name=ITWORKS
Save this file with name test.auto.rsc

Then upload it with SFTP. Check what your identity name is now.
 
User avatar
erreferre
just joined
Posts: 21
Joined: Mon Sep 08, 2014 2:29 pm

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

Fri Aug 11, 2017 11:35 am

make a new plain text file with contents:
/system identity set name=ITWORKS
Save this file with name test.auto.rsc

Then upload it with SFTP. Check what your identity name is now.
Yes, with the SFTP client of my computer. But I thought it could be possible to transfer files between MikroTik routers with a native sftp client or with a new fetch mode=sftp.
Thanks,
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri Aug 11, 2017 7:10 pm

make a new plain text file with contents:
/system identity set name=ITWORKS
Save this file with name test.auto.rsc

Then upload it with SFTP. Check what your identity name is now.
So, if I rename the 6.41rc6 .npk file to 6.41rc6.auto.npk and upload it a RouterBoard it will reboot into 6.41rc6?
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Fri Aug 11, 2017 11:00 pm

Hello

is there any problem on PPPOE-out?

after upgrade they desapear.
 
snowflake
just joined
Posts: 11
Joined: Thu Oct 25, 2012 1:53 pm

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

Sat Aug 12, 2017 2:55 pm

Hello

is there any problem on PPPOE-out?

after upgrade they desapear.
pppoe-client configs disappear after upgrade.
It also invalidates the firewall and NAT configs because the interface has disappeared.

I reinstall the pppoe-client config and try enabling pppoe-client.
I monitor the interface but nothing happens.
I unplug and re-insert the Ethernet lead and the pppoe-out1 interface springs into life.

All this is on RB751G-2HnD
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Sat Aug 12, 2017 4:34 pm

Hello

is there any problem on PPPOE-out?

after upgrade they desapear.
pppoe-client configs disappear after upgrade.
It also invalidates the firewall and NAT configs because the interface has disappeared.

I reinstall the pppoe-client config and try enabling pppoe-client.
I monitor the interface but nothing happens.
I unplug and re-insert the Ethernet lead and the pppoe-out1 interface springs into life.

All this is on RB751G-2HnD
Even ir I recreate ir it don't work
The config is there but invisible lol,
If i go back to current release it show up again and working.

Enviado de meu XT1580 usando Tapatalk
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Sat Aug 12, 2017 6:58 pm

make a new plain text file with contents:
/system identity set name=ITWORKS
Save this file with name test.auto.rsc

Then upload it with SFTP. Check what your identity name is now.
So, if I rename the 6.41rc6 .npk file to 6.41rc6.auto.npk and upload it a RouterBoard it will reboot into 6.41rc6?
So, it works for newer versions but not older versions. MikroTik please make it so you can downgrade RouterOS through this mechanic. If necessary make it a boolean value in the /ip service sftp settings to toggle allow/disallow software downgrades.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

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

Tue Aug 15, 2017 5:50 pm

So, it works for newer versions but not older versions. MikroTik please make it so you can downgrade RouterOS through this mechanic. If necessary make it a boolean value in the /ip service sftp settings to toggle allow/disallow software downgrades.
on the older versions this works just with ftp.
but there's nothing a consecutive sftp and ssh cannot fix, right :-)

scp yourcommandfile.rsc admin@router:
ssh admin@router '/import file-name=yourcommandfile.rsc; /file remove [find where name="yourcommandfile.rsc"]'

the only thing you lose is the output log.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Aug 15, 2017 6:13 pm

To be clear I was talking only about uploading a .npk file to the device for the purpose of installing a different version of RouterOS.

It allows you to upgrade (newer code) but not downgrade (older code). As an example you can up to 6.41rc11 by uploading the code file. Once in that version you cannot upload 6.41rc7. You only get a syslog message saying it's an older version.

I'm looking for a way without netinstall to allow that action.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

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

Tue Aug 15, 2017 6:30 pm

I'm looking for a way without netinstall to allow that action.
sorry.
put your npk files on the /file section, then do a
[bat@hgw2] /ip firewall nat> /sys package downgrade
it will ask for confirmation on reload, and then install whatever version you have on the files, so yes it is the way you downgrade your OS.
i hope i got it right this time.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 16, 2017 1:19 pm

What's new in 6.41rc13 (2017-Aug-15 13:09):

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 - added initial support for hardware "igmp-snooping" on CRS1xx/2xx (CLI only);
*) bridge - implemented software based "igmp-snooping" (CLI only);
*) bridge - removed "master-port" parameter (CLI only);
*) certificate - fixed import of certificates with empty SKID;
*) dhcp - require DHCP option name to be unique;
*) dhcpv6-client - ignore unknown IA;
*) hotspot - fixed missing "/ip hotspost server profile" if invalid "dns-name" was specified;
*) interface - added option to join and exclude "/interface list" from one and another;
*) lte - improved FastPath support for SXT LTE;
*) lte - added multi APN passthrough support for wAP LTE;
*) lte - do not show USB LTE modem under "/port" menu (introduced in 6.41rc);
*) lte - improved reliability of USB LTE modems;
*) lte - properly recognize USB devices under "/system resource usb" (introduced in 6.41rc12);
*) rb750gr3 - show warning and do not allow to use "protected-bootloader" feature if "factory-firmware" older than 3.34.4 version;

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
eworm
Forum Guru
Forum Guru
Posts: 1092
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Wed Aug 16, 2017 3:49 pm

I am having issues with CAPsMAN on 6.41rc13... Looks like cap interfaces with CAPsMAN forwarding do not pass any traffic.
 
User avatar
horza
just joined
Posts: 6
Joined: Sun Oct 19, 2014 3:30 pm

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

Wed Aug 16, 2017 5:42 pm

6.41rc11 -> 6.41rc13 broke my bridge on x86.
The bridge is still there, I can disable and enable it, but it registeres as "not ready" everywhere (firewall, ip...)
In an attempt to fix it, I've deleted the bridge and created a new one with default options and cleared bridge>settings, but the new bridge exhibits same behavior - "not ready" reported by ip, firewall, etc.
I've managed to nicely downgrade back to 6.41rc11 without any config changes, and it works just fine.

I've got a mipsbe test router that's configured almost identically, and that one upgraded nicely and no bridge problems (same bridge configuration as on x86 machine).
No need for help; just reporting an issue for your consideration ;-)
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Aug 16, 2017 9:09 pm

I'm looking for a way without netinstall to allow that action.
sorry.
put your npk files on the /file section, then do a
[bat@hgw2] /ip firewall nat> /sys package downgrade
it will ask for confirmation on reload, and then install whatever version you have on the files, so yes it is the way you downgrade your OS.
i hope i got it right this time.
Thank you!!!! Nice and convenient way to downgrade. Exactly what I was after.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Aug 17, 2017 3:40 am

EDIT: I'm able to replicate the problem the x86 (CHR in my case) problem as well. IP address goes invalid as soon as it's added to a VLAN interface. That said, it works fine on my RB750Gr3 now.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Aug 17, 2017 2:50 pm

idlemind - Which type of interface is the master interface of VLAN?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Aug 17, 2017 4:37 pm

idlemind - Which type of interface is the master interface of VLAN?
A bridge. If br1 is the VLAN aware bridge the master interface of the VLAN is br1.
 
kobuki
Member Candidate
Member Candidate
Posts: 211
Joined: Sat Apr 02, 2011 5:59 pm

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

Thu Aug 17, 2017 10:46 pm

With the new bridge implementation using HW offload, will it be possible to use multiple bridges using the offload capability, effectively creating multiple "switch groups" that retain wire speed in the group? It's now possible to do something similar using VLANs where each VLAN has a CPU port besides the physical ports. Would the new bridge implementation automatically create VLANs to provide such a setup?
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Fri Aug 18, 2017 7:41 am

PPPoE failed problem was not solved in new RC. My question is - When?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Aug 18, 2017 1:57 pm

What's new in 6.41rc15 (2017-Aug-18 07:33):

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:

*) capsman - added "vlan-mode=no-tag" option (CLI only);
*) capsman - return complete CA chain when issuing new certificate;
*) export - fixed "/system routerboard" export (introduced in 6.40.1);
*) ike1 - fixed initiator ID comparison to NAT-OA;
*) led - fixed "on" and "off" triggers when multiple LEDs are selected;
*) lte - added passthrough support (CLI only);
*) ospf - fixed OSPF v2 and v3 neighbor election;
*) rb1100ahx4 - fixed HW acceleration fragmented packet decryption when fragment is smaller than 64 bytes;
*) routerboard - added "mode-button" support for RB750Gr3 (CLI only);
*) sfp - fixed SFP interface power monitor when bad SFP DDMI information is received;
*) ssh - do not execute command if it starts with "-" symbol;
*) wireless - added New Zealand regulatory domain information for P2P links;
*) wireless - updated China and New Zealand 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.
 
th0massin0
Member Candidate
Member Candidate
Posts: 156
Joined: Sun May 11, 2014 4:16 am
Location: Poland

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

Fri Aug 18, 2017 2:12 pm

What's new in 6.41rc15 (2017-Aug-18 07:33):
*) lte - added passthrough support (CLI only);
Is it available for SXT LTE?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Aug 18, 2017 2:59 pm

Unfortunately, currently SXT LTE does not support passthrough mode.
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Fri Aug 18, 2017 4:13 pm

*) lte - added passthrough support (CLI only);
where? i cant find it
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Aug 18, 2017 4:29 pm

Please remember that this is rc version - new features appear, are tested, etc. Documentation, GUI support, etc. for new features might not appear right away. Also features are not fully tested yet.

LTE Passthrough is described here:
https://wiki.mikrotik.com/wiki/Manual:I ... assthrough

Soon supported LTE devices also will be listed here:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Aug 18, 2017 5:07 pm

What's new in 6.41rc16 (2017-Aug-18 13:44):

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:

*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
*) lcd - fixed unresponsive LCD (introduced in 6.41rc15);
*) lte - added passthrough support (CLI only);
*) traffic-flow - fixed reboots when IPv6 address has been set as target address without active IPv6 package;

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.
 
bommi
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

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

Fri Aug 18, 2017 5:44 pm

*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
Is there a chance to get support for brainpool ec curves like DH group 28, 29 and 30?
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Fri Aug 18, 2017 5:57 pm

What's new in 6.41rc16 (2017-Aug-18 13:44):

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:

*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
*) lcd - fixed unresponsive LCD (introduced in 6.41rc15);
*) lte - added passthrough support (CLI only);
*) traffic-flow - fixed reboots when IPv6 address has been set as target address without active IPv6 package;

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.
passthrough Works With E3372 Hilink Mode RB750Gr3
/interface lte set lte1 apn=apn1/vlan600
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Sat Aug 19, 2017 11:01 am

In RC16 PPPoE failed too. Can Support ask me when it will be solved? I think im not alone who faced with this problm.
 
b3h3m07h
newbie
Posts: 40
Joined: Sat Dec 28, 2013 3:06 am

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

Sun Aug 20, 2017 8:01 am

still having issues with RB2011UAS-2HnD and optus (aus) Huawei E3372h-607 http://www.optus.com.au/shop/prepaid/mo ... /usb/e3372

under load, p2p , multiple users on netflix or youtube, router reboots.
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Sun Aug 20, 2017 9:31 pm

Hallo!
After updating a RB922 with a Huawei ME909s-120 modem to 6.41RC16, the lte-interface doesn't switch in running mode. The status of the interface shows only one information: "Functionality == minimal", nothing else.
Is this a normal behavior in case of lte-passthrough or a bug?

regards
 
branto
just joined
Posts: 8
Joined: Mon Aug 21, 2017 2:03 am

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

Mon Aug 21, 2017 2:17 am

Working on a new RB750Gr3 (hex). I installed 6.41rc9 and I'm unable to get an access port working for a VLAN on the new VLAN aware bridges. A similar configuration is working on a RB750Gr3 running 6,41rc6.
  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.41rc9 (c) 1999-2017       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level

[admin@rtr1] > export
# aug/07/2017 13:27:40 by RouterOS 6.41rc9
# software id = 247N-DPAI
#
# model = RouterBOARD 750G r3
# serial number = xxxxxxxxxxxx
/interface bridge
add admin-mac=6C:3B:6B:bb:xx:yy auto-mac=no fast-forward=no igmp-snooping=no name=br1 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name=eth1
set [ find default-name=ether2 ] name=eth2
set [ find default-name=ether3 ] name=eth3
set [ find default-name=ether4 ] name=eth4
set [ find default-name=ether5 ] name=eth5
/ip neighbor discovery
set eth1 discover=no
/interface vlan
add interface=br1 name=br1-vlan11 vlan-id=11
add interface=br1 name=br1-vlan12 vlan-id=12
add interface=br1 name=br1-vlan999 vlan-id=999
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=vlan11 ranges=10.214.11.100-10.214.11.199
add name=vlan12 ranges=10.214.11.100-10.214.11.199
add name=vlan13 ranges=10.214.11.100-10.214.11.199
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=br1 name=defconf
add address-pool=vlan11 disabled=no interface=br1-vlan11 name=vlan11
add address-pool=vlan12 disabled=no interface=br1-vlan12 name=vlan12
/interface bridge port
add bridge=br1 hw=no interface=eth2 pvid=11
add bridge=br1 hw=no interface=eth3
add bridge=br1 hw=no interface=eth4
add bridge=br1 hw=no interface=eth5
/interface bridge vlan
add bridge=br1 untagged=eth2 vlan-ids=11
/ip address
add address=192.168.88.1/24 comment=defconf interface=br1 network=192.168.88.0
add address=10.214.11.254/24 interface=br1-vlan11 network=10.214.11.0
add address=10.214.12.254/24 interface=br1-vlan12 network=10.214.12.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=eth1
/ip dhcp-server network
add address=10.214.11.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.11.254
add address=10.214.12.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.12.254
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=eth1
/system package update
set channel=release-candidate
#error exporting /system routerboard mode-button
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
A packet capture shows STP frames and discovery frames from the relevant VLAN interface, in this case br-vlan11, but does not seem to forward other traffic. I'm unable to mac-telnet into the router despite allowing it on the br1-vlan11 interface. I cannot ping the IP address assigned to br-vlan11 despite seeing it in the CDP message in WireShark (both interface and IP).

I am seeing something very similar on a CRS210-8G-2S+ switch... CDP/LLDP passes just fine... I even get ARP in the right VLAN(s), but no dice when sending from the neighboring device on the same VLAN.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Mon Aug 21, 2017 8:46 am

Hallo!
After updating a RB922 with a Huawei ME909s-120 modem to 6.41RC16, the lte-interface doesn't switch in running mode. The status of the interface shows only one information: "Functionality == minimal", nothing else.
Is this a normal behavior in case of lte-passthrough or a bug?

regards
What was the previos version where it worked? Enable the LTE logging topic and check the log file. What Firmware version you have fro the modem?
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Mon Aug 21, 2017 10:02 am

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Mon Aug 21, 2017 5:03 pm

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
 
kd6icz
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Wed Jun 15, 2016 11:29 pm

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

Mon Aug 21, 2017 8:27 pm

I'm happy to see support for Sierra AirPrime 7750. That's a pretty old card. The MC7455 is the current "all US carrier / all US band" card.

Any chance it would be to difficult to add whatever parameters are necessary to support the MC7455? It would be the end all be all card for two or three years.

Sent from my XT1650 using Tapatalk
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Mon Aug 21, 2017 9:03 pm

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
So, after a bit of testing the solution was, that I have to do a usb power reset over CLI. Over Winbox it doesn't work and after the next reboot I have to handle the same procedure. I think there is a problem with the USB-power-reset after reboot in 6.41RC16. After a downgrade to 6.40.1 everything works fine.
The passthrough itself was working as expectet, but I can't set it on a VLAN, only physical interfaces are supported. Would it be possible to support Vlan-interfaces too?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Tue Aug 22, 2017 9:45 am

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
So, after a bit of testing the solution was, that I have to do a usb power reset over CLI. Over Winbox it doesn't work and after the next reboot I have to handle the same procedure. I think there is a problem with the USB-power-reset after reboot in 6.41RC16. After a downgrade to 6.40.1 everything works fine.
The passthrough itself was working as expectet, but I can't set it on a VLAN, only physical interfaces are supported. Would it be possible to support Vlan-interfaces too?
Have you tried to specify that init-delay?
What does it show in the log when you enable the lte logging?
It should support the Vlan interface as well - what error message did it show?
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Tue Aug 22, 2017 11:09 am

With 9 seconds init-delay the lte modem doesn't start. When the moden isn't running, I get no errors in the log. Only after a manual usb power reset it start working and also I can see messages in the log.
If I try to set a Vlan, there is no error message. But after a export I see that nothing has changed and sfp1 is still set for passthrough.
Today I will try it on my second device too.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1092
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Tue Aug 22, 2017 12:49 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.
 
dcolli
just joined
Posts: 6
Joined: Mon Mar 12, 2012 4:08 pm

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

Tue Aug 22, 2017 3:05 pm

Bug with pppoe + ipv6 + dhcp6server + static

When static addresses are created in /ipv6 dhcp-server binding (server = all) it is placed in the pool (/ipv6 pool used) after the user disconnects the pppoe it is removed from the / ipv6 pool used, and after reconnection does not return the Address for /ipv6 pool used.

commands:

/ipv6 pool used print
/ipv6 dhcp-server binding make-static numbers=0
ipv6 dhcp-server binding set 0 server=all
/ipv6 pool used print
/ppp active remove 0
/ipv6 pool used print
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Aug 22, 2017 4:30 pm

Working on a new RB750Gr3 (hex). I installed 6.41rc9 and I'm unable to get an access port working for a VLAN on the new VLAN aware bridges. A similar configuration is working on a RB750Gr3 running 6,41rc6.
  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.41rc9 (c) 1999-2017       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level

[admin@rtr1] > export
# aug/07/2017 13:27:40 by RouterOS 6.41rc9
# software id = 247N-DPAI
#
# model = RouterBOARD 750G r3
# serial number = xxxxxxxxxxxx
/interface bridge
add admin-mac=6C:3B:6B:bb:xx:yy auto-mac=no fast-forward=no igmp-snooping=no name=br1 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name=eth1
set [ find default-name=ether2 ] name=eth2
set [ find default-name=ether3 ] name=eth3
set [ find default-name=ether4 ] name=eth4
set [ find default-name=ether5 ] name=eth5
/ip neighbor discovery
set eth1 discover=no
/interface vlan
add interface=br1 name=br1-vlan11 vlan-id=11
add interface=br1 name=br1-vlan12 vlan-id=12
add interface=br1 name=br1-vlan999 vlan-id=999
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=vlan11 ranges=10.214.11.100-10.214.11.199
add name=vlan12 ranges=10.214.11.100-10.214.11.199
add name=vlan13 ranges=10.214.11.100-10.214.11.199
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=br1 name=defconf
add address-pool=vlan11 disabled=no interface=br1-vlan11 name=vlan11
add address-pool=vlan12 disabled=no interface=br1-vlan12 name=vlan12
/interface bridge port
add bridge=br1 hw=no interface=eth2 pvid=11
add bridge=br1 hw=no interface=eth3
add bridge=br1 hw=no interface=eth4
add bridge=br1 hw=no interface=eth5
/interface bridge vlan
add bridge=br1 untagged=eth2 vlan-ids=11
/ip address
add address=192.168.88.1/24 comment=defconf interface=br1 network=192.168.88.0
add address=10.214.11.254/24 interface=br1-vlan11 network=10.214.11.0
add address=10.214.12.254/24 interface=br1-vlan12 network=10.214.12.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=eth1
/ip dhcp-server network
add address=10.214.11.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.11.254
add address=10.214.12.0/24 dns-server=10.214.0.1 domain=123.local gateway=10.214.12.254
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=eth1
/system package update
set channel=release-candidate
#error exporting /system routerboard mode-button
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=br1
add interface=br1-vlan11
A packet capture shows STP frames and discovery frames from the relevant VLAN interface, in this case br-vlan11, but does not seem to forward other traffic. I'm unable to mac-telnet into the router despite allowing it on the br1-vlan11 interface. I cannot ping the IP address assigned to br-vlan11 despite seeing it in the CDP message in WireShark (both interface and IP).

I am seeing something very similar on a CRS210-8G-2S+ switch... CDP/LLDP passes just fine... I even get ARP in the right VLAN(s), but no dice when sending from the neighboring device on the same VLAN.
Turns out I missed adding the VLAN as tagged to my bridge in /interface bridge vlan

If you're already doing that check the docs. I remember a model or two of CRS was unsupported with the new bridges initially. I think they have it rectified now though
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Aug 22, 2017 6:58 pm

What's new in 6.41rc3 (2017-Jul-26 09:32):
*) ippool6 - try to assign desired prefix for client if prefix is not being already used;
@MikroTik - @strods

Multiple people have asked in this thread without a reply about this feature line. Specifically your users are requesting the ability to "hint" what they want to be assigned for both the network and host portion of an address. This can be seen in practice in OpenWRT as class hints (source: https://wiki.openwrt.org/doc/uci/network6) for the network hinting portion.

I've also placed a support case for clarification. It is #2017082222001255.

Threads (will link as I dig them back out):

viewtopic.php?f=2&t=120254&p=591415&hil ... nt#p591415
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 23, 2017 11:44 am

What's new in 6.41rc17 (2017-Aug-22 11:58):

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 - fixed "R" state for bridge interfaces on x86 and CHR installations (introduced in v6.41rc12);
*) capsman - added "vlan-mode=no-tag" option;
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
*) ipsec - allow to specify "remote-peer" address as DNS name;
*) lcd - fixed unresponsive LCD (introduced in v6.41rc15);
*) lte - added Passthrough support (CLI only);
*) pppoe - fixed invalid PPPoE server or client after reboot or "interface" edit (introduced in v6.41rc9);
*) snmp - fixed bridge host requests on devices with multiple bridge interfaces;
*) winbox - added possibility to define "comment" for "/routing bgp network" entries;
*) winbox - do not show LCD menu for devices which does not have it;
*) www - fixed unresponsive Web services (introduced in v6.40);

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.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Wed Aug 23, 2017 12:52 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.
Please provide us more info on your setup and how to reproduce the problem as we tested locally and the CAPsMAN forwarding is working.
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Wed Aug 23, 2017 12:55 pm

What's new in 6.41rc17 (2017-Aug-22 11:58):

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 - fixed "R" state for bridge interfaces on x86 and CHR installations (introduced in v6.41rc12);
*) capsman - added "vlan-mode=no-tag" option;
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
*) ipsec - allow to specify "remote-peer" address as DNS name;
*) lcd - fixed unresponsive LCD (introduced in v6.41rc15);
*) lte - added Passthrough support (CLI only);
*) pppoe - fixed invalid PPPoE server or client after reboot or "interface" edit (introduced in v6.41rc9);
*) snmp - fixed bridge host requests on devices with multiple bridge interfaces;
*) winbox - added possibility to define "comment" for "/routing bgp network" entries;
*) winbox - do not show LCD menu for devices which does not have it;
*) www - fixed unresponsive Web services (introduced in v6.40);

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.
SXT LTE?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 23, 2017 1:00 pm

irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
 
Siona
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Thu Jan 29, 2015 11:56 am

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

Wed Aug 23, 2017 1:02 pm

irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
Is it possible to add this future in future release?
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Wed Aug 23, 2017 1:11 pm

irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
in last 3 release
we have
*) lte - added Passthrough support (CLI only);
but why still no support For most important LTE device "SXT LTE"
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 23, 2017 1:45 pm

Currently SXT LTE does not support this functionality.

If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Wed Aug 23, 2017 4:32 pm

@ Mikrotik Support
*) pppoe - fixed invalid PPPoE server or client after reboot or "interface" edit (introduced in v6.41rc9);
what this suppose to fix?
because even after this RC all my pppoe don't show up either
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 23, 2017 4:37 pm

raffav - What do you mean with "don`t show up either"? Be more specific. This fixed as written in changelog "invalid PPPoE server or client after reboot or "interface" edit". Did you upgrade device and you see invalid (red) PPPoE server or client interface?
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Wed Aug 23, 2017 4:51 pm

raffav - What do you mean with "don`t show up either"? Be more specific. This fixed as written in changelog "invalid PPPoE server or client after reboot or "interface" edit". Did you upgrade device and you see invalid (red) PPPoE server or client interface?
i thought that fix applied to my case too ( pppoe interfaces disappears after reboot/upgrade)

but never mind, i just saw answer (Ticket#2017080722001328) on my mail.
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Wed Aug 23, 2017 11:19 pm

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
So, after a bit of testing the solution was, that I have to do a usb power reset over CLI. Over Winbox it doesn't work and after the next reboot I have to handle the same procedure. I think there is a problem with the USB-power-reset after reboot in 6.41RC16. After a downgrade to 6.40.1 everything works fine.
The passthrough itself was working as expectet, but I can't set it on a VLAN, only physical interfaces are supported. Would it be possible to support Vlan-interfaces too?
Have you tried to specify that init-delay?
What does it show in the log when you enable the lte logging?
It should support the Vlan interface as well - what error message did it show?

With RC17 I was able to set a Vlan for passthrough but the LTE-Modem doesn't start with 0,3,6 and 9 seconds init-delay. Also a total power-reset with a duration of more than 1 minute, didn't solve the problem. After a munual usb power-reset with a duration of 1 second, the LTE-interface starts. Tested with 2 RB922UAGS-5HPacT (current Firmware 3,41) with Huawei ME909s-120. With 3.40.1 or older I never had such problems (init-delay 1s)
 
heaven
just joined
Posts: 13
Joined: Mon Aug 15, 2016 12:14 pm

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

Thu Aug 24, 2017 8:23 am

PPPoE failed again in new RC(
 
dancsa
just joined
Posts: 6
Joined: Mon Jul 10, 2017 9:46 pm

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

Thu Aug 24, 2017 12:19 pm

We've bought several CRS326 for our network expansion plan, as we had no major issues with MT routers. As I see the future is the new offloaded bridge feature, so I tried the RC line as the 6.41 will be probably released before these switches become prod.

As for switching between ports, they work, this bridge configuration looks more comfortable than the old switch menu (which i unfamiliar).
But no mater how i tried I couldn't bring up packages to the "router", and couldn't find any pointers how should i do that. How can i create a vlan interface, for example management purpose.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Aug 24, 2017 12:59 pm

What's new in 6.41rc18 (2017-Aug-24 07:52):

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 - changed "Host" and "MDB" table column order;
*) ipv6 - add dynamic "/ip dns" server address from RA when RA is permitted by configuration;
*) log - optimized "poe-out" logging topic logs;
*) lte - added Passthrough support (CLI only);
*) poe-out - fixed router reboot after "poe-out-status" changes;
*) userman - fixed "limitation" and "profile-limitation" update;
*) webfig - allow to open table entry even if table is not sorted by # (introduced in v6.40);
*) webfig - allow to unset "rate-limit" for DHCP leases;
*) winbox - added "notrack-chain" setting to IPSec peers;
*) winbox - do not show FAN related information under "/system health" menu for devices which does not have it;
*) winbox - fixed ARP table update after entry changes state to incomplete;

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.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Aug 24, 2017 5:30 pm

What's new in 6.41rc18 (2017-Aug-24 07:52):

*) ipv6 - add dynamic "/ip dns" server address from RA when RA is permitted by configuration;
Almost there, now allow us to control the DNS server distributed in RA to enable our IPv6 clients to use the local MikroTik resolver cache.

Add an option to /ipv6 nd to specify the DNS servers!
 
buzzdee
newbie
Posts: 35
Joined: Mon Apr 22, 2013 1:22 pm

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

Fri Aug 25, 2017 6:49 pm

*) ipsec - allow to specify remote peer address as DNS name (CLI only);
does this mean ipsec tunnels can be established between 2 sites with dynamic ip addresses, so I can get rid of the additional L2TP Tunnel?
In road warrior setups, yes.
I tried that setup, mikrotik routers on both ends. Router 1 uses a dns-name as peer address, router 2 is set to 0.0.0.0/0. If I don't want to use any tunneling, I still have to specify the SA Dst. Address in router 1's policy-action. Are there plans to also make the use of dns-names possible in SA Address fields of policies?

Thanks,

BuzzDee

Edit: Seems, I'm not alone - see
viewtopic.php?f=2&t=124502&p=612878&hil ... ns#p612878
viewtopic.php?f=1&t=123534&p=610966&hil ... ns#p610966
Last edited by buzzdee on Mon Aug 28, 2017 4:34 pm, edited 1 time in total.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1092
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Mon Aug 28, 2017 3:13 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.
Please provide us more info on your setup and how to reproduce the problem as we tested locally and the CAPsMAN forwarding is working.
Opened Ticket#2017082822000816 with more details.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Mon Aug 28, 2017 3:22 pm

Hallo!
It is/was running perfect with 6.40.1 since it was released und before with 6.39.2. The Firmware of the modem is 11.617.06.00.00. To activate the logging is only with RC helpful, isn't it? I will try it once more in the evening.
We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
So, after a bit of testing the solution was, that I have to do a usb power reset over CLI. Over Winbox it doesn't work and after the next reboot I have to handle the same procedure. I think there is a problem with the USB-power-reset after reboot in 6.41RC16. After a downgrade to 6.40.1 everything works fine.
The passthrough itself was working as expectet, but I can't set it on a VLAN, only physical interfaces are supported. Would it be possible to support Vlan-interfaces too?
Have you tried to specify that init-delay?
What does it show in the log when you enable the lte logging?
It should support the Vlan interface as well - what error message did it show?

With RC17 I was able to set a Vlan for passthrough but the LTE-Modem doesn't start with 0,3,6 and 9 seconds init-delay. Also a total power-reset with a duration of more than 1 minute, didn't solve the problem. After a munual usb power-reset with a duration of 1 second, the LTE-interface starts. Tested with 2 RB922UAGS-5HPacT (current Firmware 3,41) with Huawei ME909s-120. With 3.40.1 or older I never had such problems (init-delay 1s)
Could you make a support output file after the reboot when the interface doesn't work and send that to support@mikrotik.com?
The problem also happens when you are not using the passthrough mode?
 
w0lt
Long time Member
Long time Member
Posts: 537
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

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

Mon Aug 28, 2017 4:47 pm

I've been to testing IGMP-Snooping using ROS 6.41 rc18, and have found the multicast device (and group) I'm listening to seems to time out after about 5 minutes. I was working just fine up till then with a correct entry in the "Bridge MDB" section. Do you think that rc18 has a multicast time-out issue? Seems to work just fine other than that. :-)

-tp
 
klaus007
just joined
Posts: 19
Joined: Thu Aug 17, 2017 1:11 pm

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

Mon Aug 28, 2017 6:20 pm

We tested and 909s-120 works with such firmware in RouterOS6.41rc16
Try to specify the init-delay in the System Routerboard settings to 9s and then reboot the board.
Also check if it works when you do a usb power reset option.
So, after a bit of testing the solution was, that I have to do a usb power reset over CLI. Over Winbox it doesn't work and after the next reboot I have to handle the same procedure. I think there is a problem with the USB-power-reset after reboot in 6.41RC16. After a downgrade to 6.40.1 everything works fine.
The passthrough itself was working as expectet, but I can't set it on a VLAN, only physical interfaces are supported. Would it be possible to support Vlan-interfaces too?
Have you tried to specify that init-delay?
What does it show in the log when you enable the lte logging?
It should support the Vlan interface as well - what error message did it show?

With RC17 I was able to set a Vlan for passthrough but the LTE-Modem doesn't start with 0,3,6 and 9 seconds init-delay. Also a total power-reset with a duration of more than 1 minute, didn't solve the problem. After a munual usb power-reset with a duration of 1 second, the LTE-interface starts. Tested with 2 RB922UAGS-5HPacT (current Firmware 3,41) with Huawei ME909s-120. With 3.40.1 or older I never had such problems (init-delay 1s)
Could you make a support output file after the reboot when the interface doesn't work and send that to support@mikrotik.com?
The problem also happens when you are not using the passthrough mode?

Hallo Uldis!

I have sent you the support.rif.
At the moment I have fixed it with a script after startup an a delay of 10s (It was disabled for the support-file).
Yes, the problem is still there without passthrough.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Aug 29, 2017 11:16 am

What's new in 6.41rc20 (2017-Aug-29 06:41):

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 - implemented software based vlan-aware bridges;
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option;
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - fixed "fast-forward" counters;
*) bridge - implemented software based "igmp-snooping";
*) bridge - implemented software based MSTP;
*) bridge - removed "master-port" parameter;
*) dhcpv6 client - added IAID check in reply;
*) dhcpv6-client - fixed IA check on solicit when "raoud-commit" is enabled;
*) dhcpv6-server - do not release address of static binding from pool after server removal;
*) export - fixed export for PoE-OUT related settings;
*) ipsec - kill PH1 on "mode-config" address failure;
*) led - fixed RB711UA ether1 LED (introduced in v6.38rc16);
*) lte - added Passthrough support (CLI only);
*) lte - integrated IP address acquisition without DHCP client for wAP LTE kit-US;
*) userman - fixed "limitation" and "profile-limitation" update;
*) userman - fixed CoA packet processing after changes in "/tool user-manager router" configuration;

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.
 
patrick7
Member
Member
Posts: 351
Joined: Sat Jul 20, 2013 2:40 pm

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

Tue Aug 29, 2017 12:25 pm

What's the difference between /interface ethernet switch vlan/ports and the bridge VLAN implementation?
What is the correct way to create a switch with multiple VLANs (tagged and untagged) with a management IP on a vlan?
 
ivicask
Member
Member
Posts: 438
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

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

Tue Aug 29, 2017 1:28 pm

So how is this new bridge HW offload supposed to work?I upgraded my WAP AC and than I printed my bridges after upgrade and they all say hw=no, tried creating new bridge, still says no.
Also I see there is new option Bridge Fast forward, what does it do?I tried ticking it again i see no differences anywhere regarding CPU load or anything else.
Last edited by ivicask on Tue Aug 29, 2017 1:36 pm, edited 1 time in total.
 
timberwolf
Member Candidate
Member Candidate
Posts: 274
Joined: Mon Apr 25, 2011 12:08 pm
Location: Germany

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

Tue Aug 29, 2017 1:35 pm

How would one realize inter-vlan routing or generally vlan interfaces with the new bridge implementation?
Can't find anything on this except some emtpy placeholder topic in the Wiki.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Aug 29, 2017 2:30 pm

How would one realize inter-vlan routing or generally vlan interfaces with the new bridge implementation?
Can't find anything on this except some emtpy placeholder topic in the Wiki.
Yes the wiki needs it documented formally! In the meantime:

Add your VLAN interfaces and set their interface as your bridge. Apply your IP and DHCP servers to the VLAN interfaces. Then go into /interface bridge vlan and add your VLANs and be sure to tag the bridge interface.

So it would look something like this if you were to make a brand new bridge, add VLANs 11 and 12 (10.99.11.0/24 and 10.99.12.0/24), create a VLAN 11 access port on ether2, create a VLAN 12 access port on ether3 and a trunk on ether4 with VLAN 1 as the native VLAN and allow VLANs 11 and 12 to be tagged.
/interface bridge add vlan-filtering=no name=br1

/interface vlan add interface=br1 vlan-id=11 name=br1-vlan11
/interface vlan add interface=br1 vlan-id=12 name=br1-vlan12

/ip address add interface=br-vlan11 address=10.99.11.254/24
/ip address add interface=br-vlan11 address=10.99.12.254/24

/interface bridge vlan add bridge=br1 vlan-ids=11 tagged=br1,ether4 untagged=ether2
/interface bridge vlan add bridge=br1 vlan-ids=12 tagged=br1,ether4 untagged=ether3

/interface bridge port add bridge=br1 interface=ether2 pvid=11 frame-types=admit-only-untagged-and-priority-tagged
/interface bridge port add bridge=br1 interface=ether3 pvid=12 frame-types=admit-only-untagged-and-priority-tagged
/interface bridge port add bridge=br1 interface=ether4 pvid=1 frame-types=admit-all

/interface bridge set [ find where name=br1 ] vlan-filtering=yes
Ker-blamo, you have a 2 VLAN network with an access port in each and a trunk port on ether4 to uplink to your network.
Last edited by idlemind on Tue Aug 29, 2017 4:08 pm, edited 2 times in total.
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1768
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

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

Tue Aug 29, 2017 3:30 pm

What's new in 6.41rc20 (2017-Aug-29 06:41):
uuuu, winbox support for new bridge implementation....
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Aug 29, 2017 3:36 pm

What's new in 6.41rc20 (2017-Aug-29 06:41):
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
Strods, is the CRS1xx/2xx now able to do the new bridge based VLANs without mucking around in the Ethernet switch menu? I know in the first releases it was indicated by MikroTik posts that this was required at the time. I don't own one of these types of devices so I can't test myself but I do see posts in other threads and would like to be able to help those users if possible and be as consistent as possible in my advice. I do love the new bridge implementation so far though. Good work.
 
andriys
Forum Guru
Forum Guru
Posts: 1543
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Tue Aug 29, 2017 3:42 pm

Also I see there is new option Bridge Fast forward, what does it do?
That is a special case of bridge FastPath that only works when you have exactly two interfaces in a bridge. My understanding is that this option has nothing to do with bridge HW offloading. And it's not that new, it first appeared in 6.39.
 
w0lt
Long time Member
Long time Member
Posts: 537
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

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

Tue Aug 29, 2017 5:13 pm

v6.41rc20 has some really cool stuff. I'm still having a problem with IGMP-Snooping where it drops an ACTIVE multicast group (after about 4-5 Min.). I'm not sure why it is doing this and to remedy it, I have to deactivate IGMP-Snooping and redeploy PIM (v6.40.2). I can't seem to find the ability to list the "Master Port" under Interface/Ethernet anymore. This might have been on purpose, just asking. I believe you folks are coming along nicely on IGMP-Snooping though it needs some tweaks (time will tell, right?). Would the ability to "Query" for IGMP Groups help in my case? Just spit-balling there.. :-)

Thanks,

-tp
 
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 Aug 29, 2017 5:14 pm

@andirys and mikrotik
*) bridge - implemented software based MSTP;
thank you for making this happen
 
sindudas
newbie
Posts: 36
Joined: Thu Aug 16, 2012 2:59 pm

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

Wed Aug 30, 2017 1:10 pm

@andirys and mikrotik
*) bridge - implemented software based MSTP;
thank you for making this happen
+1 :-P
 
timberwolf
Member Candidate
Member Candidate
Posts: 274
Joined: Mon Apr 25, 2011 12:08 pm
Location: Germany

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

Wed Aug 30, 2017 1:52 pm

...snip...
Ker-blamo, you have a 2 VLAN network with an access port in each and a trunk port on ether4 to uplink to your network.
Thanks, will give it a shot. :-)
 
User avatar
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

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

Wed Aug 30, 2017 1:56 pm

- ipv6 - fixed IPv6 address request from pool (introduced in 6.41rc1);

RB2011UAS v6.41rc1 - rc20
IPv6 address assignment is broken :-( State is 'invalid'


Just for INFO:
MikroTik have managed to reproduce the problem. The error only occurs with me and a few others. MikroTik are working on it. But I fear this will remain an eternal bug.
:wink: I can live with the router not to reboot.

Since 6.41rc13 the DHCPv6 client has no more prefix. The IPv6 address could therefore not be assigned manually. Since 6.41rc20 gets the DHCPv6 client again a prefix which I then manually assigned.

I can not test the feature with the dynamic subprefix.
- Ippool6 - try to assign the requested prefix for client if prefix is not being already used;
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Aug 30, 2017 2:10 pm

Seems that I managed to reproduce the problem with invalid IPv6 address on rc version. We will try to fix this as soon as possible.
 
becs
MikroTik Support
MikroTik Support
Posts: 501
Joined: Thu Jul 07, 2011 8:26 am

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

Wed Aug 30, 2017 5:43 pm

How would one realize inter-vlan routing or generally vlan interfaces with the new bridge implementation?
Can't find anything on this except some emtpy placeholder topic in the Wiki.
The example "InterVLAN Routing by Bridge" has been updated:
https://wiki.mikrotik.com/wiki/Manual:I ... _Bridge.29
 
timberwolf
Member Candidate
Member Candidate
Posts: 274
Joined: Mon Apr 25, 2011 12:08 pm
Location: Germany

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

Wed Aug 30, 2017 6:13 pm

The example "InterVLAN Routing by Bridge" has been updated:
https://wiki.mikrotik.com/wiki/Manual:I ... _Bridge.29
Thanks!
 
patrick7
Member
Member
Posts: 351
Joined: Sat Jul 20, 2013 2:40 pm

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

Wed Aug 30, 2017 9:41 pm

How about HW switching if STP and Layer3 Routing is needed? (bridge vlan disables HW)
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Aug 31, 2017 7:17 pm

How about HW switching if STP and Layer3 Routing is needed? (bridge vlan disables HW)
Patrick, the new bridge automatically toggles HW support as you enable or disable features. This doesn't require you to manually switch between /interface Ethernet switch and /interface bridge when your feature need changes or you work on different models of hardware.

https://wiki.mikrotik.com/wiki/Manual:S ... Offloading

If you scroll down you'll see a table of each switches capabilities. Depending on which product you have you'll only get certain capabilities.

It's important to note that regardless of switch chip / hardware offloading, layer 3 interactions like inter-vlan routing have always been performed in CPU (per a MikroTik support case I opened).
 
jondavy
Member Candidate
Member Candidate
Posts: 143
Joined: Tue May 12, 2009 11:14 pm
Location: Brasil

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

Thu Aug 31, 2017 8:30 pm

What's the difference between /interface ethernet switch vlan/ports and the bridge VLAN implementation?
What is the correct way to create a switch with multiple VLANs (tagged and untagged) with a management IP on a vlan?
I believe that the new implementation inside bridge of tag and tag was very simple to understand,
but for compatibility and understanding issues could be created dynamic interfaces VLAN and bridges for tagging or untagging vlans into interfaces menu
 
patrick7
Member
Member
Posts: 351
Joined: Sat Jul 20, 2013 2:40 pm

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

Thu Aug 31, 2017 8:52 pm

I'm aware of that. VLAN aware bridges disables HW offload on small switches (RB750GL etc). I'd like to have routing (this will be in CPU) AND switching (in hardware) on the same device as it was possible before 6.41rc. STP is needed too. I don't see a way how to solve this.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Aug 31, 2017 8:56 pm

I'm aware of that. VLAN aware bridges disables HW offload on small switches (RB750GL etc). I'd like to have routing (this will be in CPU) AND switching (in hardware) on the same device as it was possible before 6.41rc. STP is needed too. I don't see a way how to solve this.
If the underlying hardware supports it I imagine the new bridge implementation will catch up. Just watch the release notes for updates.
 
User avatar
NoXy
just joined
Posts: 15
Joined: Thu Sep 15, 2005 11:07 am
Location: Hungary

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

Fri Sep 01, 2017 12:12 pm

InterVLAN routing with CRS326 (ROS 6.41rc20) works well.
I have a setup like this:
- ether1 (routed, DHCP client, Internet access)
- other ports in a bridge, separated to two different vlans (ID:2,3)
- each vlan has DHCP-Server, address etc.

I see poor bandwidth (max 25-40Mbps) between host connected to any inside vlan and Internet. Do you guys have same issue?
Ports are working in offload mode, hosts on same vlan can communicate wirespeed, with few precentage of CPU usage, which shows me that hw-offload is working well.

Is it a known problem?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Sep 01, 2017 1:42 pm

Version 6.40.3 has been released:
viewtopic.php?f=21&t=125163
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Sep 01, 2017 1:59 pm

What's new in 6.41rc21 (2017-Sep-01 08: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:

!) bridge - implemented software based vlan-aware bridges;
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option;
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) arp - properly update dynamic ARP entries after interface related changes;
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
*) bridge - implemented software based MSTP;
*) bridge - removed "master-port" parameter;
*) ike1 - remove PH1 and PH2 when "mode-config" exchange fails;
*) interface - added "/interface reset-counters" command (CLI only);
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2 (CLI only);
*) lcd - fixed "flip-screen=yes" state after reboot;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Yota non-configurable modem support;
*) lte - fixed mode initialization after reboot;
*) sniffer - fixed VLAN tag reporting for TX packets (introduced 6.41rc14);
*) tile - improved reliability on MPLS package processing;
*) wireless - pass interface MAC address in Sniffer TZSP frames;
*) wireless - updated United Kingdom 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.
 
gtj
Member Candidate
Member Candidate
Posts: 121
Joined: Thu Apr 30, 2015 2:52 am
Location: Colorado US

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

Fri Sep 01, 2017 4:23 pm

I tried to upgrade a lab CRS-226-24P-2S+ from 6.40.1 to 6.41.rc18 and had major issues.

The switch is set up as a simple dumb switch, no vlans except the default and all ports switched. After the upgrade I had no IP connectivity to the switch and no connectivity through the switch. The switch was emitting LLDP since the upstream switch (also a CRS226 running 6.40.1) was showing it in the neighbors list but that's it. No mac-telnet either. Hooked up serial port and looked at the config. It "looked" correct (I have a supout which I'll send to support).

Now here's where the fun starts...
The switches are connected via SFP+ direct attach cables. After the upgrade, I lost connectivity to the UPSTREAM switch.
If I unplug the direct attach cable between the 2 switches, I get connectivity back to the upstream switch.
If I plug it back in again, I lose it. If I plug it in and change the bridge protocol on the upgraded switch to "none", I get connectivity back to the upstream switch but still no connectivity to the upgraded switch. After about an hour of playing with different settings, I decided to reset the config on the upgraded switch thinking that maybe the conversion process had an issue. No help.

Finally I did a reset with no default config and set the switch up manually by creating the bridge and adding the ports. YAY! It worked...
Except, I still have an SFP problem, but different. I no longer lose connectivity to the upstream switch but I still can't pass any traffic to the upgraded switch via that SFP port. With the 2 switches connected via ether1, no problem (I should have tried that earlier actually). Also, a Quanta 10G switch that's downstream from the upgraded switch is fine using the upgraded switch's SFP ports.

HMMM. As I'm typing this, I just heard the upgraded switch beep and sure enough, it's rebooting.

Anyway, I'm actually going to downgrade the switch back to 6.40.1 and retry the upgrade again to see if the connectivity issue was solely related to the SFP port or whether there was really a problem with the converted or default config.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Sep 01, 2017 5:08 pm

Unfortunately, currently SXT LTE does not support passthrough mode.
irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
Is there a plan for this or even and ETA? SXT LTE is the ultimate platform to get this feature.
 
w0lt
Long time Member
Long time Member
Posts: 537
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

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

Fri Sep 01, 2017 5:34 pm

v6.41rc20 has some really cool stuff. I'm still having a problem with IGMP-Snooping where it drops an ACTIVE multicast group (after about 4-5 Min.). I'm not sure why it is doing this and to remedy it, I have to deactivate IGMP-Snooping and redeploy PIM (v6.40.2). I can't seem to find the ability to list the "Master Port" under Interface/Ethernet anymore. This might have been on purpose, just asking. I believe you folks are coming along nicely on IGMP-Snooping though it needs some tweaks (time will tell, right?). Would the ability to "Query" for IGMP Groups help in my case? Just spit-balling there.. :-)

Thanks,

-tp
Still having the same problem with v6.41 rc21

-tp
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Fri Sep 01, 2017 6:01 pm

Unfortunately, currently SXT LTE does not support passthrough mode.
irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
Is there a plan for this or even and ETA? SXT LTE is the ultimate platform to get this feature.
+1 For SXT LTE
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 04, 2017 2:45 pm

What's new in 6.41rc23 (2017-Sep-04 09:07):

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:

*) address - show warning on IPv6 address when acquire from pool has failed;
*) bridge - fixed connectivity issues when there are multiple VLAN interfaces on bridge;
*) bridge - show bridge interface local addresses in the host table;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) dhcp - fixed DHCP services failing after reboot when DHCP option was used;
*) dhcpv4-client - allow to use DUID for client ID;
*) dhcpv6-client - require pool name to be unique;
*) routerboard - fixed "/system routerboard upgrade" for CRS212-8G-4S;

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.
 
TmH
just joined
Posts: 1
Joined: Mon Sep 04, 2017 9:19 pm

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

Mon Sep 04, 2017 9:26 pm

*) bridge - fixed connectivity issues when there are multiple VLAN interfaces on bridge;
.
I gave the new rc a go because of the multiple VLAN option, however after upgrading from the previous rc21 now the link is not stable anymore.
Every few minutes the link goes down and comes up again (from the mikrotik log).
Other than the new rc no changes were made to hardware [mikrotik hAP ac, RB962UiGS-5HacT2HnT] or settings. (same config etc)

Config used is blank, one bridge using all ports no vlans configured, dhcp-client on bridge interface, no firewall rules
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2182
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

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

Tue Sep 05, 2017 3:53 pm

DANGER

If you are running CAPSMAN avoid 6.41rc23

6.41rc23 breaks CAP communication with CAPSMAN, at least when using a tunelled datapath. Downgrading to 6.41rc20 does not fix the problem :(

Mikrotik support are aware of this issue.
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

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

Tue Sep 05, 2017 5:01 pm

DANGER

If you are running CAPSMAN avoid 6.41rc23

6.41rc23 breaks CAP communication with CAPSMAN, at least when using a tunelled datapath. Downgrading to 6.41rc20 does not fix the problem :(

Mikrotik support are aware of this issue.
Too late. My users complain that they are connected to the wifi, but there´s hardly any or only few traffic is getting through the connection.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Sep 05, 2017 6:05 pm

You can download prior versions of the RC by manually adjusting the URL from the download page if you wanted to revert back to an RC that it still works at for you to retain the new bridge.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Tue Sep 05, 2017 6:07 pm

DANGER

If you are running CAPSMAN avoid 6.41rc23

6.41rc23 breaks CAP communication with CAPSMAN, at least when using a tunelled datapath. Downgrading to 6.41rc20 does not fix the problem :(

Mikrotik support are aware of this issue.
Too late. My users complain that they are connected to the wifi, but there´s hardly any or only few traffic is getting through the connection.
How are you connecting the CAP to the CAPsMAN? Are you using Local-forwarding or CAPsMAN forwarding? Are you using VLAN in our setup?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Tue Sep 05, 2017 6:09 pm

You can download prior versions of the RC by manually adjusting the URL from the download page if you wanted to revert back to an RC that it still works at for you to retain the new bridge.
There is bug that after the downgrade from the newest RC you need to do a soft reboot of the board as the dhcp-client doesn't start in the first boot. Powercycle will not help, you need to do a sift reboot.
 
stucki
just joined
Posts: 19
Joined: Sun Apr 16, 2017 3:57 pm

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

Tue Sep 05, 2017 7:44 pm

How many troubles will come with V8?
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2182
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

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

Tue Sep 05, 2017 10:54 pm

How are you connecting the CAP to the CAPsMAN? Are you using Local-forwarding or CAPsMAN forwarding? Are you using VLAN in our setup?
Hi Uldis, it is Layer3 with CAPsMAN forwarding.

Even downgrading to the previously working 6.41rc20 through Package/Downgrade, the problem still remains :(
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

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

Wed Sep 06, 2017 7:57 am

There is bug that after the downgrade from the newest RC you need to do a soft reboot of the board as the dhcp-client doesn't start in the first boot. Powercycle will not help, you need to do a sift reboot.
Well, it doesn't matter what older version I used. I downgraded and then "telnet-mac" into the access point to add an dhcp-client interface which took ~ 30 seconds to be added. After a reboot the access points worked again (I went back to 6.40.3).
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Wed Sep 06, 2017 9:31 am

nz_monkey, are you using VLAN interfaces and Bridge interfaces as in v6.41RC versions there are lot of changes to the Bridge implementation that could cause some problem.
 
hzdrus
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Mon May 14, 2012 3:58 pm

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

Wed Sep 06, 2017 11:06 am

*) crs317 - added initial support for HW offloaded MPLS forwarding;
Can you elaborate on this feature? It applies solely when acting as a transit P router or when encapsulating/decapsulating l2circuit also?

P.S. Congrats on the work to implement multicast snooping. Looking forward to a stable release.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7187
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Wed Sep 06, 2017 2:53 pm

@hzdrus currently only as a P router.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Sep 08, 2017 9:42 am

What's new in 6.41rc26 (2017-Sep-07 13:26):

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);
*) chr - added KVM memory balloon support;
*) chr - added suspend support;
*) crs1xx/2xx - fixed 1 Gbps forced mode for several SFP modules;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) dhcp - fixed unresponsive DHCP service caused by inability to read not set RAW options;
*) e-mail - auto complete file name on "file" parameter (introduced in v6.40);
*) eoip - made L2MTU parameter read-only;
*) hotspot - fixed missing "/ip hotspot server profile" if invalid "dns-name" was specified;
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C;
*) lte - fixed mode initialization after reboot;
*) ppp - fixed missing PPP client interface after reboot (introduced in v6.41rc);
*) rb931-2nd - fixed startup problems (requires additional reboot after upgrade);
*) userman - fixed unresponsive RADIUS server (introduced in v6.40.3);
*) webfig - improved reliability of login 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.
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Fri Sep 08, 2017 11:39 am

What's new in 6.41rc26 (2017-Sep-07 13:26):

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);
*) chr - added KVM memory balloon support;
*) chr - added suspend support;
*) crs1xx/2xx - fixed 1 Gbps forced mode for several SFP modules;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) dhcp - fixed unresponsive DHCP service caused by inability to read not set RAW options;
*) e-mail - auto complete file name on "file" parameter (introduced in v6.40);
*) eoip - made L2MTU parameter read-only;
*) hotspot - fixed missing "/ip hotspot server profile" if invalid "dns-name" was specified;
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C;
*) lte - fixed mode initialization after reboot;
*) ppp - fixed missing PPP client interface after reboot (introduced in v6.41rc);
*) rb931-2nd - fixed startup problems (requires additional reboot after upgrade);
*) userman - fixed unresponsive RADIUS server (introduced in v6.40.3);
*) webfig - improved reliability of login 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.
is there any news about SXT LTE?
 
HasanAlawlaki
just joined
Posts: 6
Joined: Wed Sep 06, 2017 1:18 pm

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

Fri Sep 08, 2017 2:40 pm

In this vertion ..!

What about netcut and ip scanner for who using hotspot and not managed switch with ubnt AP's ?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26912
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

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

Fri Sep 08, 2017 2:56 pm

is there any news about SXT LTE?
Your question was already answered!
Unfortunately, currently SXT LTE does not support passthrough mode.
What about netcut and ip scanner for who using hotspot and not managed switch with ubnt AP's ?
Sorry, I don't understand, what are you talking about?
 
HasanAlawlaki
just joined
Posts: 6
Joined: Wed Sep 06, 2017 1:18 pm

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

Fri Sep 08, 2017 4:05 pm

Sorry i mean


The netcut program and another ip scanner can we control and block them by this new bridge features ?
 
irghost
Member
Member
Posts: 308
Joined: Sun Feb 21, 2016 1:49 pm

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

Fri Sep 08, 2017 4:29 pm

is there any news about SXT LTE?
Your question was already answered!
Unfortunately, currently SXT LTE does not support passthrough mode.
What about netcut and ip scanner for who using hotspot and not managed switch with ubnt AP's ?
Sorry, I don't understand, what are you talking about?
Does SXT LTE Support passthrough in this version?
the answer is "NO"
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3343
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Sat Sep 09, 2017 7:05 pm

Could you please add Address List to the Queue module.
In firewall you can use Address List to make more flexible rules.
In Queue and Simple Queue you can only use IP or range of IP.
 
diasem
just joined
Posts: 5
Joined: Tue Dec 08, 2015 4:15 am

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

Sat Sep 09, 2017 8:49 pm

Strods Please include dns resolution on interface torch.
 
cXXcoder
just joined
Posts: 1
Joined: Mon Sep 11, 2017 5:23 am

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

Mon Sep 11, 2017 5:37 am

What's new in 6.41rc6 (2017-Aug-01 11:30):
[...]
*) ppp - added support for Sierra MC7750, Verizon USB730L;
[...]
For the Verizon USB730L / Novatel Global Mode USB730L, would it work if plugged into USB slot of the RB750UPr2? If not, which MikroTik routers compatible? And if yes, please point me to the relevant chapters/sections of documentation, or tutorials?

Please forgive my ignorance: I do software, not networks. :-(

Thank you!
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Mon Sep 11, 2017 4:15 pm

is there any news about SXT LTE?
Your question was already answered!
Unfortunately, currently SXT LTE does not support passthrough mode.
Normis could you Elaborate.
Your answer and Wiki is ambiguous:
Saying It's not supported and it can not be done due to hardware limitations.
OR
It is currently not supported, it can be done but we have not yet made a decision If or When?.

Yours J
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 11, 2017 4:18 pm

Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Mon Sep 11, 2017 4:46 pm

Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
strods, breaking hearts on a Monday. Love it.
 
Siona
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Thu Jan 29, 2015 11:56 am

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

Mon Sep 11, 2017 5:00 pm

Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
Why? It would be really nice to have this functionality...
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Sep 12, 2017 2:24 pm

What's new in 6.41rc28 (2017-Sep-11 12:37):

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:

*) console - do not stop "/certificate sign" process if console times out in 1 minute;
*) crs317 - added L2MTU support;
*) crs3xx - added port ingress and egress rate limiting;
*) log - added "bridge" topic;
*) lte - added Passthrough support (CLI only);

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.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Tue Sep 12, 2017 3:01 pm

Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
Thanks for the elaboration.

Looking at the SXT LTE device it is the perfect fit for this function. We will buy many more of these units when this is available.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Wed Sep 13, 2017 1:51 pm

Got my first Batch of CRS317-1G-16S+ 's unpacking the first and trying out this test version.

Connected Copper (1g) and startet winbox clearing conf. Looking around and tried to change l2mtu.

/interface ethernet set l2mtu=10000 numbers=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

Boom ether1 stoped working (interface nr 0) the switch rebooted and didn't let me in again over winbox.
serialport connect reset conf and back in buissnesss.

I did notice that ether1 is connected to the same switch chip (swtich1) and perhaps this is the wrong way to change mtu. But at the same if I want 10K frames on the sfpports and no switch connectivity to the ether1 how is this accomplished with the new implementation. is there a manual for this new implementation or some pointers to get our heads round to test it properly..
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Sep 13, 2017 2:06 pm

JimmyNyholm - Did this happen when you used 6.41rc28?
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Sep 15, 2017 11:24 am

JimmyNyholm - Did this happen when you used 6.41rc28?
Yes!

admin@MikroTik] > system package print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 routeros-arm 6.41rc28
1 system 6.41rc28
2 X ipv6 6.41rc28
3 X wireless 6.41rc28
4 X hotspot 6.41rc28
5 X dhcp 6.41rc28
6 mpls 6.41rc28
7 routing 6.41rc28
8 X ppp 6.41rc28
9 security 6.41rc28
10 advanced-tools 6.41rc28
[admin@MikroTik] >
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Sep 15, 2017 2:47 pm

What's new in 6.41rc26 (2017-Sep-07 13:26):
*) crs317 - added initial support for HW offloaded MPLS forwarding;
Is this gona be not bridged intefaces can hardware switch depending on label but ldp is running on ip so one would have to configure ip adresses and a routing protocol say ospf to get routes that would be hardware switched on labels without cpu. the cpu would only run routing protocol and ldp and the hardware chip would switch/route incoming mpls packes according to ldp. being a router no l2 domain but doing it true switching on ldp labels... Like the big guys....
Is this Initial something that works now in cli or is it the first door and something to be enabled later in the rc branch.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 18, 2017 12:02 pm

What's new in 6.41rc30 (2017-Sep-15 11:50):

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 L2MTU support;
*) crs326 - fixed packet processing speed on switch chip if individual port link speed differs;
*) crs3xx - added port ingress and egress rate limiting;
*) export - fixed wireless "ssid" and "supplicant-identity" compact export;
*) ppp - fixed situation when part of PPP configuration was reset to default values after reboot;
*) wireless - added "allow-signal-out-of-range" option for Access List entries (CLI only);

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: 8712
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Mon Sep 18, 2017 12:12 pm

added "allow-signal-out-off-range" option
should be 'out of range' or 'off-range', but not both, I think :)
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 18, 2017 12:39 pm

Chupaka - Thanks! Fixed the typo in changelog.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8712
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Mon Sep 18, 2017 1:01 pm

Any use cases for this option?
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 552
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Sep 18, 2017 4:12 pm

Just tested CRS326-24G-2S+ on 6.41rc30
- started from clean config (reset w/o default)
- simple config: all port in a bridge, RSTP active
- ip dhcp client on bridge interface
- set identity and users

Reboot >> device dead

Via console I see the device is booting correctly >> startup services >> login (and after 1 sec) >> System rebooting (but the board stuck there w/o rebooting).
Note: the ether1 was the only cable plugged in and the led was off.

I was not able to create a supout (too fast in locking down); netinstall to 6.40.3 and we are in business again
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 18, 2017 4:37 pm

bajodel - Can you please send to support@mikrotik,.com precise commands which you execute to reproduce this problem? We added all ports into bridge, added DHCP client on bridge, rebooted device and it is working just fine.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 552
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Sep 18, 2017 5:27 pm

Sure, as soon as possible I'll try to redo the same setup.
Now I remember that I also changed default MACs on etherXX interfaces and set admin-MAC on bridge one.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Mon Sep 18, 2017 5:44 pm

Any use cases for this option?
Here is the discussion about that option:
viewtopic.php?f=7&t=124884
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Mon Sep 18, 2017 6:12 pm

Any use cases for this option?
Here is the discussion about that option:
viewtopic.php?f=7&t=124884
Interesting how fast some options appear compared to others, cough useful IPv6 changes.

Yes, I'm heckling you because well it's apparently needed.

Side-note: It seems the pace is slowing on this RC. I imagine this means we'll be seeing 6.41rc moving to GA and 6.42 started? Will we see a general theme targeted in this next cycle like we say with the new bridge implementation?
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Mon Sep 18, 2017 6:36 pm

Interesting how fast some options appear compared to others, cough useful IPv6 changes.

Yes, I'm heckling you because well it's apparently needed.

Side-note: It seems the pace is slowing on this RC. I imagine this means we'll be seeing 6.41rc moving to GA and 6.42 started? Will we see a general theme targeted in this next cycle like we say with the new bridge implementation?
Good observation!
I am waiting until today for a simple reset counter:

viewtopic.php?f=1&t=108552&p=614961&hil ... er#p614961
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 552
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Sep 18, 2017 7:11 pm

bajodel - Can you please send to support@mikrotik,.com precise commands which you execute to reproduce this problem? We added all ports into bridge, added DHCP client on bridge, rebooted device and it is working just fine.
Board: CRS326-24G-2S+

1) netinstalled 6.40.3
2) upgraded to 6.41rc30
3) reset w/o default
4) create bridge and put all port into it
5) change all Ethernet MACs (sample below)
/interface ethernet
set [ find default-name=ether1 ] mac-address=CC:4E:24:00:EE:01
set [ find default-name=ether2 ] mac-address=CC:4E:24:00:EE:02
set [ find default-name=ether3 ] mac-address=CC:4E:24:00:EE:03
set [ find default-name=ether4 ] mac-address=CC:4E:24:00:EE:04
set [ find default-name=ether5 ] mac-address=CC:4E:24:00:EE:05
set [ find default-name=ether6 ] mac-address=CC:4E:24:00:EE:06
set [ find default-name=ether7 ] mac-address=CC:4E:24:00:EE:07
set [ find default-name=ether8 ] mac-address=CC:4E:24:00:EE:08
set [ find default-name=ether9 ] mac-address=CC:4E:24:00:EE:09
set [ find default-name=ether10 ] mac-address=CC:4E:24:00:EE:10
set [ find default-name=ether11 ] mac-address=CC:4E:24:00:EE:11
set [ find default-name=ether12 ] mac-address=CC:4E:24:00:EE:12
set [ find default-name=ether13 ] mac-address=CC:4E:24:00:EE:13
set [ find default-name=ether14 ] mac-address=CC:4E:24:00:EE:14
set [ find default-name=ether15 ] mac-address=CC:4E:24:00:EE:15
set [ find default-name=ether16 ] mac-address=CC:4E:24:00:EE:16
set [ find default-name=ether17 ] mac-address=CC:4E:24:00:EE:17
set [ find default-name=ether18 ] mac-address=CC:4E:24:00:EE:18
set [ find default-name=ether19 ] mac-address=CC:4E:24:00:EE:19
set [ find default-name=ether20 ] mac-address=CC:4E:24:00:EE:20
set [ find default-name=ether21 ] mac-address=CC:4E:24:00:EE:21
set [ find default-name=ether22 ] mac-address=CC:4E:24:00:EE:22
set [ find default-name=ether23 ] mac-address=CC:4E:24:00:EE:23
set [ find default-name=ether24 ] mac-address=CC:4E:24:00:EE:24
set [ find default-name=sfp-sfpplus1 ] mac-address=CC:4E:24:00:EE:25
set [ find default-name=sfp-sfpplus2 ] mac-address=CC:4E:24:00:EE:26
>> Reboot

On console you'll see..
BootROM 1.41
Booting from SPI flash
BootROM: Image checksum verification PASSED


RouterBOOT booter 3.41

CRS326-24G-2S+

CPU frequency: 800 MHz
  Memory size: 512 MiB
 Storage size:  16 MiB

Press <delete> key within 4 seconds to enter setup....

loading kernel... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...

Rebooting...
Stopping services...
The board is stuck (not really rebooting); unplugging power cable you start again as above.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8712
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Tue Sep 19, 2017 10:17 am

I am waiting until today for a simple reset counter:

viewtopic.php?f=1&t=108552&p=614961&hil ... er#p614961
so, now it's available in 6.41rc? :)
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Sep 19, 2017 10:39 am

Chupaka, juliokato - Yes, it is:
*) interface - added "/interface reset-counters" command (CLI only);
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Tue Sep 19, 2017 4:01 pm

OK thanks, I'll test if it works I do not need to wait for V.7 .....

I'll just wait for the stable version.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
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: 228
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:
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
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: 1146
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: 8712
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)?
 
mszru
Frequent Visitor
Frequent Visitor
Posts: 92
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: 1658
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 Guru
Forum Guru
Posts: 1347
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: 1146
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: 1543
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: 552
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: 26912
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

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.
 
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: 248
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: 1658
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: 3446
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 Guru
Forum Guru
Posts: 1347
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
Long time Member
Long time Member
Posts: 537
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" ?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
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
Long time Member
Long time Member
Posts: 537
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
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2397
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?
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1056
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 Guru
Forum Guru
Posts: 1347
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: 8712
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.
 
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: 3446
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: 57
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
Forum Guru
Forum Guru
Posts: 1092
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!
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 57
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: 4047
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?)
 
skuykend
Member Candidate
Member Candidate
Posts: 274
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: 3343
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.
 
User avatar
floeff
newbie
Posts: 43
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: 1658
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: 552
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: 552
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: 552
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: 248
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: 1146
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: 7
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: 1658
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: 552
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
 
pcjc
just joined
Posts: 22
Joined: Wed Aug 02, 2017 4:29 pm

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

Mon Oct 02, 2017 6:36 pm

I decided to try the 6.41rc release on my new CRS326-24G-2S+.

Two notes..

1. Same with 6.40 release firmware, the LAN activity light on Port 1 RJ45 blinks on (appears to reflect activity on the bridge link?), which appears to be a bug (or is this a hardware fault I should return the unit for?)

2. I cannot set the MTU of the bridge (which replaced the old switch configuration) to support jumbo frames. (I can create a new bridge with high MTU, but get an error "Couldn't change Interface <bridge1> - could not set mtu (6)" when attempting to do so on the bridge with all my ports on.

The ports are all hardware offloaded. Do I need to set a high MTU on the bridge / interfaces within the bridge in order to be able to pass jumbo frames? (That is what I am trying to achieve).
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 552
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Oct 02, 2017 6:40 pm

It's been 4 hours and the CRS326-24G-2S+ (on 6.41rc37) is now beheaving well:
- RSTP now works stable between CRS326 and CRS125 (also on 6.41rc37)
- it's now possible to edit MAC addresses on CRS326 ethernet ports (and the device doesn't stuck on reboot)
- no port flapping (yet)

very curious about this:
*) wireless - improved WPA2 key exchange reliability;
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Tue Oct 03, 2017 11:33 am

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

Changes since previous 6.41rc release:

*) fetch - accept all HTTP 2xx status codes;
Thank you for this fix!

I don't know how it was planned but noticed that it failed at 204 status code:
[admin@CHR] > /tool fetch url="http://httpstat.us/204"
  status: failed

action failed (6)
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Tue Oct 03, 2017 11:40 am

normis, thank you for observation:
[admin@CHR] > /tool fetch url="https://httpstatuses.com/204"
      status: finished
  downloaded: 3KiBC-z pause]
    duration: 1s
It working as expected!
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26912
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

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

Tue Oct 03, 2017 11:44 am

There actually is a bug with 204, we will address it. Your previous URL works with "curl -v" so it should work in Fetch too.
 
msatter
Forum Guru
Forum Guru
Posts: 2941
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Tue Oct 03, 2017 12:31 pm

Maybe it is possible to extra spaces to end of the "KiB" to erase the remainder of the previous text: "C-z pause]" with fetch.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 89
Joined: Wed Jun 05, 2013 5:54 am

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

Tue Oct 03, 2017 2:32 pm

I have a Novotel 730 which was added in 6.41r6 & it still is function it reboots when ever I try to pass traffic through it. I already emailed support hopefully they can help me figure this out.
 
niqx
just joined
Posts: 2
Joined: Thu Oct 01, 2015 10:28 am

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

Tue Oct 03, 2017 3:34 pm

Hello Friends,

A small note, but very important for us that uses ALOT of vlans.

We're currently benching CRS317 and we're missing out the option to set notes/comments under /interface bridge vlan.

This is because we'll have alot of config here and since we're alot of people managing the same devices it's key to leave notes. :-)
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Oct 03, 2017 4:00 pm

What's new in 6.41rc38 (2017-Oct-03 11: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:

*) arm - minor improvements on CPU load distribution for RB1100 series devices;
*) bgp - added 32-bit private ASN support;
*) lte - added Passthrough support (CLI only);
*) snmp - fixed "/system license" parameters for CHR;
*) upnp - add "src-address" parameter on NAT rule if it is specified on UPnP request;
*) upnp - deny UPnP request if port is already used by the router;

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.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

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

Tue Oct 03, 2017 4:46 pm

*) bridge - initial support for "/interface list" as a bridge port (CLI only);
Try this:
/in bridge port add interface=all
It's fun! (Spoiler alert - netinstall.exe) ;-)
But actually, this feature is really what I was waiting for for a long time. I just hope these interface lists will be available for "tagged" and "untagged" attributes in "/in br vlan" section !
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Tue Oct 03, 2017 5:55 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
nescafe2002
Forum Veteran
Forum Veteran
Posts: 914
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

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

Tue Oct 03, 2017 6:00 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Tue Oct 03, 2017 6:14 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
Thank you!
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Tue Oct 03, 2017 6:16 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
We are constantly improving and fixing bugs for this feature.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3343
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Wed Oct 04, 2017 8:16 am

We are constantly improving and fixing bugs for this feature.
Then the correct should be:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - updated Passthrough support (CLI only);

What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
hapi
Member Candidate
Member Candidate
Posts: 232
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 8:58 am

Why our sfp modules don't show tx power in mikrotik? Same module in signamax switch show tx power. THX.

Signamax
Connector Type	SFP - LC
Fiber Type	Reserved
Tx Central Wavelength	1310
Baud Rate	1G
Vendor OUI	00:00:00
Vendor Name	Mikrotik
Vendor PN	S-35LC20D
Vendor Rev	1.0
Vendor SN	SK151211B35234
Date Code	151205
Temperature [Degrees Centigrade]	33.75
Vcc [Volt]	3.30
Mon1 (Bias) [mA]	1
Mon2 (TX PWR) [dBm]	-5.19
Mon3 (RX PWR) [dBm]	-17.42
CRS326-24G-2S+
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 20000m
         sfp-vendor-name: Mikrotik
  sfp-vendor-part-number: S-53LC20D
     sfp-vendor-revision: 1.0
       sfp-vendor-serial: SK151211B54444
  sfp-manufacturing-date: 15-12-05
          sfp-wavelength: 1550nm
         sfp-temperature: 40C
      sfp-supply-voltage: 3.296V
     sfp-tx-bias-current: 0mA
            sfp-rx-power: -9.752dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 02 00  00 00 00 01 0d 00 14 c8  ........ ........
                          0010: 00 00 00 00 4d 69 6b 72  6f 74 69 6b 20 20 20 20  ....Mikr otik    
                          0020: 20 20 20 20 00 00 00 00  53 2d 35 33 4c 43 32 30      .... S-53LC20
                          0030: 44 20 20 20 20 20 20 20  31 2e 30 00 06 0e 00 e4  D        1.0.....
                          0040: 00 1a 00 00 53 4b 31 35  31 32 31 31 42 35 34 34  ....SK15 1211B544
                          0050: 34 34 20 20 31 35 31 32  30 35 20 20 68 f0 04 34  44  1512 05  h..4
                          0060: 1f a0 7b 0b 1a 66 2c 8c  00 00 52 52 52 52 00 52  ..{..f,. ..RRRR.R
                          0070: 00 40 52 52 00 40 52 52  52 52 52 ff ff ff ff 00  .@RR.@RR RRR.....
                          0080: 55 00 d8 00 46 00 00 00  8d cc 74 04 88 b8 79 18  U...F... ..t...y.
                          0090: af c8 00 00 88 b8 00 00  13 94 04 eb 13 94 04 eb  ........ ........
                          00a0: 18 a6 00 10 13 94 00 10  00 00 00 00 00 00 00 00  ........ ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 40  ........ .......@
                          00e0: 28 64 80 c6 00 65 0b b3  05 89 7d 7d 7d 7d 00 7d  (d...e.. ..}}}}.}
                          00f0: 00 00 7d 7d 00 00 7d 7d  7d 7d 07 ff ff ff ff 00  ..}}..}} }}......
Last edited by hapi on Wed Oct 04, 2017 9:39 am, edited 1 time in total.
 
User avatar
skylark
Member Candidate
Member Candidate
Posts: 144
Joined: Wed Feb 10, 2016 3:55 pm

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

Wed Oct 04, 2017 9:15 am

Hello hapi,

DDM info seems quite good from SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
 
hapi
Member Candidate
Member Candidate
Posts: 232
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 9:41 am

oh my mistake, it is CRS326-24G-2S+. Modul not function on 10Gbit = auto-negotation is disable and force 1Gbit otherwise they will not join on fiber.

TX power still not show.

v6.41rc38
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 04, 2017 10:12 am

Jotne - Main idea of rc changelog is to see the difference between current and rc version. Think of an upgrade like you would upgrade from 6.40.4 to 6.41rc no from 6.41rc to 6.41rc.

Anyway, if you have more questions about changelog structure, then please create new forum topic about this or write to support@mikrotik.com

Main idea of this topic is to polish new features in 6.41rc version so that the version would become 6.41 (current) release.
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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

Wed Oct 04, 2017 6:19 pm

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
 
hapi
Member Candidate
Member Candidate
Posts: 232
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 6:46 pm

Another sfp modul, also no tx power, why? Will be fixed?
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 3000m
         sfp-vendor-name: UBNT
  sfp-vendor-part-number: UF-SM-1G-S
       sfp-vendor-serial: FT17012008409
  sfp-manufacturing-date: 17-01-12
          sfp-wavelength: 1550.32nm
         sfp-temperature: 39C
      sfp-supply-voltage: 3.263V
     sfp-tx-bias-current: 19mA
            sfp-rx-power: -7.271dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 40 00  00 00 00 01 0d 00 03 1e  ......@. ........
                          0010: 00 00 00 00 55 42 4e 54  20 20 20 20 20 20 20 20  ....UBNT         
                          0020: 20 20 20 20 00 00 00 00  55 46 2d 53 4d 2d 31 47      .... UF-SM-1G
                          0030: 2d 53 20 20 20 20 20 20  20 20 20 20 06 0e 20 37  -S           .. 7
                          0040: 20 0a 00 00 46 54 31 37  30 31 32 30 30 38 34 30   ...FT17 01200840
                          0050: 39 20 20 20 31 37 30 31  31 32 00 00 68 90 01 79  9   1701 12..h..y
                          0060: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0070: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0080: 5a 00 d3 00 55 00 d8 00  94 70 69 78 90 88 6d 60  Z...U... .pix..m`
                          0090: c3 50 00 00 af c8 00 32  18 a6 03 e8 13 94 04 eb  .P.....2 ........
                          00a0: 27 10 00 28 1f 07 00 32  00 00 00 00 00 00 00 00  '..(...2 ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 99  ........ ........
                          00e0: 27 c3 7f 78 25 76 0a 81  09 cd 00 00 00 00 22 00  '..x%v.. ......".
                          00f0: 00 40 00 00 00 40 00 00  00 00 00 ff ff ff ff 00  .@...@.. ........
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 552
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Wed Oct 04, 2017 9:25 pm

..cut.. SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
On RB3011 sfp to a CRS326-24G-2S+ via DAC cable doesn't work if you set auto-negotiation , furthermore the RB3011 doesn't detect if link go down (CRS instead correctly detects it).
All this on latest rc but also in previous 6.41rc and also 6.40.3/4
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Thu Oct 05, 2017 2:07 pm

Is it me or how do I search for learned mac-addresses with this new bridge implementation. Host table is almost always empty but local mac's but everything works.
This has been the same all this 41rc branch....

Is there a way to increase timeout on learning ( I have also asked for the option to disable learning or limit number of addresses learned.)

EDIT: Found all macs in /interfaces ethernet switch host

In this new implementation shouldn't these to tables be the same /bridge host and /interface ethernet switch host ???
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Oct 06, 2017 10:25 am

In ROS this 6.41rc (38) branch with new bridge implementation with (H)ard ware flag. if I want to use switch chip's filter function.
is this rules applied to (I want the Silicon Hardware ones...)

/interface/bridge/filter
or
/interface/ethernet/switch/rule

Am I right to believe that the switch menu will go away completely and all stuff there will be moved/added to bridge menu. My concern is where we currently stand?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10529
Joined: Mon Jun 08, 2015 12:09 pm

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

Fri Oct 06, 2017 12:33 pm

I am a bit lost on the direction and state of the new bridge implementation...
I use the switch on (mostly RB2011) routers fully configured with VLAN tagging, and with VLAN subinterfaces on the CPU port, like this:
/interface ethernet
set [ find default-name=ether3 ] master-port=ether2
set [ find default-name=ether4 ] master-port=ether2
set [ find default-name=ether5 ] master-port=ether2

/interface vlan
add interface=ether2 name=ether2.vlan12 vlan-id=12
add interface=ether2 name=ether2.vlan19 vlan-id=19
add interface=ether2 name=ether2.vlan20 vlan-id=20
add interface=ether2 name=ether2.vlan24 vlan-id=24
add interface=ether2 name=ether2.vlan44 vlan-id=44
add interface=ether2 name=ether2.vlan58 vlan-id=58

/interface ethernet switch port
set 2 vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure
set 5 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure

/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether2,ether3  switch=switch1 vlan-id=44
add independent-learning=no ports=switch1-cpu,ether2,ether3,ether4,ether5 switch=switch1 vlan-id=58
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=20
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=19
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=12
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=24
What is the current state of the "switch to bridge" migration in 6.41rc? Is it going to convert such a configuration properly
and will it still work the same way? I.e. with hardware switching between the ports on tagged and untagged VLANs even
when some ports are tagged and others untagged in the same VLAN? And will it still drop traffic from VLAN tags not
configured for that port?
 
Denkinger
just joined
Posts: 1
Joined: Sun Oct 08, 2017 12:17 am

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

Sun Oct 08, 2017 12:24 am

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
Good evening,

Same problem here...
And I think router os runs a little bit slow on that device.
 
C3H5N3O9
just joined
Posts: 5
Joined: Tue Oct 03, 2017 1:16 am

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

Sun Oct 08, 2017 10:49 pm

Can't use proxy-arp fonctionality on bridge with new bridge implementation in 6.41rc, in fact, when we try to use ppptp tunnel with proxy-arp on bridge, host behind tunnel on lan can't ping. After a downgrade in 6.40.4 everything work well.
 
poizzon
Member Candidate
Member Candidate
Posts: 113
Joined: Fri Jun 21, 2013 12:53 pm

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

Sun Oct 08, 2017 11:59 pm

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
 
ivicask
Member
Member
Posts: 438
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

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

Mon Oct 09, 2017 10:18 am

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
Can confirm this, same new WAP LTE constant reboots, Critical process died, etc in logs, works fine with older version.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 11, 2017 12:35 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):

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:

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - added comment support for VLANs;
*) bridge - added support for "/interface list" as a bridge port;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) crs3xx - fixed 100% CPU usage after interface related changes (introduced in v6.41rc31);
*) dhcpv4-client - add dynamic DHCP client for mobile clients which require it;
*) fetch - accept all HTTP 2xx status codes;
*) firewall - do not NAT address to 0.0.0.0 after reboot if to-address is used but not specified;
*) ike1 - fixed RSA authentication for Windows clients behind NAT;
*) interface - added default "/interface list" "dynamic" which contains dynamic interfaces;
*) interface - added option to join and exclude "/interface list" from one and another;
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2;
*) ipsec - fixed lost value for "remote-certificate" parameter after disable/enable;
*) ipsec - fixed policy enable/disable;
*) ipsec - improved reliability on certificate usage;
*) ipsec - skip invalid policies for phase2;
*) l2tp - improved reliability on packet processing in FastPath;
*) log - fixed interface name in log messages;
*) log - properly recognize MikroTik specific RADIUS attributes;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support (CLI only);
*) lte - fixed modem initialization after reboot;
*) lte - limited minimal default route distance to 1;
*) mac-server - use "/interface list" instead of interface name under MAC server settings;
*) neighbor - show neighbors on actual bridge port instead of bridge itself
*) sms - include timestamps in SMS delivery reports;
*) sms - properly initialize SMS storage;
*) snmp - show only available OIDs under "/system health print oid";
*) winbox - allow shorten bytes to k,M,G in Hotspot user limits;
*) winbox - do not show duplicate "Switch" menus for CRS326;
*) winbox - fixed "/certificate sign" process;
*) wireless - added "allow-signal-out-off-range" option for Access List entries;

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10529
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 2:18 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):
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.
What about configurations like mentioned in posting #275 in this topic? Are they supported now?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 2:45 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?

Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.

The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.

Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device. This also could be a WAN port, allow SSH to the device from your home or another office's IP so you can hop in that way if needed (or leave it open by src IP and use a good password / ssh key and come in via a mobile hotspot or starbucks). This would allow you to tweak the bridge config as needed.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1160
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Oct 11, 2017 3:36 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Wed Oct 11, 2017 3:44 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
 
andriys
Forum Guru
Forum Guru
Posts: 1543
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Wed Oct 11, 2017 3:49 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1160
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Oct 11, 2017 3:51 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Yes that would actually be cool IMHO.

I generally don't like features that 'call the vendor's home'. I prefer solutions that respect the user's privacy.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 4:05 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is the test IPv6 compliant. It needs to be. The address 8.8.8.8 is an IPv4 static, fail. The DNS name cloud.mikrotik.com only has an A record.

If you truly want to detect for Internet you need to use both IPv4 and IPv6 literals and a dual-stacked DNS name. We (the networking community) MUST NOT design features that are IPv4 only. The standards bodies have adopted an IPv6 first approach. I'm very sad to see this feature does not follow that stance. Some ISPs have already had to go to an IPv6 only design due to IPv4 exhaustion. Many others are doing layered IPv4 NAT (CGN) to provide psuedo IPv4 connectivity. (Look at the US cellular market). As a customer, this lack of market awareness is troubling. A feature that clearly targets home or small business routers should be IPv6 aware given the climate of connectivity.

As many forum members will likely state, this feature is of little value to them. It may find some play in the home router arena but even then it seems like overkill. I am curious as to how this test is valid. Packets sourced from my LAN IP all have access to 8.8.8.8 and cloud.mikrotik.com via the static default route and NAT rules. Does the special interface have coding that inspects the routing table?

All in all, seems like another case of MikroTik's roadmap being out of touch with actual customer needs. You don't drive sales by developing features that don't provide any value. You need to provide features that demonstrate how MikroTik routers can be used to develop solutions that create positive business outcomes. We can sell business outcomes to purchasers. Simplifying VLAN configuration and implementing RSTP and MSTP. Those are great examples of features that create value that can be translated into positive business outcomes.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10529
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 4:33 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
The defconf already changed in version 6.40! It now uses the "WAN" interface list in the firewall instead of ether1.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 89
Joined: Wed Jun 05, 2013 5:54 am

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

Wed Oct 11, 2017 4:48 pm

The Novotel 730L is still unable to stay connected it constantly loses DHCP leases even after this release.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10529
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 5:01 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
 
Zaffo
just joined
Posts: 5
Joined: Tue Jun 27, 2017 7:52 pm

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

Wed Oct 11, 2017 5:05 pm

After an upgrade from the previous rc38 to v6.41rc44 my mAP lite crashes when the ethernet cable is plugged in. First log entry after unplugging the cable states "router rebooted because some critical program crashed". Device is configured as a pocket router/AP and has one L2TP/IPsec and two ovpn clients.

After disabling the PPP clients I can connect ether1 without problems. When I now enable either one of the ovpn clients the device crashes some time after the connection is established. The L2TP/IPsec client gives no problem.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 11, 2017 5:13 pm

As for detect-interface feature. Please take a look at wiki page which was provided in changelog:
https://wiki.mikrotik.com/wiki/Manual:D ... figuration

"detect-interface-list (interface list; Default: none) All interfaces in the list will be monitored by Detect Internet"

As you can see - default value is none
 
R1CH
Forum Guru
Forum Guru
Posts: 1108
Joined: Sun Oct 01, 2006 11:44 pm

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

Wed Oct 11, 2017 5:18 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Changing the hosts is not just useful, it's a requirement. Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8712
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Wed Oct 11, 2017 5:28 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:00 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:12 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.

As far as the acceleration goes, it is model dependent. The goal is to manage hardware offload based on the switch chips available features. I got that answer from MikroTik support. The translation is that if it can do it now in the switch chip it should do it in the future with HW offload on dynamically. How long it takes to get to that state for all models, well time will tell.

The master-port option is removed so you can't really use the old configurations. MikroTik has been tight lipped about which switch chips it has enabled HW offload for. None of my test gear (hex, wap ac and cap lite) are setup in a way that I'm seeing HW offload actually turned on yet for the Ethernet ports. That said I can still pull over 300mbps across VLANs on my hex. InterVLAN routing was and always will be CPU bound and I don't really have much traffic that hits the bridges, I used software bridges in the past because the switch chip in the hex is basically a single flat layer 2 domain (no vlans).

Without meaningful release notes that tell us when each switch chip is enabled for HW offload the only thing we know is that they are developing off of CRS3xx in house. The best thing might be to target a single location that uses a RB2011 or setup a lab RB2011 and monitor the RCs progress for your particular set of options so you know when that happens or cool your heals until 6.41 goes GA.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

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

Wed Oct 11, 2017 6:19 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:31 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
The magic is in the other settings:
[admin@211-rtr1] > interface detect-internet set 
Change properties of one or several items.

detect-interface-list -- 
internet-interface-list -- 
lan-interface-list -- 
wan-interface-list -- 
If you see the wiki the lists is what does the work, set Internet interface list to something like WAN, add all interfaces to the detect-interface-list and boom you have a problem. If the LAN interface is detected to be a WAN interface it can then be elevated to an Internet interface. I'd have to setup a lab but I'd imagine it's possible to do the necessary spoofing just with routing.
 
andriys
Forum Guru
Forum Guru
Posts: 1543
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Wed Oct 11, 2017 6:52 pm

Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
My understanding is detect-internet is aimed to be used on home-users' routers, which are definitely not supposed to be running any of the dynamic routing protocols (and are not by default). Honestly, I don't see anything wrong with it. Much better to have all ports protected, and treat some of them as WAN-facing (and others as LAN-facing) when certain criteria is met, than exposing your router to the DNS amplification attacks by simply adding PPPoE interface without also modifying the existing (default) firewall rules (a common problem that multiple people complained about up until recently).
 
pe1chl
Forum Guru
Forum Guru
Posts: 10529
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 7:20 pm

PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.
Ok, that sounds good. From earlier discussion I got the impression that from now on the bridge would be one big VLAN-transparent thing, whereas in my existing practice (not the above example) I would normally put VLAN subinterfaces on ports and make the subinterfaces part of a bridge, rather than putting entire ports in the bridge and adding VLAN subinterfaces to the bridge.
However, with detailed VLAN configuration for bridge ports that could be a good solution.

I think I'll have to experiment with converting some setups on a test router...

Who is online

Users browsing this forum: No registered users and 7 guests