Community discussions

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

v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Fri Jul 07, 2017 3:27 pm

Version 6.40rc36 has been released.

Important note!!! Backup before upgrade!
RouterOS v6.40rc36 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.40rc release:

!) bridge - implemented software based "igmp-snooping" (untested, undocumented, CLI only);
!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) bridge - implemented software based vlan-aware bridges;
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (undocumented, CLI only);
!) switch - CRS3xx switch VLAN configuration integrated within bridge VLAN configuration with hw-offload;
*) filesystem - improved error correcting process on tilera and RB1100Dx4 storage;
*) firewall - fixed bridge "action=log" rules;
*) health - fixed memory leak on devices that have "/system health" menu (introduced in 6.40rc30);
*) ikev1 - added log error message if netmask was not provided by "mode-config" server;
*) ipsec - added support for "key-id" peer identification type;
*) rb3011 - fixed packet passthrough on switch2 while booting;
*) sniffer - do not skip L2 packets when "all" interface mode was used;
*) snmp - fixed "/system resource cpu print oid" menu;
*) switch - fixed "loop-protect" on CRS SFP/SFP+ ports;
*) trafficgen - added "lost-ratio" to statistics;
*) vlan - do not delete existing VLAN interface on "failure: already have such vlan";
*) winbox - do not autoscale graphs outside known maximums;
*) winbox - hide LCD menu on CRS112-8G-4S;
*) winbox - show "/system health" only on boards that have health monitoring;
*) winbox - show "D" flag under "/interface mesh port" menu;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1764
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 3:31 pm

... looks like my weekend just become much more interesting!
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 3:38 pm

Same! I'm hoping this eases config across platforms without having to resort to old school software bridging everywhere.

With the new MSTP implementation will MikroTik's STP/RSTP implementation behave like the standard (untagged BPDU that represents all VLANS)?
 
nkourtzis
Member Candidate
Member Candidate
Posts: 214
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 3:40 pm

Thank you guys for delivering (actually over-delivering) on your promises! Please take your time to debug 6.40 before releasing it, since it is quite a big upgrade with lots of potential for bugs. And please, create a GUI for the new bridge implementations!

Keep up the good work!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1616
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 3:43 pm

Please note that this is the first release with such functionality and can cause different kinds of issues. Main reason for this release is to allow you to help us debug new implementation and polish it until it will be ready for 6.40 full release.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 4:01 pm

Nice,
Maybe new winbox is near?


Enviado de meu XT1580 usando Tapatalk
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 4:07 pm

With the new MSTP implementation will MikroTik's STP/RSTP implementation behave like the standard (untagged BPDU that represents all VLANS)?
Yes, that is our goal! And the "old style" bridges with VLAN interfaces and per-VLAN RSTP behavior also will remain.
 
alexjhart
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 20, 2011 8:03 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 4:57 pm

Very exciting release! Way to go Mikrotik. Looking forward to testing this out. I think this is a step in the right direction.

Does this bridge change affect the snmp mib? If so, how?
 
godlike
just joined
Posts: 21
Joined: Mon Jul 15, 2013 6:41 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 5:35 pm

Good news!
Will bridge on MT7621 have hw offloaded vlans?
 
User avatar
sguox
Trainer
Trainer
Posts: 73
Joined: Fri Mar 09, 2012 6:23 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 5:55 pm

finally, IGMP Snooping!
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 6:27 pm

Well done 'tik.

This is how things get done.

Now time for us to go break it for you and give it back :)
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 7:42 pm

will we be seeing MSTP in 6.40 (a latter RC) perhaps? is it in planning?
Has it been promised?
In case it has, can you provide a link, please?
If not, please stop spamming with the topic not directly related to the 6.40rc series.
!) bridge - implemented software based "igmp-snooping" (untested, undocumented, CLI only);
!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) bridge - implemented software based vlan-aware bridges;
thank you for the much needed MSTP, as well to andriys for the much needed support in making this happen.

look at the response, everyone is so excited!
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 10:08 pm

Someone find how to set up vlan trunk on crs 125?


Enviado de meu XT1580 usando Tapatalk
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 10:13 pm

Hi.

My WLAN interface IN AP mode just stop forwarding any data (added to a bridge). I can access to my MT by ARP only.
Is something new that I'm missing in configuration?

Regards,
RafGan.
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 10:49 pm

New created virtual AP added to the same bridge works good.
Magic.


In /bridge/hosts MAC adress of connected device is marked as Local. When device is connected to vAP, L dissapears.
Last edited by RafGan on Thu Jul 13, 2017 12:05 pm, edited 1 time in total.
 
andriys
Forum Guru
Forum Guru
Posts: 1526
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 07, 2017 11:49 pm

Does the new bridge implementation support fast-forward? If yes, what are the requirements for fast-forward to be usable?
 
alexjhart
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 20, 2011 8:03 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 12:19 am

Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
Will these "appropriate conditions" be documented on the wiki? When can we expect to see these?
 
irghost
Member
Member
Posts: 300
Joined: Sun Feb 21, 2016 1:49 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 8:07 am

do something for SXT LTE
Bridge between lte interface and ether1
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 11:12 am

In the header of the /export to file, there are two extra "comment" lines that are empty but they contain a superfluous CR character.
They show up in my editor like this:
#^M
#^M
(below the software-id)

Edit: the above was on a CHR. When I tried the new RC on a RB750 the above two lines contain the model and serial number, a nice addition,
however there still are those superfluous CR characters...
Last edited by pe1chl on Sun Jul 09, 2017 8:10 pm, edited 1 time in total.
 
User avatar
GreySer
just joined
Posts: 23
Joined: Thu Apr 21, 2016 9:38 am
Location: Cheboksary

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 1:09 pm

Version 6.40rc36 has been released.
!) bridge - implemented software based "igmp-snooping" (untested, undocumented, CLI only);


