Community discussions

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

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

Fri 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
just joined
Posts: 23
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: 2
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: 1101
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: 1406
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
newbie
Posts: 49
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?
CCR1009-7G-1C-1S+ ROS6.45.2
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5919
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.
 
PeterFreeman
just joined
Posts: 11
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: 1101
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: 8
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: 8
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?
MTCNA, MTCWE, MTCTCE, MTCRE, MTCUME, MTCINE
www.aerowi.es
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24127
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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.
No answer to your question? How to write posts
 
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,
MTCNA, MTCWE, MTCTCE, MTCRE, MTCUME, MTCINE
www.aerowi.es
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri 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 Candidate
Member Candidate
Posts: 285
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: 8
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 Candidate
Member Candidate
Posts: 285
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: 1101
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: 507
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.
#TR0359
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue 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: 507
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.
#TR0359
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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
Member
Member
Posts: 376
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.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
User avatar
horza
just joined
Posts: 5
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: 1101
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: 1101
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: 1406
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: 1101
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: 142
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: 1406
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: 144
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: 1406
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 Candidate
Member Candidate
Posts: 280
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
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri 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: 1406
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
just joined
Posts: 24
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 Candidate
Member Candidate
Posts: 280
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
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
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: 30
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: 16
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: 3424
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: 16
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: 3424
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: 16
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: 3424
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: 16
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
Member
Member
Posts: 376
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.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
dcolli
just joined
Posts: 5
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: 1101
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: 1101
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: 1406
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: 3424
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 Candidate
Member Candidate
Posts: 280
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?
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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 Candidate
Member Candidate
Posts: 280
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"
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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 Candidate
Member Candidate
Posts: 285
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: 1406
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 Candidate
Member Candidate
Posts: 285
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: 16
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: 1406
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: 1101
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
Member
Member
Posts: 376
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.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
uldis
MikroTik Support
MikroTik Support
Posts: 3424
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
Member
Member
Posts: 481
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
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
klaus007
just joined
Posts: 16
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: 1406
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 Candidate
Member Candidate
Posts: 298
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 Candidate
Member Candidate
Posts: 230
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: 1101
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: 1721
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....
With great knowledge comes great responsibility, because of ability to recognize id... incompetent people much faster.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue 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: 1131
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
Member
Member
Posts: 481
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
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
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: 28
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: 58
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;
╰_╯ Ciao Marco!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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: 479
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 Candidate
Member Candidate
Posts: 298
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: 1101
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: 125
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 Candidate
Member Candidate
Posts: 298
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: 1101
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: 1406
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: 1406
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: 119
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: 249
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
Member
Member
Posts: 481
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
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
irghost
Member Candidate
Member Candidate
Posts: 280
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
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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: 1813
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
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.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
anuser
Member
Member
Posts: 384
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: 1101
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: 3424
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: 3424
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: 1813
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
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 :(
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
anuser
Member
Member
Posts: 384
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: 3424
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
newbie
Posts: 36
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: 5919
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: 1406
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 Candidate
Member Candidate
Posts: 280
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?
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
HasanAlawlaki
just joined
Posts: 3
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: 24127
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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?
No answer to your question? How to write posts
 
HasanAlawlaki
just joined
Posts: 3
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 Candidate
Member Candidate
Posts: 280
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"
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1290
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

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.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
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: 249
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: 1406
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: 1101
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: 1406
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: 249
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: 249
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: 1406
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: 249
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: 249
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: 1406
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: 8305
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 :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Sep 18, 2017 12:39 pm

Chupaka - Thanks! Fixed the typo in changelog.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8305
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?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon 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: 1406
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: 545
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: 3424
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: 1101
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: 229
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
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon 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: 8305
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? :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

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: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Tue Sep 19, 2017 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.
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Sep 19, 2017 5:11 pm

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

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

Tue Sep 19, 2017 5:26 pm

I can't, I have over 400 RB with USB LTE MODEM in production and the RC version has STP bridge bugs. While it is not stable I can wait another year :lol:
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Tue Sep 19, 2017 7:11 pm

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

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

Why do I ask this silly questions... because I'm experiencing strange behaviour. And the Wiki is utterly outdated on this developing area and there is no other source for this kind of information.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Sep 19, 2017 8:47 pm

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

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

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

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

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

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

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

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

Wed Sep 20, 2017 9:06 am

By the way, maybe it's possible to add an action (probably to Bridge DST-NAT - it's suitable, according to Packet Flow diagram) to set/unset VLAN tag on the packet (to do kind of MAC-based/protocol-based VLAN)?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
mszru
just joined
Posts: 18
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: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Sep 20, 2017 4:42 pm

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

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

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

