Page 7 of 12

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

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

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

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

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

Posted: Thu Oct 12, 2017 3:00 am
by ShturmN
I'm update to 6.41rc44 my sxt 5 and now:
https://s.mail.ru/6XPP/7BwY2UJm3

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

Posted: Thu Oct 12, 2017 10:16 am
by pe1chl
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.

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

Posted: Thu Oct 12, 2017 11:06 am
by Chupaka
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
so, some peering partner injects a route to block himself? it's either bad or dumb peering partner :)

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

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

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

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

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

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

But how do I reach R2 itself on VLAN3 ?

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

How can I reach R2 via VLAN3?!?

Any help is highly appreciated. 8)

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

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

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

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

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

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

But how do I reach R2 itself on VLAN3 ?

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

How can I reach R2 via VLAN3?!?

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

You need to tag the VLANs on the bridge itself in /int bridge vlan and the VLAN interfaces need to have the interface property set to the bridge in question not some random Ethernet interface.

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

Posted: Fri Oct 13, 2017 11:06 am
by whitbread
Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?

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

Posted: Fri Oct 13, 2017 11:18 am
by Gennadiy51
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?

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

Posted: Fri Oct 13, 2017 12:34 pm
by blimbach
This Version is really bad on my hapac capsman:

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

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

How to downgrade to an older rc? I cannot find a download-link.

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

Posted: Fri Oct 13, 2017 1:13 pm
by kamillo
How to downgrade to an older rc? I cannot find a download-link.
Go to https://mikrotik.com/download

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

https://download2.mikrotik.com/routeros/6.41rc38/routeros-mipsbe-6.41rc38.npk

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

Posted: Fri Oct 13, 2017 1:39 pm
by blimbach
Thank you, downgrading fixed the Problem to me.

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

Posted: Fri Oct 13, 2017 3:43 pm
by jrpaz
Same issue with the RB750gr3 had to downgrade back #sad

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

Posted: Fri Oct 13, 2017 4:06 pm
by emils
If you experience critical program crashes or kernel panics on latest release candidate versions, please send supout.rif (autosupout.rif) files to support@mikrotik.com before downgrading.

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

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

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

Posted: Fri Oct 13, 2017 6:36 pm
by whitbread
imho it is actually only good for a LAN router not for a router with direct uplink.

What I do like actually is that it gives information about the ports open via MAC. :D

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

Posted: Mon Oct 16, 2017 9:03 am
by strods
Version 6.41rc release includes fixes in WPA2 protocol:
viewtopic.php?f=21&t=126695

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

Posted: Mon Oct 16, 2017 1:27 pm
by alkar
Hi,
when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
It is difficult to manage hundreds of vlans in a text teminal.

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

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

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?

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

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

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

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

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

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

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.

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

Posted: Mon Oct 16, 2017 4:22 pm
by idlemind
Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.

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

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

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

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

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

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

Posted: Mon Oct 16, 2017 5:23 pm
by Kubuxu
That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU.
I know that, but this is VLAN100<->VLAN100 which should be possible to be done in the switch.
expect existing hardware features to slowly be turned on in the new environment
Let's hope in future it will allow to use 3011 switch capabilities with any VLAN.

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

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

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
A "traditional" way in CRS317 not working. Switch menu shown all ports as Unknown.
viewtopic.php?f=17&t=125758

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

Posted: Tue Oct 17, 2017 5:00 pm
by idlemind
Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

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

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

Posted: Thu Oct 19, 2017 12:42 pm
by strods
What's new in 6.41rc47 (2017-Oct-18 10:38):

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.

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

Posted: Thu Oct 19, 2017 5:41 pm
by planetcoop
"/ip neighbors" seems to not work on 6.41rc47 on tile...

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

Posted: Thu Oct 19, 2017 5:49 pm
by mrz
go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all

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

Posted: Thu Oct 19, 2017 5:54 pm
by raffav
go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
this function is not available on winbox yet correct ?

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

Posted: Thu Oct 19, 2017 5:58 pm
by mrz
yes, currently only terminal. Default value is "!dynamic", but you can set it to "all".

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

Posted: Thu Oct 19, 2017 6:00 pm
by raffav
thanks

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

Posted: Thu Oct 19, 2017 7:22 pm
by pe1chl
*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
Discovery packets are now sent with source 0.0.0.0 instead of interface address as before. Maybe due to this change?
This causes firewall issues, we drop "bogon" packets (packets from an address list with certain reserved addresses including 0.0.0.0)
before the rule that accepts discovery packets.

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

Posted: Thu Oct 19, 2017 9:45 pm
by raffav
Mikrotik team

is it difficult to create some type of address-list or something similar to use on ipsec polices in future release ?

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

Posted: Thu Oct 19, 2017 10:49 pm
by alexsolovyev
Applying the default configuration seems to be broken in 6.41rc47. I'm getting an empty config after clicking on the "OK" button after resetting the configuration. It's working in 6.40.4

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

Posted: Fri Oct 20, 2017 2:26 am
by chubbs596
Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?

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

Posted: Fri Oct 20, 2017 3:18 am
by idlemind
Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?

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

Posted: Fri Oct 20, 2017 9:43 am
by roswitina
I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

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

I go back to the current firmware 6.40.4.

rosi

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

Posted: Fri Oct 20, 2017 10:09 am
by uldis
I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

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

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com

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

Posted: Fri Oct 20, 2017 11:24 am
by bajodel
Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
and if I need a single service tag on packets ?
I've never played with new bridge but I suppose there is a place where I can set the tag type..

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

Posted: Fri Oct 20, 2017 1:09 pm
by roswitina
I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

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

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com
I'm doing it. I install v6.41RC47 and wait for the next crash.
Rosi

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

Posted: Fri Oct 20, 2017 1:30 pm
by linek1980
oct/19 15:40:31 system,info router rebooted
oct/19 15:40:31 system,error,critical router rebooted because some critical program crashed
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether2
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether3
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether4
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether5
oct/19 15:40:41 interface,info ether1 link up (speed 100M, full duplex)

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

Posted: Fri Oct 20, 2017 2:11 pm
by Chupaka
Please make a support output file after the crash and send it to support@mikrotik.com

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

Posted: Fri Oct 20, 2017 3:09 pm
by becs
In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.

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

Posted: Fri Oct 20, 2017 6:19 pm
by JimmyNyholm
In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?

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

Posted: Fri Oct 20, 2017 7:00 pm
by idlemind
In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?
Wouldn't it have been in software before? Are their models that supported QinQ in hardware under the switch chip menu?

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

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

Is this a software limitation of the current RC development and will be implemented in the near future?

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

Posted: Sun Oct 22, 2017 1:46 am
by guipoletto
I would like to know if this new bridge implementation affects something on hardware that does not have an integrated switch-chip (Rb333, CCR, rb1200{ports5-10}, etc).
Are any performance gains to be expected?

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

Posted: Sun Oct 22, 2017 2:00 pm
by hapi
*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?

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

Posted: Mon Oct 23, 2017 9:37 am
by biatche
*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?
Do that for capsman too.

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

Posted: Mon Oct 23, 2017 8:24 pm
by darencrew
On previous releases, a way to flush neighbor discovery entries was to disable and re-enable discovery interfaces.
Now, it has no more effects, entries disappear only after aged out.

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

In my opinion, the new "/ip neighbor discovery-settings set discover-interface-list" is not totally useless but is too generic, so it should better be a new feature (or more exactly a macro) and not a replacement feature.

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

Posted: Tue Oct 24, 2017 9:11 am
by darzupan
Hi

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

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

Another problem

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

What could be a problem?


Best regards