v6.39rc80 [release candidate] is released!

[sergejs]

We have released MikroTik RouterOS v6.39rc76, we are getting very close to release stable v6.39 to current channel. Please report all known issues here or to support@mikrotik.com

What’s new in 6.39rc76 (2017-Apr-21 07:24):
other changes in 6.39rc tree,
https://mikrotik.com/download/changelogs/release-candidate-release-tree

*) capsman - added EAP identity to registration table;
*) capsman - added support for “background-scan” and channel “reselect-interval”;
*) ike2 - fixed RSA authentication without EAP;
*) ike2 - fixed policy release during SA negotion;
*) l2tp - fixed hidden attribute decryption in forwarded CHAP responses for LNS;
*) ppp - include rates, limits and address-lists parameters in RADIUS accounting requests;
*) pppoe - added warning on PPPoE client/server, if it is configured on slave interface;
*) tile - fixed IPSec crash (introduced in 6.39rc64);
*) webfig - allow to change global variable contents;
*) webfig - allow to enter frequency ranges in wireless scan list;
*) webfig - do not allow to reorder items if table is sorted by some column;
*) webfig - fixed bridge property display;
*) webfig - show proper error messages for optional erroneous text fields;
*) winbox - added “k” and “M” unit support to PPP secret limit-bytes parameters;
*) winbox - added “Flush” button under unicast-fdb menu;
*) winbox - added “memory-scroll”, “filter-cpu”, “filter-ipv6-address”, “filter-operation-between-entries” parameters;
*) winbox - added protected routerboard parameters under routerboard settings menu;
*) winbox - hide “wps-mode” & “security-profile” in wireless nv2 mode;
*) winbox - properly show wireless registration table stat counters;
*) wireless - fixed dynamic wireless interface removal from bridge ports when changing wireless mode;

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.

v6.39rc80 is released,
https://forum.mikrotik.com/viewtopic.php?f=1&t=120946&p=595256#p595256

[bbs2web]

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:

int vlan add name=vlanXXX interface=bridge vlan-id=XXX

The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS’s STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits of STP in the first place.

I generally understand things better with examples, perhaps the following helps others too:
You have a customer who’s paying for a layer 2 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, on redundant routers, set each one to bridge the services to the customer’s service delivery VLANs on the PNI and RSTP would automatically isolates loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38…

The current implementation additionally simply assumes that it can transmit the STP BPDU frames on the VLAN’s parent interface, so it becomes immensely unpredictable:

• • Bridging QinQ VLANs. Attach ‘vlan10-vlan100’ to a bridge and the STP frames are transmitted on vlan10. This is in direct contradiction to their change announcement where they indicated that STP wouldn’t be tagged.
    
    
    
• • Bridging other interfaces. RouterOS doesn’t transmit STP BPDU directly on the carrier interface when you bridge a tunnel interface such as EoIP, VPLS, etc. By this I mean that RouterOS wouldn’t sporadically send STP BPDU frames on ether1 because it’s carrying an EoIP tunnel. A Virtual LAN interface is supposed to be isolated from other interfaces, why would MikroTik suddenly consider it normal to transmit STP BPDU frames outside of the bridge

MikroTik should at the very least provide a method to retain their previous STP implementation, which worked well with Cisco’s PVSTP (per VLAN STP). This quite simply transmitted STP BPDU frames on all bridge member ports. Yes, bridging vlan10 and then connecting the uplink port to a cheap D-Link or Netgear may cause the STP implementation on that switch to shut the port, but that’s a problem with the switch or the user’s implementation; not for MikroTik to have a knee jerk reaction and break something as fundamental as service provider bridging redundancy. PS: People with these switches should either simply disable STP on the uplink interface, change their topology, log a request to have switch firmware changed or get a PVSTP capable switch.

I furthermore don’t see the point of having independent STP processes running for each bridge, if the STP BPDU frames are leaked to ports that aren’t members of those bridges. Simply do what switch vendors have done and provide the option of how you want STP to operate (eg Netgear M4300 offers STP, RSTP, MSTP or PV(R)STP).