Thu Sep 21, 2017 12:27 am

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

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.

I know I'm not the only one very eager for it.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Thu Sep 21, 2017 12:58 am


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

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

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

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

Thu Sep 21, 2017 2:24 am

One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Sep 21, 2017 6:53 am

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

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

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

Thu Sep 21, 2017 9:52 am

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

In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Thu Sep 21, 2017 10:37 am

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

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

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

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

Thu Sep 21, 2017 10:47 am

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

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

Thu Sep 21, 2017 10:59 am

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

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

Fri Sep 22, 2017 4:37 am

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Sep 22, 2017 12:36 pm

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
Not as faar as I can se for the moment..
And while we speak of it would it be Possible to add this to the new implementation and possibly enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
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: 3424
Joined: Mon May 31, 2004 2:55 pm

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

Fri Sep 22, 2017 5:12 pm

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

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

Fri Sep 22, 2017 5:52 pm


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

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

Fri Sep 22, 2017 6:30 pm

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

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

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri Sep 22, 2017 10:17 pm

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

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

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

Sat Sep 23, 2017 2:44 am

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

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

-tp
MTCNA - 2011

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

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

Sat Sep 23, 2017 12:32 pm

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

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

Sat Sep 23, 2017 3:40 pm

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

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

Sat Sep 23, 2017 4:48 pm

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

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

Mon Sep 25, 2017 10:47 am

Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping . :D
interface bridge set bla-bla igmp-snooping=yes
:)
This entry in changelog just means that there were some improvements in already implemented snooping.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
dschn
newbie
Posts: 25
Joined: Wed Nov 16, 2016 2:22 pm

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

Mon Sep 25, 2017 11:24 am

What version you had before on your router where it was working ok?
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...
 
uldis
MikroTik Support
MikroTik Support
Posts: 3424
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: 52
Joined: Wed Jan 09, 2013 8:26 am

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

Mon Sep 25, 2017 2:11 pm

have you planned add HW offload with vlan-filtering function?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Mon Sep 25, 2017 6:17 pm

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

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

Mon Sep 25, 2017 6:20 pm

I am having issues with CAPsMAN on 6.41rc13... Looks like cap interfaces with CAPsMAN forwarding do not pass any traffic.
The issue persists with 6.41rc16... Just downgraded to 6.41rc11 and wireless is up and running.
Updated to 6.41rc32 and everything works as expected. I can not tell what intermediate version fixed the issue though.
Thanks Uldis!
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 52
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: 4051
Joined: Wed May 11, 2011 6:08 pm

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

Wed Sep 27, 2017 12:23 am

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

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

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

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

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

Wed Sep 27, 2017 3:54 am

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

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

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

Wed Sep 27, 2017 7:55 am

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

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

Wed Sep 27, 2017 9:03 am

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

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

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

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

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

Wed Sep 27, 2017 11:40 am

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

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

Wed Sep 27, 2017 2:33 pm

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

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Wed Sep 27, 2017 8:14 pm

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

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

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

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

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

Thu Sep 28, 2017 1:03 am

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

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

Thu Sep 28, 2017 3:12 am

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

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

Sat Sep 30, 2017 10:07 am

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

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

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

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none 
2 H ether3 bridge1 yes 1 0x80 10 10 none 
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none 
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Sat Sep 30, 2017 8:33 pm

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

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

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

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

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