It`s work !!!
 
amokkatmt
newbie
Posts: 33
Joined: Mon Oct 24, 2011 3:31 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 1:50 pm

I have rb2011 with 2 to 5 ports in master-slave relations via "master-port". Also I had switch filter rule to limit broadcast packets to 5th port of this group flowing from other ports in this group (I have wifi access point on this 5th port and significant broadcasts on other ports). What should I do now with these new changes about discontinuing master-port? I tried to set up bridge and bridge filter rules, but after adding a rule I lost "fast path". What to do? And yes, switch rule is in place and not working, broadcasts are forwarded to 5th port:

add dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip ports=ether2-sv,ether3,ether4 switch=switch1 new-dst-ports=ether2-sv,ether3,ether4,switch1-cpu

Master is ether2, and 3-5 are slaves.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 4:56 pm

..cut.. What to do? ..cut..
IMHO stay with previous setup/version untill implementation is stable and complete; to edit bridge/switch functionality adding MSTP and igmp snooping is surely not easy step fo mt guys.
Anyway I guess your abnormal broadcast is coming from uplink swich(es), maybe you can try to mitigate from other side.
----

+1 for MT guys for their work
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 5:16 pm

Enabling mstp on the interface used for management result in disconnecting Winbox (RB750G).

No other stp device in the network.

If safe mode is active it is not possible to enable mstp.

Enabling RSTP do not trig this problem.
Last edited by FIPTech on Sat Jul 08, 2017 5:35 pm, edited 3 times in total.
 
amokkatmt
newbie
Posts: 33
Joined: Mon Oct 24, 2011 3:31 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 5:19 pm

IMHO stay with previous setup/version
It is obvious, but I want to know how to migrate existing things to these new implementations in the right way. Already downgraded.
About my broadcast it is because of specific software I run and it is under my control. I only want to not forward it to my wifi AP.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 6:22 pm

With the new MSTP implementation will MikroTik's STP/RSTP implementation behave like the standard (untagged BPDU that represents all VLANS)?
Yes, that is our goal! And the "old style" bridges with VLAN interfaces and per-VLAN RSTP behavior also will remain.
Becs, excellent thank you! This will be something we don't want to bungle in the documentation. It'd be great if we, the community, and you, MikroTik, are able to clearly articulate the behavior of each bridge and spanning-tree implementation. Hopefully it will aid those of us on the forum when we try to help fellow members solve problems and work to reduce inbound support cases to MikroTik techs.

Really appreciate the commitment to the release and I'm in the process of testing it against my Cisco switching lab with MSTP now!

Next: IPv6 features!
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 7:25 pm

I'll edit to this as I go ... MikroTik people, I'll keep my questions at the bottom of the post as I go so it's easier to find something specific to answer unless you'd prefer a post specific to each question.

Cisco Switches:

4 Cisco 2960-S switches, 2 stacks of 2 running 15.0(2)SE10a. They are the root for my VLANs which are 1 (unused), 11 (local lan), 41 (servers), 42 (servers) and 999 (blackhole vlan, no routing)

MikroTik:

1 Hex, RouterBOARD 750G r3, running 6.40rc25 (at start). Participates in spanning-tree and has IPs on several VLANs. Particularly 11, 41 and 42.

Linux KVM Hosts:

2 Whitebox Fedora servers running KVM using Linux bridging, 1 link to each Cisco switch stack using spanning-tree to get redundancy. They host servers on VLANs 41 and 42.

Current configuration:

The Cisco switches run rapid-pvst, the hex runs a legacy bridging architecture with VLAN interfaces that have spanning-tree enabled in a pvst way. The Linux servers run regular linux bridges that also perform pvst switches.

Cisco 2960-S Starting Point
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 11,41-42,999 priority 12288
MikroTik Starting Point
/interface bridge
add fast-forward=no name=br11
add fast-forward=no name=br41
add fast-forward=no name=br42
add fast-forward=no name=br999
add fast-forward=no name=loopback0

/interface bridge port
add bridge=br11 interface=eth2-vlan11
add bridge=br11 interface=eth3
add bridge=br11 interface=eth4
add bridge=br41 interface=eth2-vlan41
add bridge=br42 interface=eth2-vlan42
add bridge=br999 interface=eth2

/interface vlan
add interface=eth2 name=eth2-vlan11 vlan-id=11
add interface=eth2 name=eth2-vlan41 vlan-id=41
add interface=eth2 name=eth2-vlan42 vlan-id=42
^^ The protocol-mode by default is set to rstp so it is not shown in an export. Also the default priority of 0x8000 equals 32768 as an integer for spanning-tree bridge priority. This also means in MikroTik terms that it is Rapid-PVST not standards compliant RSTP. This impacts our compatibility work-flow. MST is meant to step down to RSTP per the standards.

Migration plan:
  1. Configure MST on the Cisco switching environment
  2. Enable MST on the Cisco switches. Rely on it's ability to translate back to the PVST implementations to keep everything online.
  3. Upgrade code on hex to the RC supporting MST bridging and configure it.
Things to try:

Plug the MikroTik into a PVST implementation, both the Cisco switch and the Linux servers. This is to see if MikroTik has implemented a translation layer to enable backward compatibility with PVST speaking devices or they rely on what is supposed to be a PVST back-off behavior into CST (regular old basic spanning-tree). My tests with Cisco indicate the pre-RC firmware and the Linux servers both do not back-off to CST so I doubt this will work. This means we'll need to migrate our Cisco switches to MST in a PVST compatible way then migrate the MIkroTik's to MST and leave the Linux boxes plugged into Cisco switches.

What changes were required:

The order of changing network configurations is almost always critical. It doesn't matter if it is something related to spanning-tree or a routing protocol. Very rarely are you able to make a change to the infrastructure that moves packets willy-nilly and it works. That in mind, I've decided to implement MST on the Cisco switches first because they are capable of speaking PVST back to our legacy Linux styled PVST bridges on the MikroTik and to my Linux KVM hosts.

That said, we need to keep some things in mind. Here are the requirements for PVST compatibility when using MST from Cisco's web-site:

PVST simulation is run on boundary ports and works in two ways http://www.cisco.com/c/en/us/support/do ... .html#anc8:

If the MST region has the root bridge for CIST, PVST simulation is required in order to replicate instance 0 information, and create one BPDU for every VLAN that is allowed across the trunk and tag it with the appropriate VLAN information.

If the root bridge for CIST is outside of the MST region, then PVST simulation is required to process VLAN 1 information only. The other BPDUs (VLANs 2 and above) are used for consistency checks and information from these VLANs is never copied as root bridge information.
For PVST simulation to work without failures, these two conditions must be met:
If the root bridge for CIST is within a non-MST region, the spanning-tree priority of VLANs 2 and above within that domain must be better (lesser) than that of VLAN 1.

If the root bridge for CIST is within a MST region, VLANs 2 and above defined in the non-MST domains must have their spanning-tree priorities worse (greater) than that of the CIST root.
If these conditions are not met, the boundary port is put into a PVST simulation inconsistent state until the problem is corrected.

With that in mind, I start with just 1 stack of the 2960-S, the current root bridge (I'll leave the 2nd in Rapid-PVST for now):

I'll be configuring 2 MST instances. Not because I really need it but just to be sure that a port can contain VLANs from multiple instances and still function properly both in compatibility situations and when the MikroTik runs MST. I'll need to follow the compatibility guidelines for having the root-bridge for VLANs within an MST region. This means my VLAN1 priority must be lower than the priority I set for my MST VLANs. Currently, VLANS 11, 41, 42 and 999 have a priority of 12288. I'll be configuring the MST instances to that priority value, so my MST 0 instance which will contain all my other VLANs (including VLAN1) will need to be set to a value less than that, for me 8192 works.

Enough talk, let's see some code:

Remember, we configure all the MST options before we issue the command to switch to MST mode otherwise ... 'here be dragons.'
spanning-tree mst configuration
 name pri-211
 revision 1
 instance 1 vlan 11, 999
 instance 2 vlan 41-42
spanning-tree mst 0 priority 8192
spanning-tree mst 1-2 priority 12288
When that's done, we make the switch:
spanning-tree mode mst
Verification Time
swi-core1#sh span vlan 1

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    8192
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    8192   (priority 8192 sys-id-ext 0)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/47            Desg FWD 200000    128.47   P2p 


swi-core1#
swi-core1#
swi-core1#sh span vlan 11

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    12289
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    12289  (priority 12288 sys-id-ext 1)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/3             Desg FWD 20000     128.3    P2p Edge 
Gi1/0/35            Desg FWD 20000     128.35   P2p Bound(PVST) 
Gi2/0/35            Desg FWD 20000     128.91   P2p Bound(PVST) 


swi-core1#
swi-core1#
swi-core1#sh span vlan 41

MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    12290
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    12290  (priority 12288 sys-id-ext 2)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/13            Desg FWD 20000     128.13   P2p Edge 
Gi1/0/14            Desg FWD 20000     128.14   P2p Bound(PVST) 
Gi1/0/15            Desg FWD 20000     128.15   P2p Edge 
Gi1/0/35            Desg FWD 20000     128.35   P2p Bound(PVST) 
Gi2/0/35            Desg FWD 20000     128.91   P2p Bound(PVST) 


swi-core1#
swi-core1#
swi-core1#sh span

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    8192
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    8192   (priority 8192 sys-id-ext 0)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/3             Desg FWD 20000     128.3    P2p Edge 
Gi1/0/13            Desg FWD 20000     128.13   P2p Edge 
Gi1/0/14            Desg FWD 20000     128.14   P2p Bound(PVST) 
Gi1/0/15            Desg FWD 20000     128.15   P2p Edge 
Gi1/0/35            Desg FWD 20000     128.35   P2p Bound(PVST) 
Gi1/0/47            Desg FWD 200000    128.47   P2p 
Gi2/0/35            Desg FWD 20000     128.91   P2p Bound(PVST) 

          
          
MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    12289
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    12289  (priority 12288 sys-id-ext 1)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/3             Desg FWD 20000     128.3    P2p Edge 
Gi1/0/35            Desg FWD 20000     128.35   P2p Bound(PVST) 
Gi2/0/35            Desg FWD 20000     128.91   P2p Bound(PVST) 


          
MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    12290
             Address     8cb6.4f20.2180
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    12290  (priority 12288 sys-id-ext 2)
             Address     8cb6.4f20.2180
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 20000     128.1    P2p Bound(PVST) 
Gi1/0/13            Desg FWD 20000     128.13   P2p Edge 
Gi1/0/14            Desg FWD 20000     128.14   P2p Bound(PVST) 
Gi1/0/15            Desg FWD 20000     128.15   P2p Edge 
Gi1/0/35            Desg FWD 20000     128.35   P2p Bound(PVST) 
Gi2/0/35            Desg FWD 20000     128.91   P2p Bound(PVST) 


swi-core1#
We have a working MST configuration on 1 stack of Cisco 2960-S switches that is talking correctly to our PVST configured friends (the other 2960-S stack, the MikroTik using legacy bridges and the Linux KVM hosts using Linux bridges)

Additionally, the new commands appear to be inline with the current software bridging approach which is AWESOME. The only thing that has caught me off-guard is the untagged portion of the bridge vlan add command expects an interface (ether2 for example). I was expecting it to take a VLAN. Additionally, I'm going to have to think about where the IP addressing goes. I'm guessing it has to be a VLAN interface where the parent interface is the new bridge. We'll see how it goes. Time to break the network!

In the MikroTik:
/interface bridge add name=br-master1 protocol-mode=mstp region-name=pri-211 region-revision=1 vlan-filtering=yes
/interface bridge msti add bridge=br-master1 identifier=1 vlan-mapping=11,999
/interface bridge msti add bridge=br-master1 identifier=2 vlan-mapping=41-42
/interface bridge vlan add bridge=br-master1 vlan-ids=1,42
/interface bridge port add bridge=br-master1 interface=eth4
/interface vlan add interface=br-master1 name=br-master1-vl42 vlan-id=42
I then moved the IP from what was a bridge (br42) for that VLAN. I left my VLAN interface for eth2 tagging VLAN42 down to my core on gi 1/0/1. This means, from a spanning-tree perspective I'd suspect one of the two links to the root bridge (Cisco switch) to be disabled for VLANs 1,42. When I look at the MikroTik interfaces area I don't see anything disabled. The interfaces involved would be Ethernet (eth2, eth4), VLANs (eth2-vlan42), bridges (br-master1 or br42). None are set to disabled. I'm trying to verify if I do have a loop condition on but nothing conclusive so far.

Current state: eth2 using legacy bridge w/VLAN interfaces as bridge ports, eth4 using a new bridge (br-master1) on VLANs 1 and 42 to a trunk port on the MSTP Cisco Switch with allowed VLANs 1,42. Everything works, a sh span vlan 42 show's MST instance 2 as expected with Gi2/0/1 (plugs into eth4) as P2P in status FWD (as expected, eth2 or eth4 - likely eth4 from port-id and matching speed should be the one in blocking state).

Notes Related to Each Edit
EDIT 1: Upgrade to Hex went fine (6.40rc25 to rc36), now to start configuring MST on it. The first hitch in my giddy-up is how to safely perform the cut-over on the MikroTik, with a single link to the MikroTik through Cisco 2960-S stack that is now MST and speaking PVST to the hex. I cannot do a reload into so it will have to be a cut and pray or add a second path to the MikroTik so I can meddle with the primary.

EDIT 2: I'm taking a break for a bit, I'm not seeing a way to configure MST instances yet and I'm thinking that is causing some odd effects when I try to configure VLANs that are part of a separate MST instance within a region (VLANs 11,41,42,999 for me). SOLVED - nod to FIPTech for pointing out /interface bridge msti

EDIT 3: I'm back at it. I added a second link to the hex from the switch running MSTP so I can work without losing connection all the time. The ports for the new interface have higher port-id's (eth4 and gi 2/0/1) than the main trunk using legacy bridging (eth2, gi 1/0/1). Hopefully this will help when spanning-tree converges to keep some VLANs up.

EDIT 4: With a point in the right direction I've been able to configure MSTP instances 1 and 2 to match my Cisco configuration. I've updated the "In the MikroTik" portion to show the commands. It seems to see the root bridge ID but it only captures it under "regional-root-bridge-id" and nothing under "root-bridge-id":
[admin@rtr1] > interface bridge msti monitor 1
                    state: enabled
      current-mac-address: 6C:3B:6B:AF:FE:DB
              root-bridge: no
           root-bridge-id: 0.00:00:00:00:00:00
  regional-root-bridge-id: 0x3002.8C:B6:4F:20:21:80
           root-path-cost: 0
                root-port: eth4
               port-count: 1
    designated-port-count: 0
Questions to MikroTik
How do I see blocking state of interfaces from spanning-tree? Would they show as "disabled" when using /interface print?

Below you'll see I've added a second port to the MST Cisco 2960-S from the hex. In this case I've used eth4 and eth5. I'd expect eth5 to be the unused path on the hex side. A root bridge can't have disabled ports.
[admin@rtr1] > interface bridge port print where bridge=br-master1
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                  BRIDGE                 HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     eth4                       br-master1             yes    1     0x80         10                 10       none
 1     eth5                       br-master1             yes    1     0x80         10                 10       none
 
[admin@rtr1] > interface bridge msti print 
Flags: X - disabled 
 #   BRIDGE                                                                        IDENTIFIER PRIORITY VLAN-MAPPING
 0   br-master1                                                                             1   0x8000 11          
                                                                                                       999         
 1   br-master1                                                                             2   0x8000 41-42       
[admin@rtr1] >  
[admin@rtr1] > 
[admin@rtr1] > interface bridge msti monitor 0
                    state: enabled
      current-mac-address: 6C:3B:6B:AF:FE:DB
              root-bridge: no
           root-bridge-id: 0.00:00:00:00:00:00
  regional-root-bridge-id: 0x3001.8C:B6:4F:20:21:80
           root-path-cost: 0
                root-port: eth4
               port-count: 2
    designated-port-count: 0

[admin@rtr1] > interface bridge msti monitor 1
                    state: enabled
      current-mac-address: 6C:3B:6B:AF:FE:DB
              root-bridge: no
           root-bridge-id: 0.00:00:00:00:00:00
  regional-root-bridge-id: 0x3002.8C:B6:4F:20:21:80
           root-path-cost: 0
                root-port: eth4
               port-count: 2
    designated-port-count: 0
Last edited by idlemind on Mon Jul 10, 2017 12:57 am, edited 9 times in total.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 7:41 pm

I roll back to the previous rc,
Until I figure out how to set up vlan and trunk on crs

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

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 7:57 pm

I roll back to the previous rc,
Until I figure out how to set up vlan and trunk on crs

Enviado de meu XT1580 usando Tapatalk
^^ I can't speak for the CRS as I don't have it but I'm learning as I go right now.

It seems to be:
/interface bridge add name=my-new-bridge
/interface bridge vlan add bridge=my-new-bridge vlan-ids=1,2,3,4,5,6,7 untagged=ether2
^^ What I'm not sure about is what VLAN-ID is mapped to the un-tagged interface, is it always VLAN1? What happens to VLAN-IDs in the list of VLAN-IDS but not in "tagged"

You can create ping-able SVI's (routing) like:
/interface vlan add name=my-new-bridge-vl2 interface=my-new-bridge vlan-id=2
/ip address add interface=my-new-bridge-vl2 address=10.1.2.21/24
^^ Whether that is the way MikroTik envisioned it or not it has at least got me pinging.
Last edited by idlemind on Sat Jul 08, 2017 10:06 pm, edited 1 time in total.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 8:28 pm

@idlemind

Thanks, by maybe this config is for the router side, I will give a try later.

As I using crs as a switch only , don't make sense that configuration, it will make useless the switch menu on crs


Enviado de meu XT1580 usando Tapatalk
 
Lakis
Forum Veteran
Forum Veteran
Posts: 703
Joined: Wed Sep 23, 2009 7:52 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 8:46 pm

"Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) "

What about bonding? How bridge will use switch-chip?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 10:05 pm

@idlemind

Thanks, by maybe this config is for the router side, I will give a try later.

As I using crs as a switch only , don't make sense that configuration, it will make useless the switch menu on crs


Enviado de meu XT1580 usando Tapatalk
If your CRS is running RouterOS then this would work. The point of MikroTik doing this is to remove the switch specific configurations. They are working to provide a single way to configure VLANs and RouterOS will do what is necessary to use hardware features away from the user.

If you're using SwOS then I can't speak to what their plans are and this RC would be irrelevant anyways.
 
IntrusDave
Forum Guru
Forum Guru
Posts: 1286
Joined: Fri May 09, 2014 4:36 am
Location: Rancho Cucamonga, CA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 10:57 pm

dynamic firewall address-list items are not being removed when they expire.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 11:14 pm

dynamic firewall address-list items are not being removed when they expire.
yes, i found myself blocked strangely by anti bruteforce rules...
 
vikibhai
just joined
Posts: 19
Joined: Mon Sep 08, 2014 7:44 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 08, 2017 11:20 pm

IN TORCH... not show any trafic on pppoe client interface..
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 12:32 am

bridge ports :

point-to-point=auto detection does not seem to work. Duplex links (most frequent case) should be detected as point-to-point links.

half duplex links (connected to a hub for example) should be considered shared links.

from :

http://www.cisco.com/c/en/us/support/do ... html#anc11

"STP Link Type

RSTP can only achieve rapid transition to the forwarding state on edge ports and on point-to-point links. The link type is automatically derived from the duplex mode of a port. A port that operates in full-duplex is assumed to be point-to-point, while a half-duplex port is considered as a shared port by default. This automatic link type setting can be overridden by explicit configuration. In switched networks today, most links operate in full-duplex mode and are treated as point-to-point links by RSTP. This makes them candidates for rapid transition to the forwarding state."

On a Procurve switch, link type (PtP=yes) correctly detected :

| Prio | Designated Hello
Port Type | Cost rity State | Bridge Time PtP Edge
---- --------- + --------- ---- ---------- + ------------- ---- --- ----
1 100/1000T | 200000 128 Forwarding | 002561-e33e80 2 Yes Yes
2 100/1000T | 200000 128 Forwarding | 002561-e33e80 2 Yes Yes
3 100/1000T | Auto 128 Disabled |
4 100/1000T | 20000 128 Forwarding | 002561-e33e80 2 Yes Yes
5 100/1000T | 200000 128 Blocking | 002561-e33e80 2 Yes No
6 100/1000T | 2000000 128 Forwarding | 002561-e33e80 2 Yes Yes
7 100/1000T | Auto 128 Disabled |
8 100/1000T | 20000 128 Forwarding | 002561-e33e80 2 Yes Yes
9 100/1000T | 20000 128 Forwarding | 002561-e33e80 2 Yes Yes
10 100/1000T | 20000 128 Forwarding | 002561-e33e80 2 Yes Yes
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 12:08 pm

After updating a CHR from 6.40rc28 to 6.40rc36 the /export file contains this:
/interface ethernet
set [ find default-name=ether2 ] name=ether1
set [ find default-name=ether1 ] name=ether2
But this is not reflected in the active configuration.
After doing another reboot, this issue is gone.
I have experienced a similar issue in the past on a CCR, and have seen others reporting it.
(/interface ethernet section that suddenly appears to swap all interface names to other interfaces, but not really happening)
Please fix this, as it is very worrying when it happens to a router on a remote site.
 
IntrusDave
Forum Guru
Forum Guru
Posts: 1286
Joined: Fri May 09, 2014 4:36 am
Location: Rancho Cucamonga, CA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 12:18 pm

I have a MAC conflict
/interface ethernet
set [ find default-name=ether5 ] mac-address=64:D1:54:CF:04:3B
set [ find default-name=ether11 ] speed=1Gbps
set [ find default-name=ether12 ] name=ether12-IoT
set [ find default-name=ether13 ] name=ether13-WAN
[djoyce@Intrus_AltaLoma] /interface ethernet> print
Flags: X - disabled, R - running, S - slave 
 #    NAME                                    MTU MAC-ADDRESS       ARP             MASTER-PORT                                 SWITCH                                          
 2 RS ether3                                 1500 64:D1:54:CF:04:3A enabled         none                                        switch1                               
 3 RS ether4                                 1500 64:D1:54:CF:04:3B enabled         none                                        switch1                               
 4 RS ether5                                 1500 64:D1:54:CF:04:3B enabled         none                                        switch1                               
 5 RS ether6                                 1500 64:D1:54:CF:04:3D enabled         none                                        switch2                               
 
before this RC, ether5 was 64:D1:54:CF:04:3C. I can't get it to change back
 
andriys
Forum Guru
Forum Guru
Posts: 1526
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 12:30 pm

before this RC, ether5 was 64:D1:54:CF:04:3C. I can't get it to change back
Does /interface ethernet reset-mac-address ether5 command fail?
 
amokkatmt
newbie
Posts: 33
Joined: Mon Oct 24, 2011 3:31 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 2:22 pm

I have rb2011 with 2 to 5 ports in master-slave relations via "master-port". Also I had switch filter rule to limit broadcast packets to 5th port of this group flowing from other ports in this group (I have wifi access point on this 5th port and significant broadcasts on other ports). What should I do now with these new changes about discontinuing master-port? I tried to set up bridge and bridge filter rules, but after adding a rule I lost "fast path". What to do? And yes, switch rule is in place and not working, broadcasts are forwarded to 5th port:

add dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip ports=ether2-sv,ether3,ether4 switch=switch1 new-dst-ports=ether2-sv,ether3,ether4,switch1-cpu

Master is ether2, and 3-5 are slaves.
Ok, I tried this upgrade again. Before the upgrade I had disabled bridge from some old experiments or config. Bridge had only one port ether2. Mikrotik has some script inside this new version, which converts master-slave into bridge. Script took that bridge and placed other ports that was in master-slave into that bridge and enabled it.
If I remember it right, I deleted that not needed bridge, recreated it with new name. And of course I did not set "hw=yes" to the ports, didn't know how. because it is new feature etc.etc. Abscence of knowledge.
Second try after downgrade and restore from backup. I deleted that disabled bridge and upgraded. Now script created new "bridge1" and places master-slave ports into it.
My switch rule is working fine now.

To sum this up I was confused why my disabled bridge becomes enabled, deleted it and created new one without hw=true.

I think it will be better, if conversion script will not touch existing bridges and will create a new one to not confuse people. Or at least write a note to community what will be done.
 
sid5632
Long time Member
Long time Member
Posts: 552
Joined: Fri Feb 17, 2017 6:05 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 2:55 pm

!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (undocumented, CLI only);
Quite how you expect anybody to be able to understand or test this in any meaningful way (and thus provide meaningful feedback), without any documentation whatsoever, is beyond me.
Last edited by sid5632 on Sun Jul 09, 2017 7:42 pm, edited 1 time in total.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 3:21 pm

I have rb2011 with 2 to 5 ports in master-slave relations via "master-port". Also I had switch filter rule to limit broadcast packets to 5th port of this group flowing from other ports in this group (I have wifi access point on this 5th port and significant broadcasts on other ports). What should I do now with these new changes about discontinuing master-port? I tried to set up bridge and bridge filter rules, but after adding a rule I lost "fast path". What to do? And yes, switch rule is in place and not working, broadcasts are forwarded to 5th port:

add dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip ports=ether2-sv,ether3,ether4 switch=switch1 new-dst-ports=ether2-sv,ether3,ether4,switch1-cpu

Master is ether2, and 3-5 are slaves.
Ok, I tried this upgrade again. Before the upgrade I had disabled bridge from some old experiments or config. Bridge had only one port ether2. Mikrotik has some script inside this new version, which converts master-slave into bridge. Script took that bridge and placed other ports that was in master-slave into that bridge and enabled it.
If I remember it right, I deleted that not needed bridge, recreated it with new name. And of course I did not set "hw=yes" to the ports, didn't know how. because it is new feature etc.etc. Abscence of knowledge.
Second try after downgrade and restore from backup. I deleted that disabled bridge and upgraded. Now script created new "bridge1" and places master-slave ports into it.
My switch rule is working fine now.

To sum this up I was confused why my disabled bridge becomes enabled, deleted it and created new one without hw=true.

I think it will be better, if conversion script will not touch existing bridges and will create a new one to not confuse people. Or at least write a note to community what will be done.
hw=true is the default when you add new ports to a bridge. So your problem did not come from here i think.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 3:40 pm

!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (undocumented, CLI only);
Quite how you expect anybody to be able to understand or test this in any meanigful way (and thus provide meaningful feedback), without any documentation whatsoever, is beyond me.
That's true, specially for bridges, where at least two important things did change : vlan filtering and the new software / hardware bridge with hw=yes default port option.

This mean that the old school bridge with VLAN interface on it sharing the same MAC address should disappear if i'm right, to keep only the more modern bridging technic where each VLAN need a dedicated bridge with its own address. I did use almost exclusively the second technic, but this is still confusing for peoples and badly documented. The good point is that the new bridge with hw=yes default and vlan filtering possibility will restrict the use of the old shool bridge. So things should become clearer.

The problem here is that there is not only no documentation for new functions, but no serious documentation as well for the switch chip functions. Hopefully this will change soon.

After reading the Qualcomm Atheros QCA8337 chip datasheet (364 pages !), there is no doubt that the switch chip features we can see inside Router OS is a small subset of what the chip can do. The wiki page about this is minimalist and not enough to setup the switch chip seriously. And not enough for testing it.

I wrote recently a post about the switch chip, with a lot of questions. Nobody did answer, this show that very few people are mastering this part of Mikrotik hardware, probably because the lack of documentation.

viewtopic.php?f=2&t=122608&p=603147#p603147
 
w0lt
Long time Member
Long time Member
Posts: 537
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 6:23 pm

!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (undocumented, CLI only);
Quite how you expect anybody to be able to understand or test this in any meanigful way (and thus provide meaningful feedback), without any documentation whatsoever, is beyond me.
Well said !!! :shock:
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 6:27 pm

!) bridge - implemented software based MSTP (untested, undocumented, CLI only);
!) switch - "master-port" conversion into a bridge with hardware offload "hw" option (undocumented, CLI only);
Quite how you expect anybody to be able to understand or test this in any meanigful way (and thus provide meaningful feedback), without any documentation whatsoever, is beyond me.
Well said !!! :shock:
I too think documentation is a good thing. You gave to remember this is the RC thread. From the development perspective they probably wanted te feature out in the wild over the weekend. I imagine and expect MikroTik to work with the community to create and update the documentation as we move towards GA of 6.40.

TLDR; keep calm have a beer while you fiddle and hack the new implementation. I'm sure when MikroTik is back to work tomorrow we'll get updates from them.
 
gtj
Member Candidate
Member Candidate
Posts: 121
Joined: Thu Apr 30, 2015 2:52 am
Location: Colorado US

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 6:50 pm

Tested upgrade (not new features) on...
CCR1009, 2xCRS226, RB922UAGS-5HPacT, RB Metal 2SHPn, RB493G

All went OK except for the 1st CRS226. That switch was configured as a dumb switch. No bridges, all ports switched, 2 VLANS with the mgmt IP address on one of the ports. not the master as it turns out. After the upgrade I lost all contact with the switch including mac-telnet, romon, etc. The only way back was to do a reset. After getting basic connectivity back, I restored the backup and after the reboot I got connectivity and saw the new bridge created. Everything else was intact. The 2nd CRS was configured the same way but before the upgrade, I created a bridge myself, assigned the mgmt ip address to it and added the master port to it. It then upgraded fine.

I also ran a bandwidth test from the CCR to the RB493G through one of the CRSs to make sure that I was getting wire speed through the CRS switch chip even with all ports having their master port set to none. I was. CPU utilization on the CRS remained about 5%.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 6:57 pm

w.r.t. the new bridge implementation, it would be interesting to see a couple of config exports (ethernet interfaces, switch configuration and bridge configuration) as they are before and after the installation of this RC, preferably for some non-trivial configurations as well. maybe some of the early adopters can post these exports and report about success/failure of that specific case.

Here is an example for a simple 5-port model (750) converted from switch to new bridge:
< 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 bridge
> add admin-mac=D4:CA:6D:D6:6E:C3 auto-mac=no igmp-snooping=no name=bridge1 \
>     protocol-mode=none
20a23,27
> /interface bridge port
> add bridge=bridge1 interface=ether3
> add bridge=bridge1 interface=ether4
> add bridge=bridge1 interface=ether5
> add bridge=bridge1 interface=ether2
Looking at a verbose export it has "hw=yes" for the bridge port configs.
Last edited by pe1chl on Sun Jul 09, 2017 9:28 pm, edited 1 time in total.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Sun Jul 09, 2017 7:05 pm

Tested upgrade (not new features) on...
CCR1009, 2xCRS226, RB922UAGS-5HPacT, RB Metal 2SHPn, RB493G

All went OK except for the 1st CRS226. That switch was configured as a dumb switch. No bridges, all ports switched, 2 VLANS with the mgmt IP address on one of the ports. not the master as it turns out. After the upgrade I lost all contact with the switch including mac-telnet, romon, etc. The only way back was to do a reset. After getting basic connectivity back, I restored the backup and after the reboot I got connectivity and saw the new bridge created. Everything else was intact. The 2nd CRS was configured the same way but before the upgrade, I created a bridge myself, assigned the mgmt ip address to it and added the master port to it. It then upgraded fine.

I also ran a bandwidth test from the CCR to the RB493G through one of the CRSs to make sure that I was getting wire speed through the CRS switch chip even with all ports having their master port set to none. I was. CPU utilization on the CRS remained about 5%.
Hi
@gtj
Can you post your config?

I have a 450g as router
Crs 125 as layer 2 switch with vlan 2-8,99,210,220 using the switch menu
But I can't figure out how to set up vlan on new config mode.


Enviado de meu XT1580 usando Tapatalk
 
IntrusDave
Forum Guru
Forum Guru
Posts: 1286
Joined: Fri May 09, 2014 4:36 am
Location: Rancho Cucamonga, CA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 7:13 pm

before this RC, ether5 was 64:D1:54:CF:04:3C. I can't get it to change back
Does /interface ethernet reset-mac-address ether5 command fail?

I does not fail, but it does not do anything at all.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 9:25 pm

EDIT 2: I'm taking a break for a bit, I'm not seeing a way to configure MST instances yet
Is it what your are looking for ?
[admin@MikroTik] /interface bridge msti> print detail
Flags: X - disabled 
 0   identifier=5 bridge=bridge3 priority=0x6400 vlan-mapping=4060 
[admin@MikroTik] /interface bridge msti> 
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 9:30 pm

EDIT 2: I'm taking a break for a bit, I'm not seeing a way to configure MST instances yet
Is it what your are looking for ?
[admin@MikroTik] /interface bridge msti> print detail
Flags: X - disabled 
 0   identifier=5 bridge=bridge3 priority=0x6400 vlan-mapping=4060
[admin@MikroTik] /interface bridge msti> 
FIPTech I think that's it. I was outside working on the garden until I just checked my phone. I'll check lab later tonight and let you know. That said, I'm pretty sure it is. Not sure how I missed that sub menu lol.

Edit: FIPTech, I was able to add my instances and now seems to be good to go. I'm really not certain if state is shared between the legacy bridging method and the new method. I likely have a loop on my current testing VLAN of 42. We'll see though. I may have to get brave and cut-over the other VLANs now that I seem to have a functional configuration.
Last edited by idlemind on Mon Jul 10, 2017 12:49 am, edited 1 time in total.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 9:49 pm

I've seen this after changing STP mode or changing STP priority. Disappear after router reset :

Root bridge ID :
0x8000.00:00:00:00:00:00

The mac address should be the one of the admin-mac address of the bridge : 00:3C:97...

This address is really sent in BPDUs, can be seen on a connected procurve switch.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 10:12 pm

Seems like there is a problem with msti bridge ID (mac address is wrong) :
[admin@MikroTik] /interface bridge msti> monitor 0
                    state: enabled
      current-mac-address: 00:00:00:00:00:00
              root-bridge: yes
           root-bridge-id: 0x6005.00:00:00:00:00:00
  regional-root-bridge-id: 0x6005.00:00:00:00:00:00
           root-path-cost: 0
                root-port: none
               port-count: 2
    designated-port-count: 0
Should be the mac address of the bridge.

Does not work better after reboot. Perhaps it is because i've used an admin-mac address on the bridge ?
 
dobrozhanskyi
just joined
Posts: 2
Joined: Sun Jul 09, 2017 11:39 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sun Jul 09, 2017 11:41 pm

I am try
/tool fetch  url=(https://api.telegram.org/botXXX/sendMessagechat_id=YYY&text=test) check-certificate=no keep-result=no mode=https
and receive error:
failure: invalid URL protocol
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 12:46 am

I am try
/tool fetch  url=(https://api.telegram.org/botXXX/sendMessagechat_id=YYY&text=test) check-certificate=no keep-result=no mode=https
and receive error:
failure: invalid URL protocol
Syntax is not correct i think.

Try this :
/tool fetch url="https://api.telegram.org/botxxx/sendMessage\?chat_id=yyy&text=Bonjour" keep-result=no 
 
gtj
Member Candidate
Member Candidate
Posts: 121
Joined: Thu Apr 30, 2015 2:52 am
Location: Colorado US

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 2:17 am

***WARNING*** Attempting to disable or delete a bridge port corresponding to a switched port will will render the device inaccessible!! Only a reboot will bring it back. Happens on my CCR1009 and CRS226's.
 
gtj
Member Candidate
Member Candidate
Posts: 121
Joined: Thu Apr 30, 2015 2:52 am
Location: Colorado US

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

Mon Jul 10, 2017 2:20 am

Hi
@gtj
Can you post your config?

I have a 450g as router
Crs 125 as layer 2 switch with vlan 2-8,99,210,220 using the switch menu
But I can't figure out how to set up vlan on new config mode.
As far as I can tell, there's no difference. You still use the switch menu to manage VLANs just as before.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Mon Jul 10, 2017 2:20 am

***WARNING*** Attempting to disable or delete a bridge port corresponding to a switched port will will render the device inaccessible!! Only a reboot will bring it back. Happens on my CCR1009 and CRS226's.
What you mean for switched port

Enviado de meu XT1580 usando Tapatalk
 
gtj
Member Candidate
Member Candidate
Posts: 121
Joined: Thu Apr 30, 2015 2:52 am
Location: Colorado US

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

Mon Jul 10, 2017 2:21 am

***WARNING*** Attempting to disable or delete a bridge port corresponding to a switched port will will render the device inaccessible!! Only a reboot will bring it back. Happens on my CCR1009 and CRS226's.
What you mean for switched port

Enviado de meu XT1580 usando Tapatalk
A port that is connected to the switch chip. For the CRSs, it's all of them. For the CCR1009, it's ports 1-4.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Mon Jul 10, 2017 2:54 am

Hi
@gtj
Can you post your config?

I have a 450g as router
Crs 125 as layer 2 switch with vlan 2-8,99,210,220 using the switch menu
But I can't figure out how to set up vlan on new config mode.
As far as I can tell, there's no difference. You still use the switch menu to manage VLANs just as before.
Hmm,
After the upgrade I can't made the vlan and trunk to work
Since 2 to 22 was slave for 23 so then became a part of Bridge
After this i lost the vlan trunking to my rb450
Any tip?

Crs :
My trunk ports is 19,22,23
My vlan id 2-8 distributed on access port 2 to 8


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

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 5:22 am

Good news!
Will bridge on MT7621 have hw offloaded vlans?
So far in my testing the hw=on flag has been set by default for my hex w/MT7621. Not sure if it going to cause functionality issues. I'd imagine the software is smart-enough to only enable hardware support if it's warranted.
 
John39
just joined
Posts: 21
Joined: Mon Aug 08, 2016 11:17 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 9:23 am

After updating to version 6.40rc36 I observe the blinking display on RB2011UiAS
https://drive.google.com/open?id=0B6LPC ... S1lSU5ja0k
 
jtl
just joined
Posts: 6
Joined: Wed Aug 24, 2016 7:04 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 9:33 am

After updating to version 6.40rc36 I observe the blinking display on RB2011UiAS
https://drive.google.com/open?id=0B6LPC ... S1lSU5ja0k
Looks like something that can almost cause a seizure or headache. Luckily I don't have that anymore. :D
 
jtl
just joined
Posts: 6
Joined: Wed Aug 24, 2016 7:04 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 9:35 am

"Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) "

What about bonding? How bridge will use switch-chip?
Yes. And IP source guard of some sort?
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 11:03 am

For starters, here is clarification about bridge hardware offloading:
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
Information about the new bridge VLAN implementation is coming next.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 1:20 pm

RB750G (Atheros 8316 supported switch chip) : hw-offload does not seem to work :
[admin@MikroTik] /interface bridge port> print detail
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 0     interface=VLAN-LAB-Ether2 bridge=bridge3 priority=0x80 path-cost=10 internal-path-cost=10 edge=auto point-to-point=auto external-fdb=auto horizon=none hw=yes 
       auto-isolate=no restricted-role=no restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no 
[admin@MikroTik] /interface bridge> print detail
Flags: X - disabled, R - running 
 0 R name="bridge3" mtu=auto actual-mtu=1500 l2mtu=1516 arp=enabled arp-timeout=auto mac-address=00:0C:42:70:13:66 protocol-mode=none fast-forward=yes igmp-snooping=no 
     priority=0x9000 auto-mac=yes admin-mac=02:3C:97:6D:89:E1 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m region-name="002561e33e80" 
     region-revision=0 max-hops=20 vlan-filtering=no pvid=1 
Edit 1 : ok i did find the problem : VLAN interfaces added inside the bridge do not get hw-offload enabled.

How to get hw-offload working for tagged traffic ?
[admin@MikroTik] /interface bridge port> print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                            BRIDGE                                            HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     VLAN-LAB-Ether2                                      bridge3                                           yes    1     0x80         10                 10       none
 1 I H ether5                                               bridge1                                           yes    1     0x80         10                 10       none
 2 I   vlan1                                                bridge1                                           yes    1     0x80         10                 10       none
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 2:00 pm

On RB750G [AR8316] to keep hw-offload enabled with VLANs, they have to be configured in "/interface ethernet switch" menu.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 3:37 pm

On RB750G [AR8316] to keep hw-offload enabled with VLANs, they have to be configured in "/interface ethernet switch" menu.
Isn't this supposed to be all automatic in the future versions? What I read in the initial announcement was that all switch configuration would
be migrated into bridge configuration where the hw offloading to switch features would be done as far as possible. That would be great, as
the existing situation with bridge and switch (especially with added STP support) was becoming more and more confusing for newcomers.
To really solve that, it would be best if "switch" configuration would disappear entirely from user view.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 3:44 pm

On RB750G [AR8316] to keep hw-offload enabled with VLANs, they have to be configured in "/interface ethernet switch" menu.
Isn't this supposed to be all automatic in the future versions? What I read in the initial announcement was that all switch configuration would
be migrated into bridge configuration where the hw offloading to switch features would be done as far as possible. That would be great, as
the existing situation with bridge and switch (especially with added STP support) was becoming more and more confusing for newcomers.
To really solve that, it would be best if "switch" configuration would disappear entirely from user view.
Yup, this was the impression I got to and what I was excited about. Tbh the "switch chip" configurations were way to hard. Cisco shows how to do it right with trunk and access ports or routed interfaces with sub-interfaces. The important thing is the 2 methods they use are consistent and have been present for a very long time. This reduces complexity and abstracts any kind of acceleration away from the user.

If I wanted a switch that needs to be configured differently for each model I would buy HP (truly a reason they don't come to mind as a valid product for access switching when I talk to my customers). This is also the reason I use software bridging with MikroTik's and why I don't use the models that would act as a switch in my environments. It's hard enough to learn all the different technologies and a configuration for them. It's simply stupid to learn something like VLAN switching per model whether it has to do with hardware acceleration or not.

Again, I was ecstatic with this RC not only because of MSTP but because of the VLAN aware bridges and the indication that HW offload would be managed by RouterOS. This puts you in the position someone like Cisco is in. Easy and consistent to configure across your platforms for layer 2.

TLDR; consistency breeds confidence and confidence brings hardware sales.

Now a question:

It sounds like you're working on this but can we get an example of the best way to configure an "access port, untagged traffic only for a specific VLAN present on the bridge" and a "trunk port, tagged traffic for specific VLANs on a bridge with the option to not use VLAN1 as the native VLAN"? (If this isn't possible then I need to stay with software based PVST driven single bridge per VLAN to give me control equal to what is found on a Cisco switch purchased off of eBay).
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 4:43 pm

We can now make two bridges in the same switch group. For example (RB750G) :

Ether2 and Ether3 -> bridge1

Ether4 and Ether5 -> bridge2

Ether2 to Ether5 are in the same hardware switch group.


Does it mean that there is full level2 isolation between the two bridges ? Or not ?

How is it managed internally (i mean witch switch rules are used to do that ?)

Why don't we see dynamic switch rules appear when creating a software bridge with hw-offload ?

According to what i'm seeing inside /interface/bridge/port, only a single "software" brige can have hw-offload enabled. The other software bridges, if they are in the same hardware switch group, cannot get hw-offload.

Another point : inside /interface/bridge/vlan, we can see vlan interfaces added to the bridge if vlan-filtering is enabled (current-untagged).
[admin@MikroTik] /interface bridge vlan> print detail
Flags: X - disabled, D - dynamic 
 0 D bridge=bridge3 vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=bridge3,VLAN-LAB-Ether2
This is confusing. Why a vlan interface do appear as untagged ? Because it is untagged inside the bridge i suppose. But if this is for this reason, why is there a current-tagged field ?
Regardless what i do i see nothing inside "current-tagged"

Edit 1 : I was able to get something here adding a vlan using /interface/bridge/vlan> add bridge=bridge3 tagged=VLAN-LAB-Ether2 vlan-ids=65-68,70

There is no documentation available for those new settings.

Edit 2 :
I suppose that adding VLAN-Ids to a vlan-filtered bridge do allow tagged traffic to pass through (but nothing more) ?

What does vlan-filtering exactly ? Where is the filter ? Inside the software bridge ? Is it a hardware filter using switch rules ?

Something that is important and still valid for new bridges (from the wiki) :

Adding a vlan-interface as a bridge port remove the vlan tag (the bridge see the trafic as untagged).
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 5:32 pm

This puts you in the position someone like Cisco is in. Easy and consistent to configure across your platforms for layer 2.

TLDR; consistency breeds confidence and confidence brings hardware sales.
As soon as the GUI / Console gives a good understanding of the underlying technology, it's not a problem for me to have something slightly different compared to other manufacturers or even compared to previous hardware. Mikrotik is the right solution for cost (low cost hardware and free software updates).

Winbox is fast, easy to use, and can give you access to almost all functions. This is a big advantage over some other products, where you need the console as soon as you want to do something that is not hyper common. Or use a terrible HTML5 interface or even more terrible a buggy flash / java web interface to setup common things.

This said, i think that some things needs to be done at least in Winbox to understand how the new "vlan aware" software bridges do interact with vlans and with the hardware switch chips.

Actually it is too much confusing. More the switch chip is something very difficult to use, understand and test, so you are right its configuration should be fully automatic. And it would be very interesting to have dynamic items appearing inside switch port, switch VLAN rules, and switch rules, when something is changed in a software bridge with hw-offload.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 6:33 pm

For starters, here is clarification about bridge hardware offloading:
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading
Information about the new bridge VLAN implementation is coming next.
My MT7621 doesn't seem to shut off hw-offload correctly. If I'm assuming correctly, any VLAN actions should disable the hw-offload feature for that chipset. While the VLAN configuration options are present for the Ethernet switch in RouterOS they up until this point have never produced a functioning VLAN configuration in practice. Support ticket #2017032422000958 will confirm this behavior. You can configure it all day long on the hex but it simply won't work in practice. I'm guessing at least in rc36 I'll need to manually disable hw-offload until the detection has been fixed or this release now enables VLAN switching in hardware for the hex. Please clarify.
/interface bridge
add name=br-master1 protocol-mode=mstp region-name=pri-211 region-revision=1 vlan-filtering=yes

/interface bridge msti
add bridge=br-master1 identifier=1 vlan-mapping=11,999
add bridge=br-master1 identifier=2 vlan-mapping=41-42

/interface bridge port
add bridge=br-master1 interface=eth4
add bridge=br-master1 interface=eth5

/interface bridge vlan
add bridge=br-master1 tagged=eth4,eth5 vlan-ids=1,42

[admin@rtr1] > interface bridge port print where bridge=br-master1 
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                                           BRIDGE                                                          HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     eth4                                                                br-master1                                                      yes    1     0x80         10                 10       none
 1     eth5                                                                br-master1                                                      yes    1     0x80         10                 10       none
Also, please clarify where or how I would see port disabled to prevent a loop. I'd expect eth5 to be a backup port and disabled. This is because eth4 and eth5 both face the root bridge. The eth4 interface is selected as the root-port as expected. I just don't see where eth5 is disabled or set to inactive to prevent VLANs 1 and 42 from looping. Neither of the corresponding ports would be suspended on the root bridge side and aren't.
Last edited by idlemind on Mon Jul 10, 2017 7:37 pm, edited 1 time in total.
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 6:44 pm

Here is the article about new VLAN-aware bridge implementation:
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
A couple examples will be added and more information will be updated based on your feedback.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 6:47 pm

Here is the article about new VLAN-aware bridge implementation:
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
A couple examples will be added and more information will be updated based on your feedback.
+1 reading now.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 6:58 pm

Here is the article about new VLAN-aware bridge implementation:
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
A couple examples will be added and more information will be updated based on your feedback.
@becs
Fixed
On VLAN Example #2 (Trunk and Hybrid Ports) there is a port mismatch
/interface bridge vlan
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether3 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 untagged=ether4 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether5 vlan-ids=400
on CRS 125 the vlan on switch menu, i ignore / wipe up ?
Last edited by raffav on Mon Jul 10, 2017 8:51 pm, edited 1 time in total.
 
rkau045
newbie
Posts: 45
Joined: Mon Jun 25, 2012 9:14 pm

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

Mon Jul 10, 2017 7:41 pm

@becs
On VLAN Example #2 (Trunk and Hybrid Ports) there is a port mismatch
/interface bridge vlan
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether3 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 untagged=ether4 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether5 vlan-ids=400

on CRS 125 the vlan on switch menu, i ignore / wipe up ?
Seems right to me. Ether2 and ether8 are trunk ports for vlan 200, 300 and 400. Ether6 is trunk for vlan 300. Ether7 is trunk for vlan 200 and 400.
Ether3 is access port for vlan 200, ether4 is access port for vlan 300, ether5 is access port for vlan 400.

Sent from my LG-H910 using Tapatalk
Last edited by rkau045 on Mon Jul 10, 2017 7:41 pm, edited 2 times in total.
 
rkau045
newbie
Posts: 45
Joined: Mon Jun 25, 2012 9:14 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 7:44 pm

Removed
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Mon Jul 10, 2017 7:54 pm


Seems right to me. Ether2 and ether8 are trunk ports for vlan 200, 300 and 400. Ether6 is trunk for vlan 300. Ether7 is trunk for vlan 200 and 400.
Ether3 is access port for vlan 200, ether4 is access port for vlan 300, ether5 is access port for vlan 400.

Sent from my LG-H910 using Tapatalk
Is not,
The is no eth 3,4,5 on the example
It is 6,7,8

I only said that is wrong on example if someone copy and paste and not pay attention.


Enviado de meu XT1580 usando Tapatalk
 
nje431
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Tue Sep 10, 2013 5:17 pm

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

Mon Jul 10, 2017 7:56 pm

@becs
On VLAN Example #2 (Trunk and Hybrid Ports) there is a port mismatch
/interface bridge vlan
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether3 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 untagged=ether4 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether5 vlan-ids=400

on CRS 125 the vlan on switch menu, i ignore / wipe up ?
Seems right to me. Ether2 and ether8 are trunk ports for vlan 200, 300 and 400. Ether6 is trunk for vlan 300. Ether7 is trunk for vlan 200 and 400.
Ether3 is access port for vlan 200, ether4 is access port for vlan 300, ether5 is access port for vlan 400.

Sent from my LG-H910 using Tapatalk
I agree with raffav, it doesn't look right to me either.
 
rkau045
newbie
Posts: 45
Joined: Mon Jun 25, 2012 9:14 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 8:05 pm

I should have looked at the diagram before posting. You are correct. Sorry.

Sent from my LG-H910 using Tapatalk
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 8:31 pm

Here is the article about new VLAN-aware bridge implementation:
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
A couple examples will be added and more information will be updated based on your feedback.
Something is not clear to me for vlan-id=1, the default for PVID.

If using for example an hybrid port with PVID=1, getting tagged ingress traffic with vlan-id=1, and untagged ingress traffic at the same time.

Are both tagged and untagged traffic mixed ? How to keep untagged and tagged traffic split in this case, without assigning untagged traffic to a vlan-id different from 1 (using PVID=xxx) ?

The problem if reassigning untagged traffic to a VLAN-ID different from 1, is that it would need a vlan interface on the bridge to reach the bridge IP for example. This is not logical.


Another point is not clear :

We can suppose that PVID=1 send untagged ingress traffic with mac address of the bridge to the bridge "native" interface.

This mean that adding an IP to the bridge interface link this IP with untagged traffic.

I think that a small paragraph explaining how to add IP addresses to the bridge, for untagged and tagged traffic should be added.

In the end it is not clear to me why VLAN-ID=1 is used to send untagged traffic to the native bridge interface. VLAN-ID=0 for example would be easier to understand, because it would not conflict with authorized vlan-ids (1-4094).

VLAN 0 and 4095 are reserved vlan ids. But Vlan 0 is used when traffic needs to get assigned a priority and does not need to have a vlan-id. It could be treated as untagged traffic by switches.

So it seems logical to use vlan-id=0 internally to mark untagged traffic instead of using the conflicting (according to me) vlan-id=1 ?
 
qq4569712
just joined
Posts: 12
Joined: Sat May 07, 2011 10:24 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 10:08 pm

Currently RouterOS6.40rc does support any of EAP authentication methods?
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 10:31 pm

Here is the article about new VLAN-aware bridge implementation:
https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
A couple examples will be added and more information will be updated based on your feedback.
also, 'add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether8 vlan-ids=400' should be 'add bridge=bridge1 tagged=ether2,ether6,ether7 untagged=ether8 vlan-ids=400', I believe
 
User avatar
null31
Member Candidate
Member Candidate
Posts: 183
Joined: Fri Dec 23, 2016 6:07 pm
Location: Brazil

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 10:59 pm

Currently RouterOS6.40rc does support any of EAP authentication methods?
Yes, the below methods.

Image
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 11:14 pm

Can any one help my on my senario ?

i get a parcial to work
i will use cisco term to be more simples
on CRS
TRUNK
ETH 23 allow vlan 2,4,5,6,7,8,99,210,220
eth19 allow vlan 4,5,6,7,99
eth 22 allow vlan 210.220
Access
vlan 2 port 2=8

vlan 220 port 20


so i do something like that
/interface bridge port
add bridge=br-trunk1 interface=ether23
add bridge=br-trunk1 interface=ether19
add bridge=br-trunk1 interface=ether22
add bridge=br-trunk1 interface=ether2 pvid=2
add bridge=br-trunk1 interface=ether3 pvid=2
add bridge=br-trunk1 interface=ether4 pvid=2
add bridge=br-trunk1 interface=ether5 pvid=2
add bridge=br-trunk1 interface=ether6 pvid=2
add bridge=br-trunk1 interface=ether7 pvid=2
add bridge=br-trunk1 interface=ether8 pvid=2
add bridge=br-trunk1 interface=ether20 pvid=220

/interface bridge vlan
add bridge=br-trunk1 tagged=ether23 untagged=ether2,ether3,ether4,ether5,ether6,ether7,ether8 vlan-ids=2
add bridge=br-trunk1 tagged=ether19,ether23 vlan-ids=4,5,6,7,99
add bridge=br-trunk1 tagged=ether22,ether23 vlan-ids=210,220

 
huntah
Member Candidate
Member Candidate
Posts: 287
Joined: Tue Sep 09, 2008 3:24 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 11:27 pm

I think there is another mistake in VLAN Example #2 (Trunk and Hybrid Ports):
https://wiki.mikrotik.com/wiki/Manual:I ... d_Ports.29
/interface bridge vlan
add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether6 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 untagged=ether7 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether6,ether7 untagged=ether8 vlan-ids=400
Ether6 has taged 400 in Example but not in code. there it has ether8 :).. Correct code is above. Please correct the wiki.
So it seems logical to use vlan-id=0 internally to mark untagged traffic instead of using the conflicting (according to me) vlan-id=1 ?
Has the RouterOS behavior changed.. I havent tried it yes but this confusion has been discussed here:
viewtopic.php?f=2&t=115115&p=572377&hil ... +0#p572377
Different vendros use different approach to native VLAN..
 
brwainer
newbie
Posts: 47
Joined: Tue Feb 02, 2016 2:55 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 11:29 pm

also, 'add bridge=bridge1 tagged=ether2,ether7,ether8 untagged=ether8 vlan-ids=400' should be 'add bridge=bridge1 tagged=ether2,ether6,ether7 untagged=ether8 vlan-ids=400', I believe
For Example #2 I believe you are correct.
Can any one help my on my senario ?
vlan 220 port 20
/interface bridge vlan
add bridge=br-trunk1 tagged=ether23 untagged=ether2,ether3,ether4,ether5,ether6,ether7,ether8 vlan-ids=2
add bridge=br-trunk1 tagged=ether19,ether23 vlan-ids=4,5,6,7,99
add bridge=br-trunk1 tagged=ether22,ether23 vlan-ids=210,220
You are missing ether20 from the /interface vlan bridge section. Needs to be listed like
add bridge=br-trunk1 untagged=ether20 vlan-ids=220
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 10, 2017 11:36 pm


You are missing ether20 from the /interface vlan bridge section. Needs to be listed like
add bridge=br-trunk1 untagged=ether20 vlan-ids=220
that is the problem
it not 220
i my vlan 2 that not work
access


host print where !local
Flags: L - local, E - external-fdb
BRIDGE VID MAC-ADDRESS ON-INTERFACE AGE
br-trunk1 1 08:EB:74:44:0E:C0 ether6 50s
br-trunk1 1 4C:5E:0C:47:53:3E ether23 1s
br-trunk1 1 4C:5E:0C:7E:74:3F ether19 7s
br-trunk1 1 74:D4:35:B1:E4:FD ether4 4s
br-trunk1 2 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 3 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 4 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 5 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 6 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 6 4C:5E:0C:7E:74:3F ether19 0s
br-trunk1 7 18:83:BF:B5:EB:F1 ether19 6s
br-trunk1 7 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 7 4C:5E:0C:7E:74:3F ether19 0s
br-trunk1 7 90:B9:31:A1:C1:92 ether19 3s
br-trunk1 7 A4:77:33:FF:A8:94 ether19 5s
br-trunk1 99 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 99 4C:5E:0C:7E:74:3F ether19 0s
br-trunk1 210 4C:5E:0C:47:53:3E ether23 0s
br-trunk1 220 00:90:D0:63:FF:00 ether22 1m29s
br-trunk1 220 0C:A4:02:D5:9A:9C ether22 0s
br-trunk1 220 4C:5E:0C:47:53:3E ether23 1s
br-trunk1 220 84:8D:C7:21:E0:3D ether20 2s
Never mind
I forgot to add pvid on eth 4 and 6
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 12:26 am

Has the RouterOS behavior changed.. I havent tried it yes but this confusion has been discussed here:
viewtopic.php?f=2&t=115115&p=572377&hil ... +0#p572377
Different vendros use different approach to native VLAN..
Yes, but regardless what is used internally to mark untagged traffic, and regardless the induced confusion, it seems to me important that untagged traffic does not conflict with the use of tagged vlan1 (commonly used as the default vlan-id for the primary vlan inside switches).

I did not tried it yet with the new vlan aware bridge. With older bridge it was possible to use tagged vlan 1 and untagged without conflict.

Let's try that...
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 12:34 am

In my understanding native vlan is always untagged even on trunk port
On cisco is 1 by default


I used vlan 99 tagged to be my management vlan, but now on this new way I can't find
PS
My dot1q it is on my rb 450g where All vlan is set up on eth 2.
And management ip is set to vlan 99
But I can't ping it.


Enviado de meu XT1580 usando Tapatalk
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 12:53 am

frame-types and ingress-filtering do not appear inside bridge details :
[admin@MikroTik] /interface bridge> print detail
Flags: X - disabled, R - running 
 0 R ;;; defconf
     name="bridge" mtu=auto actual-mtu=1500 l2mtu=1520 arp=enabled arp-timeout=auto mac-address=00:0C:42:70:13:66 protocol-mode=none 
     fast-forward=yes igmp-snooping=no priority=0x8000 auto-mac=no admin-mac=00:0C:42:70:13:66 max-message-age=20s forward-delay=15s 
     transmit-hold-count=6 ageing-time=5m region-name="" region-revision=0 max-hops=20 vlan-filtering=yes pvid=1 
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 12:56 am

In my understanding native vlan is always untagged even on trunk port
On cisco is 1 by default


I used vlan 99 tagged to be my management vlan, but now on this new way I can't find
PS
My dot1q it is on my rb 450g where All vlan is set up on eth 2.
And management ip is set to vlan 99
But I can't ping it.


Enviado de meu XT1580 usando Tapatalk
Did you create a VLAN interface with the interface set to the VLAN aware bridge and a VLAN ID of 99 and assign the IP to the VLAN interface?
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Tue Jul 11, 2017 1:08 am

In my understanding native vlan is always untagged even on trunk port
On cisco is 1 by default


I used vlan 99 tagged to be my management vlan, but now on this new way I can't find
PS
My dot1q it is on my rb 450g where All vlan is set up on eth 2.
And management ip is set to vlan 99
But I can't ping it.


Enviado de meu XT1580 usando Tapatalk
Did you create a VLAN interface with the interface set to the VLAN aware bridge and a VLAN ID of 99 and assign the IP to the VLAN interface?

Yes
On both
Crs and 450
I set interfere vlan
Vlan id 99 on eth 23/2
And set ip on vlan
Just to be clear
Vlan it linked to eth and not to bridge

Enviado de meu XT1580 usando Tapatalk
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

Tue Jul 11, 2017 2:44 am

In my understanding native vlan is always untagged even on trunk port
On cisco is 1 by default


I used vlan 99 tagged to be my management vlan, but now on this new way I can't find
PS
My dot1q it is on my rb 450g where All vlan is set up on eth 2.
And management ip is set to vlan 99
But I can't ping it.


Enviado de meu XT1580 usando Tapatalk
Did you create a VLAN interface with the interface set to the VLAN aware bridge and a VLAN ID of 99 and assign the IP to the VLAN interface?

Yes
On both
Crs and 450
I set interfere vlan
Vlan id 99 on eth 23/2
And set ip on vlan
Just to be clear
Vlan it linked to eth and not to bridge

Enviado de meu XT1580 usando Tapatalk
If you are using the new vlan aware bridge method (vlan filtering), my understanding is that you should put your vlan interface on your bridge, not the physical port. And put your vlan99 management IP address on this interface.

It's working for me. Do not forget to add the vlan inside /interface/bridge/vlan and add the bridge in the tagged interface list. If not you will not be able to reach the bridge IP because when the vlan filter is enabled on the bridge, only untagged traffic get a dynamic vlan rule to pass traffic through the bridge (forward) and in/out of the bridge (input/ouput). For tagged traffic you need to add vlan rules in /interface/bridge/vlan

Do not forget that vlan interfaces you add on the bridge for management or DHCP servers need to be added in tagged interfaces list for each VLAN. If you put only physical ports, then you will not be able to reach IPs or send traffic from IPs of the bridge.

See the new wiki documentation to set vlans inside the bridge.

You should get something like this (here for a tagged vlan 300) :

The vlan setup for the bridge (you can see a dynamic rule, automatically created for untagged traffic through all the bridge ports :
[admin@MikroTik] /interface bridge vlan> print detail
Flags: X - disabled, D - dynamic 
 0   bridge=bridge vlan-ids=300 tagged=ether2,bridge untagged="" current-tagged=bridge,ether2 current-untagged="" 

 1 D bridge=bridge vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=bridge,ether3,ether2 
Here the vlan interface you need to add on the bridge :
[admin@MikroTik] /interface vlan> print detail
Flags: X - disabled, R - running, S - slave 
 0 R  name="VLAN-INVITE" mtu=1500 l2mtu=1516 mac-address=00:0C:42:70:13:66 arp=enabled arp-timeout=auto 
      loop-protect=default loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m 
      vlan-id=300 interface=bridge use-service-tag=no 
Here some IP address are dynamic because i get them through a dhcp client set on the interface.
I like to use dhcp for testing to see for example if there is no vlan mixing problems.
[admin@MikroTik] /ip address> print detail
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; defconf
     address=192.168.88.1/24 network=192.168.88.0 interface=bridge actual-interface=bridge 

 1 D address=192.168.88.10/24 network=192.168.88.0 interface=bridge actual-interface=bridge 

 2 D address=192.168.220.152/26 network=192.168.220.128 interface=VLAN-INVITE actual-interface=VLAN-INVITE 
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 3:26 am

I did some RSTP tests with a correct (i think) vlan aware bridge setup.

I was not able to get RSTP working correctly with an HP procurve 2520-8-G at the other side. Specially when Mikrotik (RB750G) is not the STP root.

Somebody did success ?
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 4:13 am

@FIPTech
thanks worked

one thing that maybe need to be more simple is the interface/ bri/ vlan you need to do a "Feng Shu" and logical to reconfigure if you want to add some vlan to tagged or untagged

this i my example

i need trunk on ether23 on tag all my vlan 2,4-7,99,210,220
trunk on ether19 tag only 4-7,99
trunk on ether22 tag only vlan 210,220

but also
i need that vlan 2 to be untagged on ether2-8
that vlan 220 to be untagged on ether20


that what i get for accomplished that.


> interface bridge vlan print detail terse
0 bridge=br-trunk1 vlan-ids=4,5,6,7,99 tagged=ether19,ether23,br-trunk1 untagged="" current-tagged=br-trunk1,ether23,ether19 current-untagged=""
1 bridge=br-trunk1 vlan-ids=210,220 tagged=ether22,ether23 untagged="" current-tagged=ether22,ether23 current-untagged=ether20
2 D bridge=br-trunk1 vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=ether22,ether23,br-trunk1,ether19
3 bridge=br-trunk1 vlan-ids=2 tagged=ether23 untagged=ether2,ether3,ether4,ether5,ether6,ether7,ether8 current-tagged=ether23 current-untagged=ether4,ether6,ether2
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 7:57 am

How can spanning tree port states be seen? (show spanning-tree equavelant)
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 9:01 am

How can spanning tree port states be seen? (show spanning-tree equavelant)
/interface bridge monitor bridge1

/interface bridge port monitor [find where bridge=bridge1]

/interface bridge msti monitor [find]
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 9:57 am

A couple problems seen during testing :

1) The new vlan aware bridge seems to broke ROMON function. I did loose ROMON router access after this problem did appear so i have no more information to share. This is to be confirmed, the root cause is perhaps another problem as i was testing RSTP. When i did loose ROMON access, IP and MAC access where broken too.

It is necessary i think to test ROMON with the new bridges to be sure it's working flawlessly.

2) After RB750G reset, there is a problem in the default config : the default IP address is set on the physical port instead of the bridge, so the router is not anymore accessible. I did use mac telnet to get access again.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 10:35 am

Any way to enable STP / RSTP / MSTP logging ?
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 11:16 am

Any way to enable STP / RSTP / MSTP logging ?
Currently, it is not supported.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 12:55 pm

I think i would be interesting to have an option inside Winbox to automatically create a vlan rule on a brige when adding a vlan interface to it.

This would create a vlan rule with the vlan id of the interface, including all bridge ports.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 2:17 pm

How can spanning tree port states be seen? (show spanning-tree equavelant)
/interface bridge monitor bridge1

/interface bridge port monitor [find where bridge=bridge1]

/interface bridge msti monitor [find]
Thanks becs
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Tue Jul 11, 2017 2:38 pm

I think i would be interesting to have an option inside Winbox to automatically create a vlan rule on a brige when adding a vlan interface to it.

This would create a vlan rule with the vlan id of the interface, including all bridge ports.
Agree but winbox isn't alway possible to use.

I still think that step need to be simplified


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

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 4:02 pm

How can spanning tree port states be seen? (show spanning-tree equavelant)
/interface bridge monitor bridge1

/interface bridge port monitor [find where bridge=bridge1]

/interface bridge msti monitor [find]
Thanks becs
Victory, I now feel confident enough to migrate some additional VLANs over now :)

Request: Could you make the priority able to be set and displayed as an integer?
[admin@rtr1] > interface bridge port monitor [ find where bridge=br-master1 ]
                   interface: eth4                     eth5
                      status: in-bridge                in-bridge
                 port-number: 1                        2
                        role: root-port                alternate-port
                   edge-port: no                       no
         edge-port-discovery: yes                      yes
         point-to-point-port: no                       no
                external-fdb: no                       no
                sending-rstp: yes                      yes
                    learning: yes                      no
                  forwarding: yes                      no
     internal-root-path-cost: 10                       10
           designated-bridge: 0x2000.8C:B6:4F:20:21:80 0x2000.8C:B6:4F:20:21:80
    designated-internal-cost: 0                        0
      designated-port-number: 57                       58
            multicast-router: no                       no
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

Tue Jul 11, 2017 4:32 pm

I think i would be interesting to have an option inside Winbox to automatically create a vlan rule on a brige when adding a vlan interface to it.

This would create a vlan rule with the vlan id of the interface, including all bridge ports.
Agree but winbox isn't alway possible to use.

I still think that step need to be simplified


Enviado de meu XT1580 usando Tapatalk
Another possibility would be to optionally create a default vlan rule for newly created bridges, allowing all tagged vlan-id on all ports of the bridge. If this does not trig a performance issue.

I tried to put such a rule, with vlan-ids 2-4094. This does not seem to rise the CPU %.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 4:41 pm

According to a simple test i've just done on a vlan aware bridge, it is not possible to use tagged vlan 1 and untagged traffic at the same time.

As soon as a bridge vlan rule is set with vlan-ids=1 and bridge ports added as tagged, Winbox connection (connected on the bridge untagged vlan IP) is lost.

This result seems to confirm what i felt yesterday : because of the internal vlan id = 1 used for untagged external traffic, It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.

The hardware switches i'm used to, (procurves) do allow to use untagged and tagged vlan=1 at the same time without any problem. More, vlan=1 is the default vlan vlan-id in those switches. This mean that it is not uncommon to see vlan 1 tagged inside an hybrid trunk, with untagged traffic from another vlan. In this case, it is not possible to connect such an hybrid trunk on a Mikrotik vlan aware bridge.

Please confirm. If i'm right this should be clearly stated in the documentation, or better, corrected in the code.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 5:09 pm

@FIPTech
i still don't underhand what is your point with vlan1 tag/untag and what you want to do
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 5:10 pm

It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.
you mean, untagged on some ports and tagged on others? or both untagged and tagged on the same port (schrodinger vlan)?..
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Tue Jul 11, 2017 5:54 pm

Another possibility would be to optionally create a default vlan rule for newly created bridges, allowing all tagged vlan-id on all ports of the bridge. If this does not trig a performance issue.

I tried to put such a rule, with vlan-ids 2-4094. This does not seem to rise the CPU %.
i think some like that
# This part you tell Mikrotik the port mode
/interface bridge port
add bridge=br-trunk1 interface=ether23 |\
add bridge=br-trunk1 interface=ether19 | TRUNK PORTS
add bridge=br-trunk1 interface=ether22 |/


add bridge=br-trunk1 interface=ether2 pvid=2 |\
add bridge=br-trunk1 interface=ether3 pvid=2 | \
add bridge=br-trunk1 interface=ether4 pvid=2 | \
add bridge=br-trunk1 interface=ether5 pvid=2 | \
add bridge=br-trunk1 interface=ether6 pvid=2 | \
add bridge=br-trunk1 interface=ether7 pvid=2 | \
add bridge=br-trunk1 interface=ether8 pvid=2 | ACCESS PORTS
add bridge=br-trunk1 interface=ether17 pvid=2 | /
add bridge=br-trunk1 interface=ether18 pvid=2 | /
add bridge=br-trunk1 interface=ether14 pvid=4 | /
add bridge=br-trunk1 interface=ether15 pvid=5 | /
add bridge=br-trunk1 interface=ether17 pvid=2 | /
add bridge=br-trunk1 interface=ether20 pvid=220|/




/interface bridge vlan
## Make Mikrotik smart enough to understand that vlans belong to the same bridge
# Tell that on eth is allowed only this tagged vlan
add bridge=br-trunk1 interface=ether23 tagged-vlan-ids=2,4,5,6,7,99,210,220

# Tell that on eth is allowed only this tagged vlan
add bridge=br-trunk1 interface=ether19 tagged-vlan-ids=4,5,6,7,99

# Tell that on eth is allowed only this tagged vlan
add bridge=br-trunk1 interface=ether22 tagged-vlan-ids=210,220
#----------------------------------
# a Hybrid mode e.g
add bridge=br-trunk1 interface=ether22 tagged-vlan-ids=210,220 utagged-vlan-ids=2
Last edited by raffav on Tue Jul 11, 2017 5:58 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 6:05 pm

It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.
you mean, untagged on some ports and tagged on others? or both untagged and tagged on the same port (schrodinger vlan)?..
I think he means "have vlan 1 tagged on some port, and at the same time have some other vlan untagged on that or another port".

While vlan 1 is nothing special, it would not be the first case where it causes problems to use it tagged. In the past I have
also tried to hunt down bugs on other manufacturer's switches, and even faced the situation where the manuf "could not reproduce"
the problem and it was because the Windows driver for the ethernetcard he uses to debug the problem (or maybe even Windows itself)
invisibly deleted a VLAN 1 tag from the packet even before wireshark gets it. Wireshark under Linux showed the problem clearly.

I think in a complex VLAN scenario with tagged/untagged use, one simply should not use VLAN 1 or not use it for something important.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 6:13 pm

According to a simple test i've just done on a vlan aware bridge, it is not possible to use tagged vlan 1 and untagged traffic at the same time.

As soon as a bridge vlan rule is set with vlan-ids=1 and bridge ports added as tagged, Winbox connection (connected on the bridge untagged vlan IP) is lost.

This result seems to confirm what i felt yesterday : because of the internal vlan id = 1 used for untagged external traffic, It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.

The hardware switches i'm used to, (procurves) do allow to use untagged and tagged vlan=1 at the same time without any problem. More, vlan=1 is the default vlan vlan-id in those switches. This mean that it is not uncommon to see vlan 1 tagged inside an hybrid trunk, with untagged traffic from another vlan. In this case, it is not possible to connect such an hybrid trunk on a Mikrotik vlan aware bridge.

Please confirm. If i'm right this should be clearly stated in the documentation, or better, corrected in the code.
FIPTech, I'm not following you. I just did a test with 2 MikroTik's and 2 Cisco routers in GNS3. I used the new VLAN aware bridges with the PVID set to 1. I added an IP directly to the bridge. I setup the link between the MIkroTik's to send traffic untagged for VLAN1 and the Cisco routers to tag VLAN1 with an IP on that sub-interface.

This creates a situation where VLAN1 is untagged on the MikroTik's and tagged on the link to the Cisco devices. It all works fine and as expected you can see the tag applied out of the Cisco router into the MikroTik and then the tag is popped on it's way to the second MikroTik.

Now, you do have to tell the Cisco device what VLAN to assign untagged traffic to, in my case I picked 999 (random). You can't have untagged and tagged traffic on the same physical interface for the same VLAN. Think a trunk link, you have to set a native/untagged VLAN (1 by default) and you have to assign the VLANs that are tagged. Also, Cisco allows you tag all traffic including the default VLAN (a best practice similar to configuring a non-routable native) this just tells the Cisco switch to tag the default VLAN and drop any untagged packets. The take-away is you don't have a single interface with untagged and tagged packets on it. I can't speak for HP but if they are doing that it would seem like a loop or VLAN hop point to me.

Diagram (can't post images in this thread)

(m1) MikroTik Connected to c1 Cisco Router and m2 MikroTik
/interface bridge
add name=br-master1 protocol-mode=stp vlan-filtering=yes
/interface bridge port
add bridge=br-master1 interface=ether4
add bridge=br-master1 interface=ether1
add bridge=br-master1 interface=ether2
/interface bridge vlan
add bridge=br-master1 untagged=ether1,ether2 vlan-ids=999
add bridge=br-master1 tagged=ether1,ether2 vlan-ids=1

/ip address
add address=192.168.1.11/24 interface=br-master1 network=192.168.1.0
(m2) MikroTik connected only to m1 MikroTik
/interface bridge
add name=br-master1 protocol-mode=stp vlan-filtering=yes
/interface bridge port
add bridge=br-master1 interface=ether4

/ip address
add address=192.168.1.21/24 interface=br-master1 network=192.168.1.0
(c1) Cisco router config
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/0.1
 encapsulation dot1Q 1
 ip address 192.168.1.31 255.255.255.0
!
interface FastEthernet0/0.999
 encapsulation dot1Q 999 native
Success
c1#ping 192.168.1.21 repeat 4

Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 192.168.1.21, timeout is 2 seconds:
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 4/9/20 ms
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 6:31 pm

I think in a complex VLAN scenario with tagged/untagged use, one simply should not use VLAN 1 or not use it for something important.
^^ Exactly the reason I create and use VLAN999 on all of my switch to switch (or VLAN speaking router) links as the untagged VLAN. I also ensure that no IP addressing is ever applied to VLAN999. This is 1 of 2 recommended approaches for dealing with VLAN hopping. The other is to tag all traffic including the native VLAN. This method is less common and essentially discards any untagged traffic (in a similar fashion as having it on a non-routable VLAN).
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 6:41 pm

I think in a complex VLAN scenario with tagged/untagged use, one simply should not use VLAN 1 or not use it for something important.
^^ Exactly the reason I create and use VLAN999 on all of my switch to switch (or VLAN speaking router) links as the untagged VLAN. I also ensure that no IP addressing is ever applied to VLAN999. This is 1 of 2 recommended approaches for dealing with VLAN hopping. The other is to tag all traffic including the native VLAN. This method is less common and essentially discards any untagged traffic (in a similar fashion as having it on a non-routable VLAN).
exactly
"native vlan" is most comum used to management and a good practice is to move the native to another vlan id
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 9:50 pm

It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.
you mean, untagged on some ports and tagged on others? or both untagged and tagged on the same port (schrodinger vlan)?..
I think he means "have vlan 1 tagged on some port, and at the same time have some other vlan untagged on that or another port".

While vlan 1 is nothing special, it would not be the first case where it causes problems to use it tagged. In the past I have
also tried to hunt down bugs on other manufacturer's switches, and even faced the situation where the manuf "could not reproduce"
the problem and it was because the Windows driver for the ethernetcard he uses to debug the problem (or maybe even Windows itself)
invisibly deleted a VLAN 1 tag from the packet even before wireshark gets it. Wireshark under Linux showed the problem clearly.

I think in a complex VLAN scenario with tagged/untagged use, one simply should not use VLAN 1 or not use it for something important.
Yes, i mean put on the same trunk (hybrid) untagged traffic and tagged VLAN 1. This is not working with vlan aware bridges (except if you are using "PVID=something else than 1" to change the untagged traffic vlan-id).

Because vlan 0 is reserved, or used for priority when no specific vlan is necessary (normally considered as untagged by switches), it should be safer to use internally vlan-id=0 for untagged traffic.

This should remove the conflict between untagged and tagged vlan1.

Here is the dynamic vlan rule added for untagged traffic when you create a bridge :
1 D bridge=bridge vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=bridge,ether2
You can see here that if you add a tagged vlan with vlan-id=1, it will conflict with untagged traffic.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 9:55 pm

It is not possible to use untagged and tagged vlan-id=1 traffic at the same time.
you mean, untagged on some ports and tagged on others? or both untagged and tagged on the same port (schrodinger vlan)?..
I think he means "have vlan 1 tagged on some port, and at the same time have some other vlan untagged on that or another port".

While vlan 1 is nothing special, it would not be the first case where it causes problems to use it tagged. In the past I have
also tried to hunt down bugs on other manufacturer's switches, and even faced the situation where the manuf "could not reproduce"
the problem and it was because the Windows driver for the ethernetcard he uses to debug the problem (or maybe even Windows itself)
invisibly deleted a VLAN 1 tag from the packet even before wireshark gets it. Wireshark under Linux showed the problem clearly.

I think in a complex VLAN scenario with tagged/untagged use, one simply should not use VLAN 1 or not use it for something important.
Yes, i mean put on the same trunk (hybrid) untagged traffic and tagged VLAN 1. This is not working with vlan aware bridges (except if you are using "PVID=something else than 1" to change the untagged traffic vlan-id).

Because vlan 0 is reserved, or used for priority when no specific vlan is necessary (normally considered as untagged by switches), it should be safer to use internally vlan-id=0 for untagged traffic.

This should remove the conflict between untagged and tagged vlan1.

Here is the dynamic vlan rule added for untagged traffic when you create a bridge :
1 D bridge=bridge vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=bridge,ether2
You can see here that if you add a tagged vlan with vlan-id=1, it will conflict with untagged traffic.

I've used vlan1 tagged mixed with untagged traffic without problems in the past with procurve switches as well as Mikrotiks.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 10:18 pm

Ya, I don't get why you'd want to do that. At the very least it would tell the switch to duplicate all traffic.

Say I have 2 MikroTiks, m1 and m2. They are connected by a single Ethernet connection, say ether1 on each. You literally want all untagged traffic to be treated as VLAN1 as well as tagging any VLAN1 traffic over that same link? At the very, very least you'd be sending all traffic that traverses that link for VLAN1 twice and likely in the old per VLAN STP bridges it was likely shutting one of the 2 paths off or ignoring the traffic from the underlying bridge by nature. Neither produce a best practices view in my personally opinion.

Now, you can take the same MikroTik's, m1 and m2. They could be connected by two Ethernet connections, say ether1 to ether1 and ether2 to ether2. For the ether1 connection VLAN1 could be untagged and ether2 it could be tagged and it wouldn't cause any problem.

All in all, we may not be understanding what you are trying to accomplish. I don't think there is any valid reason to remove untagged traffic mapping to PVID1 by default and assigning the IP for VLAN1 to the bridge. I'd simply reconfigure any offending switch (if the HPs do this well, 1 I'm not surprised and 2 setup the port to work appropriately). The same behavior is exhibited by other network hardware and I think the assumption comes from the IEEE dubbing VLAN1 the default VLAN which translates well to humans as untagged traffic by default.

Just my 0.02.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 11:28 pm

I've used vlan1 tagged mixed with untagged traffic without problems in the past with procurve switches as well as Mikrotiks.
I agree with you that it should work and indeed it does work on Procurve (I have such a scenario at work) but before that we had
switches from another manufacturer (no longer on the market, but its name started with a digit) and they behaved very curiously.

So, especially when setting up a new network, I would not recommend that setup. Either keep VLAN 1 untagged or use some other
VLAN number, as others already wrote. In the meantime, hope that MikroTik fixes it.

For an interesting time, configure a switch with multiple VLAN, with a hybrid port (VLAN 1 untagged and VLAN 2 and 3 tagged),
then configure monitoring of that port (mirroring to another port) and watch how the untagged VLAN appears on that port.
Look at both ingress and egress traffic for the untagged VLAN 1. Use a Linux box to watch it.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 11, 2017 11:52 pm

Are you able to dump a configuration from the ProCurve's showing a single port untagged for VLAN1 and tagged for VLAN1? I'd be extremely surprised if that is the case as well as confused as to how that isn't at the least causing the link to bridge traffic twice if not forming a loop.

I know this is wandering dangerously off-topic of the actual content of the RC release so we may need to take it to a new thread. I can create one. At this point I'm more curious as to how something like that would actually work. I'm pretty sure what you're describing is definitely not standard behavior. The Cisco switches and routers I have in my lab won't let me do it. I don't have any ProCurve hardware to lab with, largely because they fall into the each model is configured differently category and that annoys me (at least since the 3com purchase).
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 1:24 am

Are you able to dump a configuration from the ProCurve's showing a single port untagged for VLAN1 and tagged for VLAN1? I'd be extremely surprised if that is the case as well as confused as to how that isn't at the least causing the link to bridge traffic twice if not forming a loop.

I know this is wandering dangerously off-topic of the actual content of the RC release so we may need to take it to a new thread. I can create one. At this point I'm more curious as to how something like that would actually work. I'm pretty sure what you're describing is definitely not standard behavior. The Cisco switches and routers I have in my lab won't let me do it. I don't have any ProCurve hardware to lab with, largely because they fall into the each model is configured differently category and that annoys me (at least since the 3com purchase).
No you are right tagged for vlan1 and untagged for vlan1 at the same time on the same port is not possible.
But it is definitely possible to have tagged vlan 1 on a port, and untagged vlan 1 on other ports.

With a Ros vlan aware bridge, untagged traffic goes (default situation) to vlan 1. But if you create a vlan interface on the bridge with vlan-id=1, it does not seem possible to get tagged traffic on it.

This is the problem. I can't understand why untagged traffic is assigned vlan 1. Untagged by default should go to the native bridge interface (this is the case actually), but should not steal vlan-id=1 so that we can use tagged traffic with vlan-id=1. untagged should use a special vlan marker internally, not in the range 1-4094. 0 should be possible i think, or something else out of the normal vlan range.
I've just make a try that is confirming a not working vlan1 vlan interface on the bridge.

In short, with the default untagged vlan-id=1 assignation, it is not possible to bridge a tagged traffic with vlan-id=1 isolated from the untagged traffic.

This vlan rule, dynamically created, show that :
 1 D bridge=bridge vlan-ids=1 tagged="" untagged="" current-tagged="" current-untagged=bridge,ether2
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 3:33 am

... and migration complete. I'm switched over to RouterOS doing MSTP with 1 of my Cisco switches and inter-VLAN routing. The hex is also talking plain STP (fallback) with another one of my Cisco switches so I have redundant uplinks. The hex is also doing inter-VLAN routing. All of my VLANs are dual-stack (IPv4/6) without any problems so far.

Now ... to do some speed tests and eventually try adding a WLAN or virtual AP interface in as a bridge port to ensure that works. Right now my lab WiFi is provided by an OpenWRT TP-Link.
 
sparker
just joined
Posts: 23
Joined: Mon Jan 23, 2012 5:48 pm
Location: Russia / Chelyabinsk

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 8:02 am

Can show a simple example of the configuration of the MSTP between the three MikroTik permissible?
 
becs
MikroTik Support
MikroTik Support
Posts: 499
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 12:36 pm

Here is a simple MSTP configuration example for insight. It could be used on 3 routers connected in a ring.
#1) Create a bridge with ports:

/interface bridge
add name=bridge1 protocol-mode=none vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2

#2) Configure VLANs:

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1,ether2 untagged="" vlan-ids=10
add bridge=bridge1 tagged=bridge1,ether1,ether2 untagged="" vlan-ids=20
add bridge=bridge1 tagged=bridge1,ether1,ether2 untagged="" vlan-ids=30
add bridge=bridge1 tagged=bridge1,ether1,ether2 untagged="" vlan-ids=40

#3) Assign VLANs to MST instances:

/interface bridge msti
add bridge=bridge1 identifier=1 vlan-mapping=10,20
add bridge=bridge1 identifier=2 vlan-mapping=30,40

#4) Enable VLAN Filtering and MSTP:

/interface bridge set bridge1 protocol-mode=mstp vlan-filtering=yes

#5) Check MSTP status:

/interface bridge msti monitor [find]
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1616
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 12:53 pm

Version 6.40rc38 has been released.

Important note!!! Backup before upgrade!
RouterOS v6.40rc36 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.40rc release:
*) certificate - update and reload old certificate with new one if SKID matches;
*) email - added support for multiple attachments;
*) firewall - added "none-dynamic" and "none-static" options for "address-list-timeout" parameter;
*) firewall - fixed crash on fasttrack dummy rule manual change attempt;
*) ikev2 - fixed duplicate policy checking with "0.0.0.0/0" policies;
*) lte - added initial fastpath support (except SXT LTE and Sierra modems);
*) mmips - added support for NVME disks;
*) ppp - added output values for "info" command for finding the GSM base station's location ("LAC" and "IMSI");
*) ppp - fixed "user-command" output;
*) quickset - simplified LTE status monitoring;
*) rb1100ahx4 - fixed startup problems (requires additional reboot after upgrade);
*) ssl - added Wildcard support for "left-most" DNS label (will allow to use signed Wildcard certificate on VPN servers);
*) userman - do not send disconnect request for user when "simultaneous session limit reached";
*) userman - added "/tool user-manager user clear-profiles" command;

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.
 
John39
just joined
Posts: 21
Joined: Mon Aug 08, 2016 11:17 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 1:52 pm

The new update does not solve the problem I described earlier
viewtopic.php?f=21&t=123335&start=50#p607285
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1616
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 2:32 pm

John39 - There are no related fixes mentioned in chagelog. Have you contacted support@mikrotik.com? Are you sure that problem was introduced in 6.40rc version and downgrade to older version fixes this problem?
 
SPKA16
newbie
Posts: 29
Joined: Fri Aug 05, 2016 8:41 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 2:45 pm

*) lte - added initial fastpath support (except SXT LTE and Sierra modems);
Any updates when we can expect fastpath support for PPPoE Client interfaces?
 
andriys
Forum Guru
Forum Guru
Posts: 1526
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 3:06 pm

Any updates when we can expect fastpath support for PPPoE Client interfaces?
It is supported since 6.35. And there also were improvements in 6.39. Check changelogs out for details.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1135
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 3:10 pm

Any updates when we can expect fastpath support for PPPoE Client interfaces?
It is supported since 6.35. And there also were improvements in 6.39. Check changelogs out for details.
It doesn't work on RB850Gx2.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1616
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 4:03 pm

Please take a look at list of supported router models:
https://wiki.mikrotik.com/wiki/Manual:Fast_Path

Also please note that this topic is created for discussions related to 6.40rc release. Please create new topics for unrelated questions or write directly to support@mikrotik.com
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1764
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 4:19 pm

It doesn't work on RB850Gx2.
RB850Gx2 Ethernets doesn't have fastpath support, MT doesn't have their own driver there, they use ones provided by CPU manufactures so that IPsec hardware acceleration works. I asked about this at the MUM.
 
John39
just joined
Posts: 21
Joined: Mon Aug 08, 2016 11:17 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 4:34 pm

John39 - There are no related fixes mentioned in chagelog. Have you contacted support@mikrotik.com? Are you sure that problem was introduced in 6.40rc version and downgrade to older version fixes this problem?
No.I thought this problem can be solved on the forum.
John39 - There are no related fixes mentioned in chagelog. Have you contacted support@mikrotik.com? Are you sure that problem was introduced in 6.40rc version and downgrade to older version fixes this problem?
Yes, I'm sure the upgrade to version 6.39.2 or earlier fixes this problem.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 6:43 pm

*) mmips - added support for NVME disks;

what possible current mmips based router has slot/interface to get an nvme ssd attached to it? afaik nvme is pcie, and the hexR3 (the sole mmips based mikrotik device) doesn’t have anything similar...
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 8:10 pm

*) mmips - added support for NVME disks;
what possible current mmips based router has slot/interface to get an nvme ssd attached to it?
Preparing for the future: viewtopic.php?f=2&t=121533
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 12, 2017 11:36 pm

@ Mikrotik Staff

using CRS125-24G-1S-2HnD is better/more performace
using this new way or keep using the switch menu
for trunk/access vlan ?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 1:30 am

I'm noticing with 6.40rc36 on a hex (gr3) traffic that has to pass from my wired network (cisco switches) to my wireless side (openwrt) begins to get roughly 50% packet loss after ~6 hours. It happened overnight into this morning and now again at the end of the day. The OpenWRT AP is running Chaos Calmer and connected to an "access" port of a new VLAN aware bridge running MSTP.
interface bridge vlan print 
Flags: X - disabled, D - dynamic 
 #   BRIDGE                                                               VLAN-IDS  CURRENT-TAGGED                                                              CURRENT-UNTAGGED                                                             
 0   br1                                                                  1         eth2                                                                        br1                                                                          
                                                                                    eth3                                                                       
 1   br1                                                                  11        br1                                                                         eth4                                                                         
                                                                                    eth2                                                                       
                                                                                    eth3                                                                       
 2   br1                                                                  12        br1                                                                        
                                                                                    eth2                                                                       
                                                                                    eth3                                                                       
 3   br1                                                                  41        br1                                                                        
                                                                                    eth2                                                                       
                                                                                    eth3                                                                       
 4   br1                                                                  42        br1                                                                        
                                                                                    eth2                                                                       
                                                                                    eth3                                                                       
 5   br1                                                                  999       br1                                                                         eth2                                                                         
                                                                                                                                                                eth3
As soon as I reboot the OpenWRT router it begins to act normally again, this ran fine with the original software bridges for several months without ever doing this. I'll be upgrading to rc38 tonight yet but I don't expect it to fix it.

^^ EDIT 1: Ignore this, I'm pretty sure this was a bad AP. I replaced it with a cap lite and it's been working great since. Just a very random time for the AP to have problems I think.
Last edited by idlemind on Fri Jul 14, 2017 6:05 pm, edited 2 times in total.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 2:56 am

@ Support
it not first time that this happens
Image
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1764
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 7:12 am

*) mmips - added support for NVME disks;

what possible current mmips based router has slot/interface to get an nvme ssd attached to it? afaik nvme is pcie, and the hexR3 (the sole mmips based mikrotik device) doesn’t have anything similar...
Maybe M33 ??
https://mum.mikrotik.com/presentations/EU17/2017-eu.pdf
second to last slide
 
sparker
just joined
Posts: 23
Joined: Mon Jan 23, 2012 5:48 pm
Location: Russia / Chelyabinsk

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 7:20 am

Here is a simple MSTP configuration example for insight. It could be used on 3 routers connected in a ring.
Many thanks!
 
User avatar
null31
Member Candidate
Member Candidate
Posts: 183
Joined: Fri Dec 23, 2016 6:07 pm
Location: Brazil

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 8:19 am

I upgraded the CHR to rc38 from rc36.
No firewall rules, no bridges and no master-ports configured before the upgrade.
I have only the dude server running there.

Is this error normal after the reboot to upgrade?

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

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 10:40 am

null31 - Do not worry. This message should not appear on CHR. We will fix this in upcoming releases and get rid of unrelated error message after upgrade.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2095
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 2:40 pm

*) mmips - added support for NVME disks;

what possible current mmips based router has slot/interface to get an nvme ssd attached to it? afaik nvme is pcie, and the hexR3 (the sole mmips based mikrotik device) doesn’t have anything similar...
The upcoming RouterBoard M3 has a M.2 slot which could be used for a NVMe SSD....
 
blingblouw
Member
Member
Posts: 345
Joined: Wed Aug 25, 2010 9:43 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 4:22 pm

*) mmips - added support for NVME disks;

what possible current mmips based router has slot/interface to get an nvme ssd attached to it? afaik nvme is pcie, and the hexR3 (the sole mmips based mikrotik device) doesn’t have anything similar...
The upcoming RouterBoard M3 has a M.2 slot which could be used for a NVMe SSD....

What is this?
 
User avatar
null31
Member Candidate
Member Candidate
Posts: 183
Joined: Fri Dec 23, 2016 6:07 pm
Location: Brazil

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 13, 2017 5:09 pm

 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 14, 2017 12:10 am

IMPORTANT INFORMATION ON 6.40RC38
Yes, everything that saves to file from console is broken, export to file print to file etc. We will try to fix this in future rc versions.
viewtopic.php?f=1&t=123497#p607883

In the current RC (6.40RC38) or since the new bridge setup instead of master-slave ports I get a big drop in speed on PPPoE after an few hours. Under heavy load but with fastracking then one of the four cores goes to 100% on upload and download about it is 85%. The last core is mostly used.

When doing the speedtest I got with (pre-RC36) Master-Slave directly the maximum download speed, with the Bridge there is a build-up to normal speed. So it burst-ed well over 700Mbit/s and dropped to 235Mbit/s and now it is maximum 200Mbit/s after the build-up.

Update: this morning after 8 uptime of the PPPoE, the speeds are still as they should be so I will check later today how the speed are.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 14, 2017 2:28 pm

Not getting happier about this and I had to revert back current 39.2 to have my settings back. The backups I have all say "provide password" and I what am think WHAT password!!!! I tired many but none did work so that means all my carefully made backups are toast or is there some way to use them. The export .rsc are all trowing errors so that is also a no go.

This sets me back a few months in changes made in firewall and a lot of scripting I did in that time. I cant even go back to 6.40rc38 because of I have only the .backup and no .rsc.

Is there a reliable way to backup you settings so one can restore their router in case of disaster?

So back ot Bridge and Master. The load on the cores are with master more even and none is stressed to the utmost.

With bridge I have 100% on core four and with Master I have maximum 67% on one of the cores on upload.

I wanted to show two pictures showing the difference in speed but I can't find the attach option any more. So bad luck all the way.
Last edited by msatter on Fri Jul 14, 2017 2:53 pm, edited 1 time in total.
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

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

Fri Jul 14, 2017 2:36 pm

Not getting happier about this and I had to revert back current 39.2 to have my settings back. The backups I have all say "provide password" and I what am think WHAT password!!!! I tired many but none did work so that means all my carefully made backups are toast or is there some way to use them. The export .rsc are all trowing errors so that is also a no go.

This sets me back a few months in changes made in firewall and a lot of scripting I did in that time. I cant even go back to 6.40rc38 because of I have only the .backup and no .rsc.

Is there a reliable way to backup you settings so one can restore their router in case of disaster?

So back ot Bridge and Master. The load on the cores are with master more even and none is stressed to the utmost.

I wanted to show two pictures showing the difference in speed but I can't find the attach option any more. So bad luck all the way.
When you press the backup button on winbox is encrypted by default, if you don't set up password you locked out,you lost the backup.. [emoji30]
2 options
Check don't the box to don't set password or put a password on


Enviado de meu XT1580 usando Tapatalk
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Fri Jul 14, 2017 2:43 pm

Got lucky and could revert to 6.40rc32 and use the backup that I so carefully made......YEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH

So I am back to a situation of only seven day's ago and I am happy there.

I thinking now that it is more to it. I did try before to restore that same backup in the process.
It seems that I have to go first to pre-RC and than back to upgrading to the RC of which I have the backup.

I don't want try to restore the backup of 6.40rc38 because of the bridge behavior.
 
imanewbie
just joined
Posts: 1
Joined: Wed Nov 02, 2016 4:29 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 15, 2017 6:23 pm

Unable to export configuration to a file

Is anyone else having this issue? I can run /export from the CLI, but if I do:

/export file=x (or /export file="x")

No files get created.

I'm trying on both a CCR1016-12G and on a hAP ac.

Thanks,
Tom
 
Zaffo
just joined
Posts: 3
Joined: Tue Jun 27, 2017 7:52 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 15, 2017 8:16 pm

Unable to export configuration to a file
(...)
Tom
Known issue. See viewtopic.php?f=1&t=123497#p607883

I ran into this myself today while trying out the new bridge implementation, took me a sec to remember I had read something about it. Does anyone know if there is a list of known issues kept somewhere we can see it?
 
User avatar
boldsuck
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Sun Sep 01, 2013 1:07 am
Location: Germany

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 15, 2017 10:20 pm

Unable to export configuration to a file

Is anyone else having this issue? I can run /export from the CLI, but if I do:

/export file=x (or /export file="x")

No files get created.
I had the same problem yesterday. RB2011UAS
:-? I thought I was too stupid to find the file.

ISSUE since rc38
Webfig:
No File download possible
ftp download is OK
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Sat Jul 15, 2017 10:27 pm

Give it a rest. It is known at Mikrotik and they will fix it before the final version...I assume.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 2:52 pm

WinBox: in IP -> Neighbours it says 'UPtime'. Should be 'Uptime', I believe
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 4:34 pm

Unable to export configuration to a file

Is anyone else having this issue? I can run /export from the CLI, but if I do:

/export file=x (or /export file="x")

No files get created.
I had the same problem yesterday. RB2011UAS
:-? I thought I was too stupid to find the file.

ISSUE since rc38
Webfig:
No File download possible
ftp download is OK
It seems that it was corrected by rc41 as in Changelog of RouterOS 6.40rc41.
It applied by CCR 1009 and confirmed.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 5:22 pm

Speaking of rc41 ... No announcment on the forums yet.

Most curiously:

!) bridge hw-offload implementation reverted back to pre-6.40rc36 state (testing will continue in v6.41rc);

^^ MikroTik, what does this mean for rc38 to rc41? Will our bridge configs be mangled or useless? Will the become full software based VLAN aware bridges?
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 5:30 pm

No more IGMP Snooping? :(
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 6:31 pm

v6.40 is scheduled for release, so we reverted hw-offload as well as igmp-snooping, because it requires more testing and bugfixes.
Most likely it will be back in v6.41rc
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 7:06 pm

Does that mean that "master port" functionality will remain? Or will everything still be converted to bridges but now without hw offload and IGMP snooping?
 
upower3
Member
Member
Posts: 425
Joined: Thu May 07, 2015 11:46 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 7:34 pm

There is one interesting line in CHANGES for 6.40.rc42:
*) pppoe-server - fixed situation when some of 100+ pppoe-servers can become invalid on reboot;
Is it possible to know since which version this bug exists? 6.39 is vulnerable or not, for CCR1009?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 9:08 pm

v6.40 is scheduled for release, so we reverted hw-offload as well as igmp-snooping, because it requires more testing and bugfixes.
Most likely it will be back in v6.41rc
I'll keep on 6.40rc38 until 6.41rc hits the downloads then. Can't say i'm interested in reverting my new VLAN aware bridges back to the old way and then back again into VLAN aware bridges. Good progress. Don't fall asleep at the wheel. I hope you guys got some good initial testing on MSTP / VLAN ware bridging.
 
User avatar
Xymox
Member
Member
Posts: 416
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 9:53 pm

Well... That was fun... hahahaha..

Not exactly sure what happened on my CCR, it seemed fine at first.. My bridges seemed fine. I have no master/slave ports.. That was last nite.. This morning I wake up and things are astray.. I have a DNS server and its TX port on ethernet seems to have nothing coming from it. Ive hooked it to a few devices. So something in a Linux server has gone astray - really odd timing if its unrelated.. The CCR is still working I just changed to a external DNS to bypass the server and all is well. Im going to look at the server shortly.

I moved back to the stable release during troubleshooting on the CCR.

When i read the warning about backing up, I decided to copy over to a partition before doing anything. You guys should recommend that more often. Its a great reason to have partitions. I have not flipped back yet, but, I think I will as going from 38 to 41 who knows...

Now the more interesting router was the 2011UiAS-2HnD ... While that seemed to work ok and I did not notice any obvious networking issues, the display light was now tied to port one activity light. So the display was going on/off with the activity light.. SOrta "Help me ! Im in trouble here !"... haha..

Your beta's are normally pretty much like stable releases. So im sure to a lot of people this might have been alarming to have issues with a beta. BUT. I found your beta procedures really great. Your WARNED EVERYBODY - DO A BACKUP -.. In my case I READ the release notes before pushing the button. So I grabbed EVERYTHING off each router and then set a partition before running the beta.. SO for me these were ZERO issues when things got weird.

Not sure any of the above really helps with the beta test, but I try and give feedback when on a beta and something goes astray.
Last edited by Xymox on Mon Jul 17, 2017 10:11 pm, edited 1 time in total.
 
User avatar
Xymox
Member
Member
Posts: 416
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 9:59 pm

Everybody using RC's should also be using partitions. This makes for instant fall back and no worries.
 
User avatar
Xymox
Member
Member
Posts: 416
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Mon Jul 17, 2017 11:41 pm

Hmmm.. Did I see the routerboard firmware go from 3.33 to 3.39 during that someplace ? Maybe I have just not checked in a while. It would be a lot more annoying to have to fact reset it to get back to its factory 3.18 and then update firmware and then restore settings from a export/import.

Hopefully 3.39 in routerboard firmware is OK to use with 6.40.RC21 ? or 6.39.2 ?

I saw a lot of weird things occur on my network. I cant say they are related, but, ive never had anything go wacky in 6 months and then everything went wacky at the same time I did 6.40RC38..Then 41..

That was a pretty weird set of events. Im back on 6.39.2 on the 2011 and 6.40.RC21 on the CCR. These were my last stable partitions.

Maybe cuz it was monday ?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 1:59 am

I confirmed w/6.40rc41 the VLAN aware bridges are reverted. I did not test what happens when they are reverted when upgrading from 6.40rc38 to 6.40rc41. Also, odd to have such limited communication on the release from MikroTik.

When can we expect to see 6.40 announced and 6.41rc started back with the VLAN aware implementation.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26291
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 8:59 am

What's new in 6.40rc41 (2017-Jul-17 09:03):
!) bridge hw-offload implementation reverted back to pre-6.40rc36 state (testing will continue in v6.41rc);
!) wireless - added Nv2 AP synchronization feature "nv2-modes" and "nv2-sync-secret" option;
*) bonding - fixed 802.3ad mode on RB1100AHx4;
*) export - fixed export to a file (introduced in v6.40rc39);
*) hotspot - added "address-list" support in "walled-garden" IP section;
*) hotspot - fixed firewall accept rules created by "/ip hotspot walled garden ip" (introduced in v6.40rc18);
*) ike1 - create tunnel policy when no split net provided;
*) ike1 - wait for cfg set reply before ph2 creation with xAuth;
*) ipsec - allow to specify chain in "firewall" peer option;
*) ppp - fixed non-standard PAP or CHAP packet handling;
*) pppoe-server - fixed situation when some of 100+ pppoe-servers can become invalid on reboot;
*) routerboard - added "caps-mode" option for "reset-configuration";
*) sfp - fixed invalid temperature reporting when ambient temperature is less than 0;
*) winbox - make IPSec policies table an order list;
*) winbox - show "/interface wireless cap print" warnings;
Important: This means all the new bridge/switch/igmp-snooping functionality is removed and will return in 6.41rc. The reason is that we found that these new features need more testing, and v6.40 was too close to release, so it would delay the release for some time. Those of you who used the RC, there is no painless way to upgrade or downgrade.

The choices are:
1) reconfigure and repair by hand
2) wait until 6.41RC
 
User avatar
Xymox
Member
Member
Posts: 416
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 11:46 am

This was very easy to roll back with a partition. Just make the partition active that was right before the upgrade. Took seconds.. As I mentioned, everyone doing RCs should use partitions. I copy my current RC and config over to a partition before I try out a new RC. Any issue, I just move back..

I had to with 38, upgraded to 41. On the 2011 it was still causing the display to flash. So 41 did not fix something from 38. So I "made active" my original partition and the issue was gone.

I really think Mikrotik should discuss using partitions in addition to backups.
 
expert
Frequent Visitor
Frequent Visitor
Posts: 97
Joined: Sun Dec 04, 2016 1:22 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 12:16 pm

I really think Mikrotik should discuss using partitions in addition to backups.
Can I make partition(s) on my mAP Lite? It has only 32MB disk space.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 12:17 pm

This was very easy to roll back with a partition. Just make the partition..
You are right, but try to use partitioning on a hEX (or any other "zero flash") devices!
There is no common sense in putting 16mb flash on new devices.. IMHO .. the real reason is obviously NOT save 2 bucks
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Mon May 05, 2014 10:36 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 12:31 pm

I really think Mikrotik should discuss using partitions in addition to backups.
Can I make partition(s) on my mAP Lite? It has only 32MB disk space.
Are you sure about that? mAP lite should have 64MB RAM and 16MB flash ... and no you cant use partitions ...
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 2:04 pm

After upgrading from 6.40rc38 to 6.40rc41 I do not see any 5Ghz client being connected on many of my WAP AC devices. Normally I get a ratio of 60:40 for 2.4Ghz:5Ghz.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 3:21 pm

This was very easy to roll back with a partition. Just make the partition active that was right before the upgrade. Took seconds.. As I mentioned, everyone doing RCs should use partitions. I copy my current RC and config over to a partition before I try out a new RC. Any issue, I just move back..

I had to with 38, upgraded to 41. On the 2011 it was still causing the display to flash. So 41 did not fix something from 38. So I "made active" my original partition and the issue was gone.

I really think Mikrotik should discuss using partitions in addition to backups.
+1

This is a wonderful idea. I didn't even know this was possible till you mentioned so as well some means to boot once off a secondary partition?
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 5:11 pm

https://wiki.mikrotik.com/wiki/Manual:I ... pt_example

DHCP-Client does not run 'script=' on lease refresh (e.g. when gateway changes but IP address stays the same).
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 5:40 pm

Important: This means all the new bridge/switch/igmp-snooping functionality is removed and will return in 6.41rc. The reason is that we found that these new features need more testing, and v6.40 was too close to release, so it would delay the release for some time. Those of you who used the RC, there is no painless way to upgrade or downgrade.
Normis, what is the time-line for 6.40 GA and 6.41rc?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 7:15 pm

This is a wonderful idea. I didn't even know this was possible till you mentioned so as well some means to boot once off a secondary partition?
It can boot off the secondary partition when booting off the first partition fails. Although it is not clearly defined what failing to boot really means.
I would have liked some feature like "boot off secondary partition when internet connection (or some VPN) fails to establish within X minutes" but
you will have to program that yourself using a script, and it is not straightforward, you cannot e.g. use a "/tool netwatch down-script" directly because
it is ALWAYS called on reboot.

Furthermore, unfortunately the use of partitions is no longer possible on the low-end models of the current product programme. A year or two ago
the low-end models still had enough flash to use partitions, but today many models have ony 16GB flash.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 7:41 pm

I'm with you guys. I'm not sure what class embedded designers are taught to use tiniest flash chip available on the market but I'd like to alter that curriculum. That said, I do get that in the hardware world, cents does multiply out to dollars when the sale quantity gets high enough. It seems like an area were you could cheaply separate yourself from other router brands even with a 128mb or 256mb flash chip.

For poops and giggles, a quick google search shows:

0.61 USD = 32MB flash chip
3.43 USD = 256MB flash chip
9.52 USD = 1GB flash chip

These numbers are very quick and dirty. Naturally the product would have to be vetted to make sure it fits the design and volume purchase discounts could soften the cost. I was just hoping to put a cost per unit for the upgrade into print in hopes of giving us all a little perspective on what kind of price impact we'd see if MikroTik moved to larger chips and passed that cost onto consumers. A device like the hap AC already in that +100 USD cost may handle an additional ~9 USD different easier than say a cap lite. I personally would be very happy with a 256MB (even 128MB) upgrade at a ~3 USD impact per device across the product line. The cost increase for storage capacity would be a justifiable reason that would increase my likelyhood to purchase MikroTik. That is just me, I can't speak for all forum members in all markets.
 
buzzdee
newbie
Posts: 35
Joined: Mon Apr 22, 2013 1:22 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 10:41 pm

As of version 6.37 I had some trouble using RoMon with R52 equipped devices in station mode.
viewtopic.php?f=21&t=114926&p=569766#p569766

The 6.40rc's i've tried so far (6.40rc32 and 6.40rc41) have solved this issue.
 
qq4569712
just joined
Posts: 12
Joined: Sat May 07, 2011 10:24 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 10:42 pm

Currently RouterOS6.40rc does support any of EAP authentication methods?
Yes, the below methods.

Image
In the V6.40rc41 version, I can not find this option. Please tell me the details of the setup steps and methods, thanks. Please forgive me, my English is very bad
 
User avatar
null31
Member Candidate
Member Candidate
Posts: 183
Joined: Fri Dec 23, 2016 6:07 pm
Location: Brazil

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 11:45 pm

In the V6.40rc41 version, I can not find this option. Please tell me the details of the setup steps and methods, thanks. Please forgive me, my English is very bad
The EAP section is on Wireless > Security Profiles > Profile entries (via winbox).

I forgot to ask.
Do you want the Mikrotik as EAP Client or as EAP Access Point?
The print that I showed is about EAP Client.

Now about EAP AP:
Page 16.
> https://mum.mikrotik.com//presentations ... 009077.pdf (Spanish language)
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Tue Jul 18, 2017 11:59 pm

I'm with you guys. I'm not sure what class embedded designers are taught to use tiniest flash chip available on the market but I'd like to alter that curriculum. That said, I do get that in the hardware world, cents does multiply out to dollars when the sale quantity gets high enough. It seems like an area were you could cheaply separate yourself from other router brands even with a 128mb or 256mb flash chip.

For poops and giggles, a quick google search shows:

0.61 USD = 32MB flash chip
3.43 USD = 256MB flash chip
9.52 USD = 1GB flash chip

These numbers are very quick and dirty. Naturally the product would have to be vetted to make sure it fits the design and volume purchase discounts could soften the cost. I was just hoping to put a cost per unit for the upgrade into print in hopes of giving us all a little perspective on what kind of price impact we'd see if MikroTik moved to larger chips and passed that cost onto consumers. A device like the hap AC already in that +100 USD cost may handle an additional ~9 USD different easier than say a cap lite. I personally would be very happy with a 256MB (even 128MB) upgrade at a ~3 USD impact per device across the product line. The cost increase for storage capacity would be a justifiable reason that would increase my likelyhood to purchase MikroTik. That is just me, I can't speak for all forum members in all markets.
+1

MT products come to many of us as an enterprise product, failover/secondary boot would be awesome. Of course I'll mention it in feature requests later otherwise that @andriys will flame for 'spamming' this thread.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 12:36 am

You are right, but try to use partitioning on a hEX (or any other "zero flash") devices!
There is no common sense in putting 16mb flash on new devices.. IMHO .. the real reason is obviously NOT save 2 bucks
This does seem strange in today's world.... but then again, as Idlemind points out - $2 for every unit sold can translate to hundreds of thousands or millions of dollars less in profits for a particular unit if it's popular...
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 3:36 am

.. less in profits ..
I see yours point, but ..

hEX/RB750Gr3 >> 5 Gbit ethernet, poe in, CPU with 4 Threads 2 core 880 MHz, usb port, sd port, 256 mb ram, voltage sensor and pcb temp sensor.. and 16mb flash !?

I think there were other rooms for saving 2 $ , why put 256 mb ram and quad core cpu .. temp and voltage monitor, usb and SD interfaces..
I can easily understand that design choice on a mAP or similar device, but on hEX it's seems unbalanced.. IMHO.
 
qq4569712
just joined
Posts: 12
Joined: Sat May 07, 2011 10:24 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 8:40 am

In the V6.40rc41 version, I can not find this option. Please tell me the details of the setup steps and methods, thanks. Please forgive me, my English is very bad
The EAP section is on Wireless > Security Profiles > Profile entries (via winbox).

I forgot to ask.
Do you want the Mikrotik as EAP Client or as EAP Access Point?
The print that I showed is about EAP Client.

Now about EAP AP:
Page 16.
> https://mum.mikrotik.com//presentations ... 009077.pdf (Spanish language)
Thanks null31, i try to try mikrotik route to build an iKEV2 VPN server, i have no radius, my client is windows7, i read wik i but still can not succeed. Would you like to help me?
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Mon May 05, 2014 10:36 am

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 12:10 pm

You got this wrong ... flash chips are declared in Megabits ... so the prices you found are for 4MB, 32MB and 128MB respectively ...
I'm with you guys. I'm not sure what class embedded designers are taught to use tiniest flash chip available on the market but I'd like to alter that curriculum. That said, I do get that in the hardware world, cents does multiply out to dollars when the sale quantity gets high enough. It seems like an area were you could cheaply separate yourself from other router brands even with a 128mb or 256mb flash chip.

For poops and giggles, a quick google search shows:

0.61 USD = 32MB flash chip
3.43 USD = 256MB flash chip
9.52 USD = 1GB flash chip

These numbers are very quick and dirty. Naturally the product would have to be vetted to make sure it fits the design and volume purchase discounts could soften the cost. I was just hoping to put a cost per unit for the upgrade into print in hopes of giving us all a little perspective on what kind of price impact we'd see if MikroTik moved to larger chips and passed that cost onto consumers. A device like the hap AC already in that +100 USD cost may handle an additional ~9 USD different easier than say a cap lite. I personally would be very happy with a 256MB (even 128MB) upgrade at a ~3 USD impact per device across the product line. The cost increase for storage capacity would be a justifiable reason that would increase my likelyhood to purchase MikroTik. That is just me, I can't speak for all forum members in all markets.
 
qoole
just joined
Posts: 19
Joined: Tue Jul 02, 2013 4:20 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 2:18 pm

You got this wrong ... flash chips are declared in Megabits ... so the prices you found are for 4MB, 32MB and 128MB respectively ...
I don't think he did get it wrong, 8gbit (1gbyte) FLASH on digikey can cost as little as between $6.16 (each in 1000 of quantity) and $9.45 (each in 1 of quantity).
That's Micron branded stuff too.

Digikey search: https://goo.gl/4ACaA5
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 2:54 pm

I have myself a RB750Gr3 and have indeed had some troubles with only 16MB flash. After getting some direction by Mikrotik I got the way it is meant to work. Firm upgrades don't are uploaded to the flash but the RAM.

It works very well and a liitle over half of the Flash os used for the firmware. All the stuff that not has to survive a restart is put in RAM.

To save stuff that has to be saved but not in the flash for that you can put SD card in.

I am very satisfied how all this works and if needed Mikrotik can put extra loadable packages on the SD card.

The Mikrotik not that expensive for the value you get back and constant development is a great addition.

On that development I advise to activate besides RC also development for the bold steps like Master to Bridge because many are using RC as current and a rollback is not without some nasty catches as I had to undergo. The solution was for me to flash the current and the step to to the wanted RC. Otherwise the backups made before were not usable.
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 3:08 pm

Mikrotik will not put extra loadable packages to external storage due to safety reasons. And 16MB flash is really too small because it does not allow you to use multiple partitions for your safety purposes.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Wed Jul 19, 2017 8:37 pm

Ehm, putting packages even on the SD is not smart but I was carried away by the thought of Mikrotik offering compression not only in the. npk files. ;-)

Maybe a plus version of the low cost routers is doable allowing more advanced users to have space to use partitions and the CPU supports that.
 
Kindis
Member
Member
Posts: 434
Joined: Tue Nov 01, 2011 6:54 pm
Location: Sweden

Re: v6.40rc [release candidate] is released! (New bridge implementation)

Thu Jul 20, 2017 12:28 am

Can we close this thread and open a new one with a better title as the new bridge is removed. Less confusing :)
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Thu Jul 20, 2017 11:16 am

Renamed the topic a bit :)
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Fri Jul 21, 2017 1:12 pm

I´m standing directly in front of the WAP AC and got disconnect with group key timeout on 5Ghz while downloading files (Sony Z1 Compact with Android 5.1) RouterOS release is 6.40.rc41
I updated to routerboard firmware: 3.39 before I saw this behavior. How can I downgrade routerboard firmware?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Fri Jul 21, 2017 2:29 pm

You can downgrade RouterOS, it is not required to downgrade the firmware.
Just select the "Current" branch in System->Packages->Update.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 9:21 pm

Any chance you could add 'Radio Name' in the SNMP wireless registrations table? It is great having graphs of wireless clients but I do not know which is which without the name. Thanks.
 
upower3
Member
Member
Posts: 425
Joined: Thu May 07, 2015 11:46 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 9:24 pm

Any chance you could add 'Radio Name' in the SNMP wireless registrations table? It is great having graphs of wireless clients but I do not know which is which without the name. Thanks.
Better use API call, will be faster way I suppose, like
/interface/wireless/registration-table
and play with.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1135
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 9:32 pm

Any chance you could add 'Radio Name' in the SNMP wireless registrations table? It is great having graphs of wireless clients but I do not know which is which without the name. Thanks.
Better use API call, will be faster way I suppose, like
/interface/wireless/registration-table
and play with.
This is not realistic.
SNMP is the defacto standard. All monitoring software (Cacti, Observium/LibreNMS, etc) supports SNMP. None that I know of supports RouterOS API. At least not without custom/3rd party plugins.

You can already monitor the signal using SNMP but you only get a MAC Address to identify the client by and it's not really easy to tell which is which as mducharme mentioned.
 
upower3
Member
Member
Posts: 425
Joined: Thu May 07, 2015 11:46 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 9:38 pm

This is not realistic.
I do understand your pain but Mikrotik is quite slow with SNMP so far. Keep asking, maybe one day?..

What I can offer (well, kind of) is to use you own SNMP server software to reply to specific SNMP requests while query MT's API for information. Not nice at all but at least it'll work.

I did that trick with Zabbix by feeding values to Zabbix server with zabbix-send for values I wasn't able to get via SNMP. I compute the list of calls I need to do, then connect to mikrotik, run one by one these requests and in one bunch send it via zabbix-send. So to say, it lowered the burned o MT CPU, since every new connection (with auth) seems to adds up load.

Dirty and unstable trick, I know, for API calls may be changed one day, but the same is true for OIDs.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1135
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 9:50 pm

For a single router or even a few, I understand that this is a solution. I've done similar stuff myself for BGP monitoring.

But when you already manage hundreds of routers with limited access policy (ie: NO API) using these kinds of 'hacks' are not scalable or manageable. Hence not realistic for production environment.

Not to mention the fact that you will flood the logs with tons of API logins/logouts every X (usually 1 or 5) minutes.
And disabling the logins logging is not realistic either :lol:
 
upower3
Member
Member
Posts: 425
Joined: Thu May 07, 2015 11:46 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 10:24 pm

scalable or manageable. Hence not realistic for production environment.
Oh, I see you're wise person already, will not teach you this way :) I can't say how many routers you need to monitor from you initial question. Yes, let's wait for MT to help with this.

They should add scripting into SNMP server, so you can set OID and which script to execute to reply the query :) This is where MT win all the time - scripting!
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 10:51 pm

Any chance you could add 'Radio Name' in the SNMP wireless registrations table? It is great having graphs of wireless clients but I do not know which is which without the name. Thanks.
+1 support for this
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Sun Jul 23, 2017 11:10 pm

They should add scripting into SNMP server, so you can set OID and which script to execute to reply the query :) This is where MT win all the time - scripting!
That feature is actually available! But it is a bit hard to find and understand.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 12:32 am

Any chance you could add 'Radio Name' in the SNMP wireless registrations table? It is great having graphs of wireless clients but I do not know which is which without the name. Thanks.
+1 support for this
+1

I do use SYSLOG and SNMP with SPLUNK to get all what I need for monitoring.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 1:28 am

APIs are good but tbh SNMP is far easier to work with in NMS tools. I've found a handful of OIDs I'd really like to see supported. Particularly IPv6 traffic tracking and connection counts. Saying it's solved with scripting to custom OIDs is a total hack over supporting standardized mibs.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 6:33 am

APIs are good but tbh SNMP is far easier to work with in NMS tools. I've found a handful of OIDs I'd really like to see supported. Particularly IPv6 traffic tracking and connection counts. Saying it's solved with scripting to custom OIDs is a total hack over supporting standardized mibs.
Yes, and adding the "Radio Name" field is something that should, IMO, be relatively easy for them to do.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10185
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 11:59 am

that should, IMO, be relatively easy for them to do.
There is probably a list of things that are relatively easy to do that is so long that it requires considerable effort to sort it all out...
 
upower3
Member
Member
Posts: 425
Joined: Thu May 07, 2015 11:46 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 12:46 pm

By the way, I now can see two block diagrams for routers, one for non-switched config and other is for switched. So as 6.41 is out both still be there but "switched" become "attached to the same bridge", right?

Also, on this diagram:

Image

am I right to say that if I set 2-4 ports to be switched, and port 1 as non-switched, then port 1 will be 1 Gbps, and four remaining will share another 1 Gpbs in routing scenario?
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Mon Jul 24, 2017 5:31 pm

By the way, I now can see two block diagrams for routers, one for non-switched config and other is for switched. So as 6.41 is out both still be there but "switched" become "attached to the same bridge", right?

Also, on this diagram:

Image

am I right to say that if I set 2-4 ports to be switched, and port 1 as non-switched, then port 1 will be 1 Gbps, and four remaining will share another 1 Gpbs in routing scenario?
Running 6.40rc38 (won't be upgrading until 6.41rc is released) I don't get hardware offload on any ports. That's ok for me because I have the hex doing intervlan routing which is done in CPU anyways per MikroTik support. I have a separate layer 2 switch that is capable of faster speeds between the hex and my various devices for intravlan traffic.
 
HeadCraft
just joined
Posts: 16
Joined: Tue Mar 05, 2013 11:11 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Tue Jul 25, 2017 11:39 am

As in v6.39.2 still not changing dynamic ipsec src. address in policies and peers, when setting it in ipip tunnel interface in local address setting. And if I delete dynamic entries in ipsec policies or peers, the will not appear anymore until reboot, or set another dst address.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Tue Jul 25, 2017 11:47 am

@HeadCraft be more specific, what you described works:
[admin@rack1_b3] /interface ipip> /ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes priority=0x10000 

 1  D  ;;; ipip-tunnel4
       src-address=1.1.1.1/32 src-port=any dst-address=1.1.1.2/32 dst-port=any protocol=ipencap action=encrypt 
       level=require ipsec-protocols=esp tunnel=no proposal=default priority=0x20000 ph2-count=0 
[admin@rack1_b3] /interface ipip> print 
Flags: X - disabled, R - running, D - dynamic 
 #     NAME         MTU ACTUAL-MTU LOCAL-ADDRESS   REMOTE-ADDRESS       KEEPALIVE                               DSCP
 0     ipip-tu...  auto       1480 1.1.1.1         1.1.1.2              10s,10                               inherit
 
 [admin@rack1_b3] /interface ipip> set 0 local-address=2.2.2.2 
[admin@rack1_b3] /interface ipip> /ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes priority=0x10000 

 1  D  ;;; ipip-tunnel4
       src-address=2.2.2.2/32 src-port=any dst-address=1.1.1.2/32 dst-port=any protocol=ipencap action=encrypt 
       level=require ipsec-protocols=esp tunnel=no proposal=default priority=0x20000 ph2-count=0 

 
 
HeadCraft
just joined
Posts: 16
Joined: Tue Mar 05, 2013 11:11 am

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Tue Jul 25, 2017 3:02 pm

@HeadCraft be more specific, what you described works:
[admin@rack1_b3] /interface ipip> /ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes priority=0x10000 

 1  D  ;;; ipip-tunnel4
       src-address=1.1.1.1/32 src-port=any dst-address=1.1.1.2/32 dst-port=any protocol=ipencap action=encrypt 
       level=require ipsec-protocols=esp tunnel=no proposal=default priority=0x20000 ph2-count=0 
[admin@rack1_b3] /interface ipip> print 
Flags: X - disabled, R - running, D - dynamic 
 #     NAME         MTU ACTUAL-MTU LOCAL-ADDRESS   REMOTE-ADDRESS       KEEPALIVE                               DSCP
 0     ipip-tu...  auto       1480 1.1.1.1         1.1.1.2              10s,10                               inherit
 
 [admin@rack1_b3] /interface ipip> set 0 local-address=2.2.2.2 
[admin@rack1_b3] /interface ipip> /ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes priority=0x10000 

 1  D  ;;; ipip-tunnel4
       src-address=2.2.2.2/32 src-port=any dst-address=1.1.1.2/32 dst-port=any protocol=ipencap action=encrypt 
       level=require ipsec-protocols=esp tunnel=no proposal=default priority=0x20000 ph2-count=0 

 
Sorry, I just found why it is not working correct (may be I doing it incorrect). The reason is that I use mikrotik DDNS as destination address in tunnel. So situation is:
[admin@MikroTik] > /interface ipip
add allow-fast-path=no ipsec-secret=123 !keepalive local-address=1.1.1.1 name=\
    ipip-tunnel1 remote-address=google-public-dns-a.google.com
After creating interface with dns there is no ipsec policies at all.
[admin@MikroTik] > ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default 
       template=yes
Lets reboot the router, and we see the policy:
[admin@MikroTik] > ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default 
       template=yes 

 1  D  ;;; ipip-tunnel1
       src-address=1.1.1.1/32 src-port=any dst-address=8.8.8.8/32 dst-port=any 
       protocol=ipencap action=encrypt level=require ipsec-protocols=esp tunnel=no 
       proposal=default priority=0 ph2-count=0

Now we will change settings in tunnel interface:
[admin@MikroTik] > /interface ipip set [find name=ipip-tunnel1] local-address=3.3.3.3
But we still see old ip in policies
[admin@MikroTik] > ip ipsec policy print                                             
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default 
       template=yes 

 1  D  ;;; ipip-tunnel1
       src-address=1.1.1.1/32 src-port=any dst-address=8.8.8.8/32 dst-port=any 
       protocol=ipencap action=encrypt level=require ipsec-protocols=esp tunnel=no 
       proposal=default priority=0 ph2-count=0
And in peers
[admin@MikroTik] > ip ipsec peer print  
Flags: X - disabled, D - dynamic, R - responder 
 0  D  ;;; ipip-tunnel1
       address=8.8.8.8/32 local-address=1.1.1.1 auth-method=pre-shared-key secret="123" 
       generate-policy=no policy-template-group=default exchange-mode=main 
       send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=sha1 
       enc-algorithm=aes-128,3des dh-group=modp1024 lifetime=1d dpd-interval=2m 
       dpd-maximum-failures=5
After rebooting the router we will see new ip.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1616
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.40rc [release candidate] is released! (New bridge implementation delayed till 6.41rc)

Wed Jul 26, 2017 2:37 pm

Version 6.41rc has been released:
viewtopic.php?f=21&t=123936

Who is online

Users browsing this forum: No registered users and 25 guests