[g33k]

May I have the details on ‘ppp - include rates, limits and address-lists parameters in RADIUS accounting requests;’


Thanks

[xlighting]

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

[macgaiver]

@xlighting

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive…

[biatche]

@bbs2web

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:

int vlan add name=vlanXXX interface=bridge vlan-id=XXX

The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS’s STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits of STP in the first place.

I generally understand things better with examples, perhaps the following helps others too:
You have a customer who’s paying for a layer 2 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, on redundant routers, set each one to bridge the services to the customer’s service delivery VLANs on the PNI and RSTP would automatically isolates loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38…

The current implementation additionally simply assumes that it can transmit the STP BPDU frames on the VLAN’s parent interface, so it becomes immensely unpredictable:

• • Bridging QinQ VLANs. Attach ‘vlan10-vlan100’ to a bridge and the STP frames are transmitted on vlan10. This is in direct contradiction to their change announcement where they indicated that STP wouldn’t be tagged.
    
    
    
• • Bridging other interfaces. RouterOS doesn’t transmit STP BPDU directly on the carrier interface when you bridge a tunnel interface such as EoIP, VPLS, etc. By this I mean that RouterOS wouldn’t sporadically send STP BPDU frames on ether1 because it’s carrying an EoIP tunnel. A Virtual LAN interface is supposed to be isolated from other interfaces, why would MikroTik suddenly consider it normal to transmit STP BPDU frames outside of the bridge

MikroTik should at the very least provide a method to retain their previous STP implementation, which worked well with Cisco’s PVSTP (per VLAN STP). This quite simply transmitted STP BPDU frames on all bridge member ports. Yes, bridging vlan10 and then connecting the uplink port to a cheap D-Link or Netgear may cause the STP implementation on that switch to shut the port, but that’s a problem with the switch or the user’s implementation; not for MikroTik to have a knee jerk reaction and break something as fundamental as service provider bridging redundancy. PS: People with these switches should either simply disable STP on the uplink interface, change their topology, log a request to have switch firmware changed or get a PVSTP capable switch.

I furthermore don’t see the point of having independent STP processes running for each bridge, if the STP BPDU frames are leaked to ports that aren’t members of those bridges. Simply do what switch vendors have done and provide the option of how you want STP to operate (eg Netgear M4300 offers STP, RSTP, MSTP or PV(R)STP).

Would having MSTP option solve this issue?

[xlighting]

@macgaiver

@xlighting

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive…

revert to 6.38.5(with same config) will immediately fix the problem…

indeed I have policy routing, I don’t think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

[Marino]

@xlighting

@macgaiver

@xlighting

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive…

revert to 6.38.5(with same config) will immediately fix the problem…

indeed I have policy routing, I don’t think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

Same here. I saw some posts with fasttrack problems in the previous version too. I’m using a RB750Gr3.

[sergejs]

bbs2web, thank you very much for the output. We will see what we can do.

g33k, PPP accounting messages now include the following paramters
MikroTik-Rate-Limit
X-Ascend-Xmit-Rate and X-Ascend-Data-Rate
MikroTik-Addres-list

Marino, and other who might have the same problem potentially.
It would be great to get some steps/instructions to support@mikrotik.com how to repeat described problems.

[jkarras]

@sergejs

Marino, and other who might have the same problem potentially.
It would be great to get some steps/instructions to support@mikrotik.com how to repeat described problems.

Steps for me were to upgrade to anything past rc62. Sites became unbearably slow if the traffic flow went through the fasttrack rule. I have a VRF on my device and that traffic was not showing issues its also not picked up by the fasttrack rule. If I disable the fast track rule everything flows normally again.

In my scenario the traffic was flowing through a SRCNAT rule I don’t have a good way at the moment to test if non-SRCNAT traffic is affected.

[andriys]

@jkarras

Steps for me were to upgrade to anything past rc62…