Sat Sep 30, 2017 9:09 pm

I think You are right (RB951Ui-2HnD), but I don't understand the log message including wlan1 port...
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Sat Sep 30, 2017 10:53 pm

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

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

Mon Oct 02, 2017 3:56 am

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

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

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

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

Mon Oct 02, 2017 11:23 am

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

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Oct 02, 2017 2:11 pm

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

Now I've enabled RSTP again and I'm going to re-insert the redundant patch cord to CRS125 ..and see what happen now
 
pcjc
just joined
Posts: 20
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: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Mon Oct 02, 2017 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: 24127
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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.
No answer to your question? How to write posts
 
msatter
Forum Guru
Forum Guru
Posts: 1195
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.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.2
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 80
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: 1406
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
Long time Member
Long time Member
Posts: 617
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: 3424
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: 1290
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

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);
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
hapi
Member Candidate
Member Candidate
Posts: 222
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
MikroTik Support
MikroTik Support
Posts: 104
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: 222
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: 1406
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: 32
Joined: Thu Aug 06, 2015 2:57 am

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: 222
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: 545
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: 249
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: 249
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: 5697
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: 2
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?
--
poi
 
ivicask
Member Candidate
Member Candidate
Posts: 230
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: 1406
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: 5697
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: 1101
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 Veteran
Forum Veteran
Posts: 890
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: 1131
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 Veteran
Forum Veteran
Posts: 890
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: 1101
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: 5697
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: 80
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: 5697
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: 3
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: 1406
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 Veteran
Forum Veteran
Posts: 883
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: 8305
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 :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

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

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

Wed Oct 11, 2017 10:27 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces that both have internet connectivity,
but their status remains at "wan" and does not go to "internet".
There are two default routes, one in the main table and one in an extra table which is selected by an IP route rule on the
source address of the second interface. Pinging 8.8.8.8 and cloud.mikrotik.com works fine.
I would have expected at least one of them to show "internet", maybe not both when this policy routing is not recognized yet.
 
boyko
just joined
Posts: 9
Joined: Sun Feb 05, 2017 1:59 am

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

Thu Oct 12, 2017 12:20 am

I just updated to the latest RC and the bridge conversion did not take in account the spoofed MAC address on the WAN port. I had to manually adjust that on the newly created bridge. This needs to be handled before the final release or people are going to have issues with it.
 
ShturmN
just joined
Posts: 1
Joined: Thu Oct 12, 2017 2:49 am

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

Thu Oct 12, 2017 3:00 am

I'm update to 6.41rc44 my sxt 5 and now:
https://s.mail.ru/6XPP/7BwY2UJm3
 
pe1chl
Forum Guru
Forum Guru
Posts: 5697
Joined: Mon Jun 08, 2015 12:09 pm

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

Thu Oct 12, 2017 10:16 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8305
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Thu Oct 12, 2017 11:06 am

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.
so, some peering partner injects a route to block himself? it's either bad or dumb peering partner :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

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

Thu Oct 12, 2017 2:52 pm

I am stuck with new bridge implementation using VLAN's either. What I want to accomplish is to pass tagged traffic through the router while reaching the router through the same VLAN.
I am using RB2011's and a RB951G with v.6.41RC44.
R1 is connected via cable to R2. R2 is connected via wireless bridge to R3. I need connection from R1 to R2 on VLAN's 3 and 1013 and from R1 to R3 on VLAN's 3 and 1002.

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0

I can connect to both VLAN's from R1 but not from R2.

R1 is configured the same way using VLAN-interfaces.
/interface vlan
add interface="P05  Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05  Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05  Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.

R2 is where I get stuck. I am trying to use a single bridge on this one as I am into using R2 as a CAP with local forwarding. So no parent VLAN interfaces will be possible.
Actually forwarding tagged traffic through R2 and connection to a Client physically connected to R2 (VLAN3) works fine.

But how do I reach R2 itself on VLAN3 ?

<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2  Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2  Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=1002
Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).
R2 is reachable on VLAN1013, but this interface is not part of the bridge.

