Community discussions

 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
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: 1717
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!
With great knowledge comes great responsibility, because of ability to recognize id... incompetent people much faster.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.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: 202
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!
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1406
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 Candidate
Member Candidate
Posts: 278
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: 477
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: 191
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?
-----
Alex Hart

The Brothers WISP
 
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 Candidate
Member Candidate
Posts: 278
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.
Best Regards,
Raf G
 
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.
Best Regards,
Raf G
 
andriys
Forum Guru
Forum Guru
Posts: 1111
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: 191
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?
-----
Alex Hart

The Brothers WISP
 
irghost
Member Candidate
Member Candidate
Posts: 277
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
MTCNA MTCRE MTCTCE MTCUME MTCWE MTCIPv6E MTCINE
 
pe1chl
Forum Guru
Forum Guru
Posts: 5545
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: 17
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: 30
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: 545
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
Member
Member
Posts: 469
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: 30
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: 1101
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: 1101
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 Candidate
Member Candidate
Posts: 278
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: 1101
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 Candidate
Member Candidate
Posts: 278
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
Long time Member
Long time Member
Posts: 699
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: 1101
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: 1282
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.
David Joyce
Network & Security Engineer
Intrus Technologies, LLC.
Rancho Cucamonga, CA, USA
 
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: 11
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
Member
Member
Posts: 469
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: 5545
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: 1282
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
David Joyce
Network & Security Engineer
Intrus Technologies, LLC.
Rancho Cucamonga, CA, USA
 
andriys
Forum Guru
Forum Guru
Posts: 1111
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: 30
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
Member
Member
Posts: 348
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
Member
Member
Posts: 469
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
Member
Member
Posts: 469
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
Member
Member
Posts: 480
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:
MTCNA - 2011

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

Re: v6.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: 119
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: 5545
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 Candidate
Member Candidate
Posts: 278
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: 1282
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.
David Joyce
Network & Security Engineer
Intrus Technologies, LLC.
Rancho Cucamonga, CA, USA
 
FIPTech
Member
Member
Posts: 469
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: 1101
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.

Who is online

Users browsing this forum: No registered users and 4 guests