I don’t think your reply is what sergejs has been asking for. It looks like just a small number of people experience problems similar to yours, so this must be something very specific to your exact configuration, no matter how simple or generic you consider your config to be. Can you please just share you full configuration with support@ (or, even better, send your supout to them).

[jkarras]

I understand. I already had an email typed up after that last version didn’t fix it with a sprout from before and after the upgrades. I was waiting until after the next update just in case they fixed it then.

My case is actually pretty simple. Standard home Internet provider, DHCP on WAN, masquerade rule, fast track matching related,established. Enabled traffic to Internet goes slow. disabled things are fine.

[mducharme]

@xlighting

@macgaiver

@xlighting

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive…

revert to 6.38.5(with same config) will immediately fix the problem…

indeed I have policy routing, I don’t think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

I am having MTU issues with IPv6 on these new RC’s, maybe it is the same problem. I had to disable IPv6 temporarily. Pings fail once packet size is turned up too high. I get my IPv6 through a tunnel.

Edit: perhaps it started at rc40? There was this change made in rc40: !) ppp - implemented internal algorithm for “change-mss”, no mangle rules necessary;

Maybe when they were making these changes for PPP MTU something was broken for MTU/MSS with other tunnel types.

[nkourtzis]

@bbs2web

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:

int vlan add name=vlanXXX interface=bridge vlan-id=XXX

The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS’s STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits of STP in the first place.

I generally understand things better with examples, perhaps the following helps others too:
You have a customer who’s paying for a layer 2 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, on redundant routers, set each one to bridge the services to the customer’s service delivery VLANs on the PNI and RSTP would automatically isolates loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38…

The current implementation additionally simply assumes that it can transmit the STP BPDU frames on the VLAN’s parent interface, so it becomes immensely unpredictable:

• • Bridging QinQ VLANs. Attach ‘vlan10-vlan100’ to a bridge and the STP frames are transmitted on vlan10. This is in direct contradiction to their change announcement where they indicated that STP wouldn’t be tagged.
    
    
    
• • Bridging other interfaces. RouterOS doesn’t transmit STP BPDU directly on the carrier interface when you bridge a tunnel interface such as EoIP, VPLS, etc. By this I mean that RouterOS wouldn’t sporadically send STP BPDU frames on ether1 because it’s carrying an EoIP tunnel. A Virtual LAN interface is supposed to be isolated from other interfaces, why would MikroTik suddenly consider it normal to transmit STP BPDU frames outside of the bridge

MikroTik should at the very least provide a method to retain their previous STP implementation, which worked well with Cisco’s PVSTP (per VLAN STP). This quite simply transmitted STP BPDU frames on all bridge member ports. Yes, bridging vlan10 and then connecting the uplink port to a cheap D-Link or Netgear may cause the STP implementation on that switch to shut the port, but that’s a problem with the switch or the user’s implementation; not for MikroTik to have a knee jerk reaction and break something as fundamental as service provider bridging redundancy. PS: People with these switches should either simply disable STP on the uplink interface, change their topology, log a request to have switch firmware changed or get a PVSTP capable switch.

I furthermore don’t see the point of having independent STP processes running for each bridge, if the STP BPDU frames are leaked to ports that aren’t members of those bridges. Simply do what switch vendors have done and provide the option of how you want STP to operate (eg Netgear M4300 offers STP, RSTP, MSTP or PV(R)STP).

I totally agree. I had MAJOR problems caused by this change until I figured out what the problem was. I was getting outages (and even complete freezes!) because the Tiks kept thinking that there was a loop where there was none. The problem was that BPDUs from two different bridges on the same physical network (one VLANed, one not) were being mixed up. At least a selectable option (strip/do not strip) would be nice to have, for those who need the tags to remain untouched.

[nkourtzis]