How can I reach R2 via VLAN3?!?

Any help is highly appreciated. 8)
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri Oct 13, 2017 1:32 am

I am stuck with new bridge implementation using VLAN's either. What I want to accomplish is to pass tagged traffic through the router while reaching the router through the same VLAN.
I am using RB2011's and a RB951G with v.6.41RC44.
R1 is connected via cable to R2. R2 is connected via wireless bridge to R3. I need connection from R1 to R2 on VLAN's 3 and 1013 and from R1 to R3 on VLAN's 3 and 1002.

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0

I can connect to both VLAN's from R1 but not from R2.

R1 is configured the same way using VLAN-interfaces.
/interface vlan
add interface="P05  Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05  Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05  Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.

R2 is where I get stuck. I am trying to use a single bridge on this one as I am into using R2 as a CAP with local forwarding. So no parent VLAN interfaces will be possible.
Actually forwarding tagged traffic through R2 and connection to a Client physically connected to R2 (VLAN3) works fine.

But how do I reach R2 itself on VLAN3 ?

<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2  Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2  Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=1002
Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).
R2 is reachable on VLAN1013, but this interface is not part of the bridge.

How can I reach R2 via VLAN3?!?

Any help is highly appreciated. 8)
Long story short, read the bridge wiki page.

You need to tag the VLANs on the bridge itself in /int bridge vlan and the VLAN interfaces need to have the interface property set to the bridge in question not some random Ethernet interface.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

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

Fri Oct 13, 2017 11:06 am

Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?
 
User avatar
Gennadiy51
newbie
Posts: 25
Joined: Fri Nov 06, 2009 4:33 pm
Location: Moldova, Chisinau

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

Fri Oct 13, 2017 11:18 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?
X86 (Intel 566 MHz Slot1), RB450G, hAP lite, wAP ac, RB493G.
 
blimbach
just joined
Posts: 10
Joined: Fri Mar 04, 2016 3:39 pm
Location: Hennef, Germany

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

Fri Oct 13, 2017 12:34 pm

This Version is really bad on my hapac capsman:

oct/12/2017 17:11:40 system,error,critical router rebooted because some critical program crashed
oct/12/2017 17:41:47 system,error,critical router rebooted because some critical program crashed
oct/12/2017 17:52:04 system,error,critical router rebooted because some critical program crashed
oct/13/2017 06:56:57 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:01:37 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:20:52 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:24:24 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:37:33 system,error,critical router rebooted because some critical program crashed

<peep>.....<peep peep> every few minutes....

How to downgrade to an older rc? I cannot find a download-link.
 
kamillo
Member Candidate
Member Candidate
Posts: 154
Joined: Tue Jul 15, 2014 5:44 pm

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

Fri Oct 13, 2017 1:13 pm

How to downgrade to an older rc? I cannot find a download-link.
Go to https://mikrotik.com/download

Grab a link to latest RC for your platform and edit url to the version you want.

https://download2.mikrotik.com/routeros/6.41rc38/routeros-mipsbe-6.41rc38.npk
 
blimbach
just joined
Posts: 10
Joined: Fri Mar 04, 2016 3:39 pm
Location: Hennef, Germany

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

Fri Oct 13, 2017 1:39 pm

Thank you, downgrading fixed the Problem to me.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 80
Joined: Wed Jun 05, 2013 5:54 am

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

Fri Oct 13, 2017 3:43 pm

Same issue with the RB750gr3 had to downgrade back #sad
 
User avatar
emils
MikroTik Support
MikroTik Support
Posts: 471
Joined: Thu Dec 11, 2014 8:53 am

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

Fri Oct 13, 2017 4:06 pm

If you experience critical program crashes or kernel panics on latest release candidate versions, please send supout.rif (autosupout.rif) files to support@mikrotik.com before downgrading.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5697
Joined: Mon Jun 08, 2015 12:09 pm

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

Fri Oct 13, 2017 5:36 pm

Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?
I would advise keeping the detect-internet feature disabled until this problem is fixed.
For now it is only safe when your internet port obtains its address using DHCP. When the detect-internet sees
a DHCP reply it then remains quiet (probably for half the leasetime at least). But when there is no DHCP reply
it goes haywire.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

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

Fri Oct 13, 2017 6:36 pm

imho it is actually only good for a LAN router not for a router with direct uplink.

What I do like actually is that it gives information about the ports open via MAC. :D
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Oct 16, 2017 9:03 am

Version 6.41rc release includes fixes in WPA2 protocol:
viewtopic.php?f=21&t=126695
 
User avatar
alkar
just joined
Posts: 3
Joined: Sat Jul 04, 2015 8:29 am

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

Mon Oct 16, 2017 1:27 pm

Hi,
when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
It is difficult to manage hundreds of vlans in a text teminal.
 
andriys
Forum Guru
Forum Guru
Posts: 1131
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Mon Oct 16, 2017 3:02 pm

when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
 
Kubuxu
just joined
Posts: 2
Joined: Sat Sep 24, 2016 10:07 pm

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

Mon Oct 16, 2017 3:18 pm

Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.

Setup in question:
Main router: 3011 running 6.41.rc44 with PPPoE upstream. For simplicity two LAN ports: eth2-PC trunk port VLANs: 100 and 200, eth3-notebook access port VLAN 100.

Bridge setup:
/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.
/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook (VLAN100<->VLAN100) and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.

If I remove swich1-cpu from 'vlan add' statements connection between PC and notebook via VLAN 100 works (no DUPs) and is switched in hardware but packets are still broadcasted on every connected interface (same issue, hw-offload disabled, switch host table not populated). If I also remove VLAN filtering from the software bridge, which makes it enable hw-offload, the switch host table gets populated but then there is no separation in the software bridge.

This setup shows that switch chip in 3011 is able to perform basic VLAN filtering in hardware but using VLAN filtering on bridge makes in unusable (DUPs, loops or no hardware acceleration).

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.
Last edited by Kubuxu on Mon Oct 16, 2017 5:24 pm, edited 1 time in total.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Mon Oct 16, 2017 4:22 pm

Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.

Setup in question:
Main router: 3011 running 6.41.rc44 with PPPoE upstream. For simplicity two LAN ports: eth2-PC trunk port VLANs: 100 and 200, eth3-notebook access port VLAN 100.

Bridge setup:
/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.
/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.

If I remove swich1-cpu from 'vlan add' statements connection between PC and notebook via VLAN 100 works (no DUPs) and is switched in hardware but packets are still broadcasted on every connected interface (same issue, hw-offload disabled, switch host table not populated). If I also remove VLAN filtering from the software bridge, which makes it enable hw-offload, the switch host table gets populated but then there is no separation in the software bridge.

This setup shows that switch chip in 3011 is able to perform basic VLAN filtering in hardware but using VLAN filtering on bridge makes in unusable (DUPs, loops or no hardware acceleration).

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.
Per a case I opened with MikroTik support, expect existing hardware features to slowly be turned on in the new environment. That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU. I believe the reference platform they are using for development is the CRS3xx products. I'd expect to see other platforms covered over time. I run a 750Gr3 (hex) to perform inter-VLAN routing and it gets 300mbps+ throughput and has worked fine in my LAN considering everything else is constrained by a much slower Internet connection. Your mileage may very with other platforms and their CPU.
 
Kubuxu
just joined
Posts: 2
Joined: Sat Sep 24, 2016 10:07 pm

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

Mon Oct 16, 2017 5:23 pm

That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU.
I know that, but this is VLAN100<->VLAN100 which should be possible to be done in the switch.
expect existing hardware features to slowly be turned on in the new environment
Let's hope in future it will allow to use 3011 switch capabilities with any VLAN.
 
User avatar
alkar
just joined
Posts: 3
Joined: Sat Jul 04, 2015 8:29 am

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

Tue Oct 17, 2017 4:04 pm