Another problem I saw in the 6.39RC is that the script for updating DynDNS (not the builtin “cloud” menu), taken from the wiki (https://wiki.mikrotik.com/wiki/Dynamic_DNS_Update_Script_for_dynDNS) stopped working after years without a problem. I have traced it down to the update statement, which uses the /tool fetch command to call the update URL. It is called but does not succeed to update the address. Probably a change in the behaviour of the fetch command caused an incompatibility. It is important, as this script is bound to a specific interface and thus it works better on routers with many public IPs.

[anuser]

@sergejs

*) capsman - added EAP identity to registration table;

/caps-man registration-table print detail gives me empty eap-identity, only, i.e.

eap-identity=""

[biatche]

@nkourtzis

@bbs2web

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:

int vlan add name=vlanXXX interface=bridge vlan-id=XXX

The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS’s STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits of STP in the first place.

I generally understand things better with examples, perhaps the following helps others too:
You have a customer who’s paying for a layer 2 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, on redundant routers, set each one to bridge the services to the customer’s service delivery VLANs on the PNI and RSTP would automatically isolates loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38…

The current implementation additionally simply assumes that it can transmit the STP BPDU frames on the VLAN’s parent interface, so it becomes immensely unpredictable:

• • Bridging QinQ VLANs. Attach ‘vlan10-vlan100’ to a bridge and the STP frames are transmitted on vlan10. This is in direct contradiction to their change announcement where they indicated that STP wouldn’t be tagged.
    
    
    
• • Bridging other interfaces. RouterOS doesn’t transmit STP BPDU directly on the carrier interface when you bridge a tunnel interface such as EoIP, VPLS, etc. By this I mean that RouterOS wouldn’t sporadically send STP BPDU frames on ether1 because it’s carrying an EoIP tunnel. A Virtual LAN interface is supposed to be isolated from other interfaces, why would MikroTik suddenly consider it normal to transmit STP BPDU frames outside of the bridge

MikroTik should at the very least provide a method to retain their previous STP implementation, which worked well with Cisco’s PVSTP (per VLAN STP). This quite simply transmitted STP BPDU frames on all bridge member ports. Yes, bridging vlan10 and then connecting the uplink port to a cheap D-Link or Netgear may cause the STP implementation on that switch to shut the port, but that’s a problem with the switch or the user’s implementation; not for MikroTik to have a knee jerk reaction and break something as fundamental as service provider bridging redundancy. PS: People with these switches should either simply disable STP on the uplink interface, change their topology, log a request to have switch firmware changed or get a PVSTP capable switch.

I furthermore don’t see the point of having independent STP processes running for each bridge, if the STP BPDU frames are leaked to ports that aren’t members of those bridges. Simply do what switch vendors have done and provide the option of how you want STP to operate (eg Netgear M4300 offers STP, RSTP, MSTP or PV(R)STP).

I totally agree. I had MAJOR problems caused by this change until I figured out what the problem was. I was getting outages (and even complete freezes!) because the Tiks kept thinking that there was a loop where there was none. The problem was that BPDUs from two different bridges on the same physical network (one VLANed, one not) were being mixed up. At least a selectable option (strip/do not strip) would be nice to have, for those who need the tags to remain untouched.

I believe we share the same issue. I just didn’t have the knowledge or understanding on how to explain it. Are you able to share what devices are involved to reproduce this at a very minimum and your topology?

I untag my vlan99 mgmt on the CRS and have a few trunk ports with native vlan 99, hence communicating as vlan1 by devices connected to this. Sorry if my explanation is poor so far. I’ve only come to learn that it is now possible to enable RSTP on the CRS as of 6.38, which I’ve yet to try. Hence, I had rstp enabled on two ends but not in between. I have two bridges, one involving vlans and another not. My question to you then is, would we face freezes still even when RSTP is enabled on the CRS?

[msatter]

I can confirm that, ike2 - fixed RSA authentication without EAP; has been resolved and it is working as normal again.

Thanks for fixing this.

[hedele]

@bbs2web

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I second this entire post - this change to how STP works is simply unacceptable as it breaks several different deployments we have in place where we NEED to rely on RouterOS to transmit correctly tagged BPDUs for interoperability with Cisco (and other PVST capable) gear.

[stucki]

is the update for chr on esx solved?