when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
A "traditional" way in CRS317 not working. Switch menu shown all ports as Unknown.
viewtopic.php?f=17&t=125758
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Oct 17, 2017 5:00 pm

Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?
I'd have to see your configuration to be certain but it shouldn't be a problem as long as VLAN1 is only untagged or tagged not both on the port. Additionally, VLAN1 either needs to be untagged (default) or tagged for the bridge interface as well.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Thu Oct 19, 2017 12:42 pm

What's new in 6.41rc47 (2017-Oct-18 10:38):

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


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

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
!) routerboot - RouterBOOT version numbering system merged with RouterOS;
*) bridge - assume "point-to-point=yes" for all Full Duplex Ethernet interfaces when STP is used (as per standard);
*) console - removed "/setup";
*) crs3xx - added ingress/egress rate input limits;
*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
*) ethernet - fixed missing "sfp-tx-power" option (introduced in v6.41rc14);
*) ipsec - fixed incorrect esp proposal key size usage;
*) lte - temporarily disabled user authentication using user/password PAP/CHAP support for R11e-LTE (introduced in v6.41rc44);
*) lte - fixed PIN option after setting up the band;
*) lte - fixed error when trying to add APN profile without name;
*) lte - fixed rare crash when initializing LTE modem after reset;
*) netinstall - fixed missing default configuration prompt on first startup after reset/netinstall;
*) ssh - do not use DH group1 with strong-crypto enabled;
*) ssh - enforced 2048bit DH group on tile and x86 architectures;
*) winbox - added support for "_" symbol in terminal window;

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.
 
planetcoop
Member Candidate
Member Candidate
Posts: 115
Joined: Thu May 15, 2014 2:32 pm
Location: Sacramento, CA

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

Thu Oct 19, 2017 5:41 pm

"/ip neighbors" seems to not work on 6.41rc47 on tile...
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5919
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Oct 19, 2017 5:49 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
 
raffav
Member Candidate
Member Candidate
Posts: 285
Joined: Wed Oct 24, 2012 4:40 am

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

Thu Oct 19, 2017 5:54 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
this function is not available on winbox yet correct ?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5919
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Oct 19, 2017 5:58 pm

yes, currently only terminal. Default value is "!dynamic", but you can set it to "all".
 
raffav
Member Candidate
Member Candidate
Posts: 285
Joined: Wed Oct 24, 2012 4:40 am

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

Thu Oct 19, 2017 6:00 pm

thanks
 
pe1chl
Forum Guru
Forum Guru
Posts: 5697
Joined: Mon Jun 08, 2015 12:09 pm

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

Thu Oct 19, 2017 7:22 pm

*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
Discovery packets are now sent with source 0.0.0.0 instead of interface address as before. Maybe due to this change?
This causes firewall issues, we drop "bogon" packets (packets from an address list with certain reserved addresses including 0.0.0.0)
before the rule that accepts discovery packets.
 
raffav
Member Candidate
Member Candidate
Posts: 285
Joined: Wed Oct 24, 2012 4:40 am

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

Thu Oct 19, 2017 9:45 pm

Mikrotik team

is it difficult to create some type of address-list or something similar to use on ipsec polices in future release ?
 
alexsolovyev
just joined
Posts: 7
Joined: Thu Oct 19, 2017 10:38 pm

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

Thu Oct 19, 2017 10:49 pm

Applying the default configuration seems to be broken in 6.41rc47. I'm getting an empty config after clicking on the "OK" button after resetting the configuration. It's working in 6.40.4
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

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

Fri Oct 20, 2017 2:26 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri Oct 20, 2017 3:18 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
 
roswitina
newbie
Posts: 26
Joined: Tue Mar 12, 2013 8:12 am

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

Fri Oct 20, 2017 9:43 am

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
 
uldis
MikroTik Support
MikroTik Support
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

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

Fri Oct 20, 2017 10:09 am

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Fri Oct 20, 2017 11:24 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
and if I need a single service tag on packets ?
I've never played with new bridge but I suppose there is a place where I can set the tag type..
 
roswitina
newbie
Posts: 26
Joined: Tue Mar 12, 2013 8:12 am

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

Fri Oct 20, 2017 1:09 pm

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com
I'm doing it. I install v6.41RC47 and wait for the next crash.
Rosi
 
linek1980
newbie
Posts: 34
Joined: Thu Feb 03, 2011 1:39 pm

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

Fri Oct 20, 2017 1:30 pm

oct/19 15:40:31 system,info router rebooted
oct/19 15:40:31 system,error,critical router rebooted because some critical program crashed
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether2
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether3
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether4
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether5
oct/19 15:40:41 interface,info ether1 link up (speed 100M, full duplex)
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8305
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Fri Oct 20, 2017 2:11 pm

Please make a support output file after the crash and send it to support@mikrotik.com
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
becs
MikroTik Support
MikroTik Support
Posts: 479
Joined: Thu Jul 07, 2011 8:26 am

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

Fri Oct 20, 2017 3:09 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Fri Oct 20, 2017 6:19 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Fri Oct 20, 2017 7:00 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?
Wouldn't it have been in software before? Are their models that supported QinQ in hardware under the switch chip menu?
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

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

Sat Oct 21, 2017 8:15 am

I am still curious which devices will support HW-offloading when VLAN-Filtering is enabled. I understand, that most devices need to run inter VLAN switching via CPU, but currently all my devices (RB2011 et. al.) don't do HW-offloading at all.

Is this a software limitation of the current RC development and will be implemented in the near future?
 
guipoletto
Frequent Visitor
Frequent Visitor
Posts: 92
Joined: Mon Sep 19, 2011 5:31 am

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

Sun Oct 22, 2017 1:46 am

I would like to know if this new bridge implementation affects something on hardware that does not have an integrated switch-chip (Rb333, CCR, rb1200{ports5-10}, etc).
Are any performance gains to be expected?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Sun Oct 22, 2017 2:00 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?
 
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 Oct 23, 2017 9:37 am

*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?
Do that for capsman too.
 
darencrew
just joined
Posts: 24
Joined: Thu Nov 23, 2006 6:12 pm

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

Mon Oct 23, 2017 8:24 pm

On previous releases, a way to flush neighbor discovery entries was to disable and re-enable discovery interfaces.
Now, it has no more effects, entries disappear only after aged out.

If that's an expected behavior, as "/ip neighbor discovery" menu has disappeared on CLI, winbox "neighbor discovery interfaces" should probably go, and be replaced by the new "discovery-settings".

In my opinion, the new "/ip neighbor discovery-settings set discover-interface-list" is not totally useless but is too generic, so it should better be a new feature (or more exactly a macro) and not a replacement feature.
 
darzupan
just joined
Posts: 1
Joined: Fri Jan 21, 2011 12:45 pm

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

Tue Oct 24, 2017 9:11 am

Hi

Yesterday i bought wap-lte kit eu upgraded to version 6.41rc47 I have a problem snmp lte not working I tried to custom oid not work
When it will be repaired

mtxrltemodem interface index 1.3.6.1.4.1.14988.1.1.16.1.1.1
mtxrltemodem signalrssi 1.3.6.1.4.1.14988.1.1.16.1.1.2
mtxrltemodem signalrsrq 1.3.6.1.4.1.14988.1.1.16.1.1.3
mtxrltemodem signalrsrp 1.3.6.1.4.1.14988.1.1.16.1.1.4
mtxrltemodem cell id 1.3.6.1.4.1.14988.1.1.16.1.1.5
mtxrltemodem signalsinr 1.3.6.1.4.1.14988.1.1.16.1.1.7

Another problem

On the SIM card I have private APN xxxx.si and APN internet but I can not connect to APN xxxx.si .. tried all possible settings but the connection is not established .. apn internet works
For APN xxxx.si I use the Huawei E3372 usb modem to MT CCR1009 this works fine in the same usb modem running on MT x86 ESXi is work. But the Wap-lte kit eu private apn doesn't work.
APN xxxx.si use to connect to the official network.

What could be a problem?


Best regards

Who is online

Users browsing this forum: No registered users and 4 guests