Fix confirmed, my issue is gone :)*) wireguard - fixed IPv6 traffic processing with multiple peers;
0 chain=cymru-in rule="if ( bgp-communities includes 65332:888 ) { accept } else { reject }"
Fb afi=ip4 contribution=filtered dst-address=23.151.160.0/24 routing-table=main gateway=1.2.3.4 immediate-gw=5.6.7.8%ether5_832 distance=20 scope=40 target-scope=30
belongs-to="BGP IP routes from 1.2.3.4"
bgp.peer-cache-id=*B000004 .as-path="65332" .communities=65332:888,no-export .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x20302360
still only one peer can use ipv6, not fixed*) wireguard - fixed IPv6 traffic processing with multiple peers;
For me such rules do work OK. I would advise trying to put the community in a community list and then reference that in the rule.this simple routing rule still does not work:
Code: Select all0 chain=cymru-in rule="if ( bgp-communities includes 65332:888 ) { accept } else { reject }"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
(log)
hardware offloading activated on bridge "bridge" ports: ether5,ether4,ether2,ether3
YesPPPoE Client?
Sure, but the message that it is activated is not related to that. It is related to bridge offloading and it was also there in v6.
Set your package channel to testing and install 7.1. Then reset the channel to stable and 7.1.3 should be there.I have 5009 with factory firmware 7.0.5 marked as stable.
When I click to "check for updates" and choose channel "stable" I still see only 6.49.3 ??
Channel: upgradeI have 5009 with factory firmware 7.0.5 marked as stable.
When I click to "check for updates" and choose channel "stable" I still see only 6.49.3 ??
Yes, it indicates that you are probably running something like MRTG to graph the temperatures (polled via SNMP). Every 5 minutes, when it asks for the temperature, problems occur.Unfortunately, all of the SFP+ ports are still flapping in 7.1.x for me, even with 7.1.3, on a CRS328-24P-4S+. Forcing the interfaces to 1G fixes the problem, but then I lose 10G. It happens at regular 5 minute intervals, which is extremely suspicious.
I do not have channel "Upgrade".
Channel: upgrade
Only "long term", "stable", "testing", "development", but only LT and stable sounds reasonable ;)
I am not; I have no external polling enabled. Same exact setup as v6.Yes, it indicates that you are probably running something like MRTG to graph the temperatures (polled via SNMP). Every 5 minutes, when it asks for the temperature, problems occur.Unfortunately, all of the SFP+ ports are still flapping in 7.1.x for me, even with 7.1.3, on a CRS328-24P-4S+. Forcing the interfaces to 1G fixes the problem, but then I lose 10G. It happens at regular 5 minute intervals, which is extremely suspicious.
Same here.This time my CCR1009-7G-1C-1S+ entered boot loop... 😳😢
Have not seen this in a long time myself.
For me such rules do work OK. I would advise trying to put the community in a community list and then reference that in the rule.this simple routing rule still does not work:
Code: Select all0 chain=cymru-in rule="if ( bgp-communities includes 65332:888 ) { accept } else { reject }"
The syntax for that is [[:name:]] (instead of 65332:888).
It fixed the problem for me when matching AS number.
NTP debug not helping:Hi,
Upgrading from 6.48.x to 7.1.x - NTP client not working... stuck on waiting.
seems others also having the same issue. viewtopic.php?p=914714
screenshot.2022-02-22 (3).png
I have checked my clock and it's the same as ever:I did notice after the upgrade bootup was at 1970, but never recovered.
- time: 10:37:31
date: feb/22/2022
time-zone-autodetect: no
time-zone-name: Africa/Johannesburg
gmt-offset: +02:00
dst-active: no
Any advice?
I haven't tried resetting the config as this is a production router.
I have that problem at every reboot, including the reboot required to do an upgrade.After upgrade from 7.1.2 my ipsec lost its identities.
I am at 7.2rc3 already so I am not going to test with 7.1.3 but in 7.1 and 7.1.1 these filters worked OK for me (and so they do in 7.2rc3).I already tried that, but that does not work either. I also tried to remove all the rules and recreate them, it does not work.
It's only the "bgp-communities includes 65332:888" part that does not work. If I change that for "gw == a.b.c.d", then the rule works.
I think it is a bug with upgrade v6->v7. My theory is like this:I did notice after the upgrade bootup was at 1970, but never recovered.
0 chain=cymru-in rule="if (gw == a.b.c.d ) { append bgp-communities 65332:888 }"
Ab B afi=ip4 contribution=active dst-address=23.135.225.0/24 routing-table=main immediate-gw="" distance=20 scope=40 target-scope=30 belongs-to="BGP IP routes from a.b.c.d"
bgp.peer-cache-id=*B000004 .as-path="65332" .communities=no-export,65332:888 .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x20302420
Fb afi=ip4 contribution=filtered dst-address=23.135.225.0/24 routing-table=main gateway=e.f.g.h immediate-gw=x.x.x.x%ether5_832 distance=20 scope=40 target-scope=30
belongs-to="BGP IP routes from e.f.g.h"
bgp.peer-cache-id=*B000001 .as-path="65332" .communities=65332:888,no-export .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x203023C0
set 1 rule="if ( bgp-communities includes 65332:888 ) { set blackhole yes; accept;} else { reject;}
I am at 7.2rc3 already so I am not going to test with 7.1.3 but in 7.1 and 7.1.1 these filters worked OK for me (and so they do in 7.2rc3).I already tried that, but that does not work either. I also tried to remove all the rules and recreate them, it does not work.
It's only the "bgp-communities includes 65332:888" part that does not work. If I change that for "gw == a.b.c.d", then the rule works.
I had some issues with numbers that were handled wrongly because of signed-unsigned mixup (so in that case 65532 would be handled as -4) and could fix that via the list workaround.
But that was for AS number, not community value, and in fact I am using community values that would be affected by such a bug.
So it apparently is something else. Unclear what.
Works fine here...Hi,
Upgrading from 6.48.x to 7.1.x - NTP client not working... stuck on waiting.
Detailed - thanks!I think it is a bug with upgrade v6->v7. My theory is like this:I did notice after the upgrade bootup was at 1970, but never recovered.
The MikroTik devices do not have a real time clock. What you normally see is a counter that counts timer interrupts, but it is not battery backed up.
Similar to the situation in a Raspberry Pi. Like that device, the current time is regularly stored in a file. So when the system reboots, it can start off where it last was.
In the Raspberry Pi there is a dedicated file for this, but in RouterOS they use the "configuration database", the binary file that holds all your configuration.
At startup the system reads the timestamp of that file and puts it as start value into the clock, and NTP then corrects that time.
However this configuration database is different between v6 and v7. When you first boot v7, the database does not exist and the time setting fails, time is now 1-1-1970 00:00 UTC.
Then, the "crossfig" program is started to convert the v6 database to a new v7 database and that is then used by the running system.
But everything the system does during this phase (e.g. converting items) is all timestamped 1970...
Now the time has to make a big jump, and NTP is always reluctant to do that. When it does not work at the first try it tends to give up on it.
It may depend on your network connection if this is going to work.
I would recommend to manually set the time to nearly OK and then check if NTP now attempts to sync it.
And hopefully MikroTik at some point revise the first boot v7 procedure to set the time from the v6 database that is being converted (e.g. inside the crossfig program).
In that case the 65332:888 community probably is not there...Hi pe1chl,
There's definitely something weird. I added a rule in the first place that adds the same community:
and now the other rule works for this peer, but not the other one:Code: Select all0 chain=cymru-in rule="if (gw == a.b.c.d ) { append bgp-communities 65332:888 }"
That is what I am expecting... NTP clients often take a big jump on the first request but not on later ones. So when the first request after boot does not get answered because first some link has to be established, it cannot make a large correction as required to recover from date 1-1-1970.Have seen this as well. Disabling and enabling the NTP client helped here.
Works for me. Please double check your configuration.still only one peer can use ipv6, not fixed*) wireguard - fixed IPv6 traffic processing with multiple peers;
No. I am using 7.1.3 and my hAP ac² always reboots when I try to shut it down. I haven't tested 7.2rc[23] yet.zapata - Do you mean that it is not working properly for you?
Are there still remaining issues where upgrading from an earlier version creates invisible internal problems that can be fixed by netinstall and configuring from scratch?Kindis, eworm, timnis - currently we have not managed to reproduce such an issue, however, we are trying to gather information in order to find a root cause of the problem. Most likely the issue is related to the version from which the router is upgraded, not the version to which it is upgraded;
I already have a ticket open, and have not seen any updates since Dec. 23: SUP-68278 which includes a supout file. I will add another one to it. Do you mind reviewing this?Kindis, eworm, timnis - currently we have not managed to reproduce such an issue, however, we are trying to gather information in order to find a root cause of the problem. Most likely the issue is related to the version from which the router is upgraded, not the version to which it is upgraded;
mafiosa, ormandj, egaspy, Rfulton, kwagga - Please provide supout file from the problematic router to support@mikrotik.com
borr, madejson, donline - Thank you for the report. We will look into this and try to resolve the problem in upcoming releases.
buset1974 - We are working on this all the time. Fixes and improvements are on their way.
mafiosa, pe1chl - Issue reported, we will try to resolve this problem as soon as possible.
dakkonsoulblade - We will look into this and try to see if there is anything we can do about this. Meanwhile please send console output to support@mikrotik.com.
wanarta - What exactly happened with configuration? Part of it is lost? Which part?
b10up, konradk, pe1chl - Seems like this routing problem is a known issue, we have already managed to reproduce it and will resolve it as soon as possible.
zapata - Do you mean that it is not working properly for you?
Reading the forum, which may or may not represent the truth :-), indicates that the firmware have been the issue not the ROS so I'm not 100 % sure. Upgrade path to v7 have been more or less smooth for me apart for a few hiccups with OSPF that where 100 % my fault! I will upgrade both ROS and firmware on a 3011 tonight and report back. Upgrade path for me will be 7.1.1 to 7.1.3.Are there still remaining issues where upgrading from an earlier version creates invisible internal problems that can be fixed by netinstall and configuring from scratch?Kindis, eworm, timnis - currently we have not managed to reproduce such an issue, however, we are trying to gather information in order to find a root cause of the problem. Most likely the issue is related to the version from which the router is upgraded, not the version to which it is upgraded;
E.g. is the bootloop issue, or the repeated loss of a section of the configuration, such an issue?
Is there any indication that these issues can and will be fixed in a future update?
It can be better for users to know that some things probably will never be fixed and that the way to get rid of them is to netinstall instead of update. Then at least we can prepare for it.
It works on 7.2c3 and Hap AC2.No. I am using 7.1.3 and my hAP ac² always reboots when I try to shut it down. I haven't tested 7.2rc[23] yet.zapata - Do you mean that it is not working properly for you?
Well, in my message I am not as much referring to issues in v7 that are the same for everyone.Reading the forum, which may or may not represent the truth :-), indicates that the firmware have been the issue not the ROS so I'm not 100 % sure. Upgrade path to v7 have been more or less smooth for me apart for a few hiccups with OSPF that where 100 % my fault!
Well you are lucky that your ticket is still open! I had ticket SUP-64360 open and later got confirmation from others that they had the same issue and also had a ticket open, but on Feb 11 it got closed with message "Your request status changed to Closed with resolution Done." without any info about what was done. So is this resolved, and if so in what version? Not in the current development version 7.2rc3, I can tell. But it was released on Jan 28, so that could be.I already have a ticket open, and have not seen any updates since Dec. 23: SUP-68278 which includes a supout file. I will add another one to it. Do you mind reviewing this?
My device was running RouterOS 7.1.2 with firmware 7.1.1 active (and firmware 7.1.2 pending a reboot) when I installed the update.Kindis, eworm, timnis - currently we have not managed to reproduce such an issue, however, we are trying to gather information in order to find a root cause of the problem. Most likely the issue is related to the version from which the router is upgraded, not the version to which it is upgraded;
This problem has been in RouterOS for ages, but you can work around it by passing the option -Cc to the snmpwalk call.Almost working ...
CHR 7.1.3
only 'OID not increasing' error left to be polished. nice, nice !!!
I made a capture, and the community is really here, see this screenshot:In that case the 65332:888 community probably is not there...Hi pe1chl,
There's definitely something weird. I added a rule in the first place that adds the same community:
and now the other rule works for this peer, but not the other one:Code: Select all0 chain=cymru-in rule="if (gw == a.b.c.d ) { append bgp-communities 65332:888 }"
Try tracing the BGP link using Packet Sniffer (filter with TCP port 179), save to file and examine using wireshark to see what is going on.
will wait for next release ...This problem has been in RouterOS for ages, but you can work around it by passing the option -Cc to the snmpwalk call.Almost working ...
CHR 7.1.3
only 'OID not increasing' error left to be polished. nice, nice !!!
I already tried that, but that does not work either. I also tried to remove all the rules and recreate them, it does not work.
It's only the "bgp-communities includes 65332:888" part that does not work. If I change that for "gw == a.b.c.d", then the rule works.
Mathieu
For me such rules do work OK. I would advise trying to put the community in a community list and then reference that in the rule.
The syntax for that is [[:name:]] (instead of 65332:888).
It fixed the problem for me when matching AS number.
I was brave enough to give it a try: Seems fine, no issues so far with the RB1100AH. Also CRS125-24G updated with no issues.I am more cautious with my RB1100AHx4 after the last update experience (firewall rules screwed up). Did any update this box?
We don't.How do we aggregate routes in bgp now?
Not fixed for me. See config example in viewtopic.php?t=180482#p914923*) wireguard - fixed IPv6 traffic processing with multiple peers;
With a filter. There’s an example in the help, but not quite the answer. You have to change that one.How do we aggregate routes in bgp now?
I talk about this: System->RouterBOARD->Settings->CPU freq (missing on 4011, after update)BrateloSlava - What do you mean by "CPU speed"? Do you refer to CPU usage under SYstem/Resources menu?
Are you sure you applied the chain to the input.filter on the connection to the peer?
I already tried that, but that does not work either. I also tried to remove all the rules and recreate them, it does not work.
It's only the "bgp-communities includes 65332:888" part that does not work. If I change that for "gw == a.b.c.d", then the rule works.
Mathieu
input.procid=20 .filter=cymru-in ebgp
Default behavior has changed from show-sensitive to hide-sensitive from ROS6 to ROS7.export is missing wireless security profiles details like PSK keys. In v6 export is working as expected
Microseconds (μs).Upgrade my devices, all working property, but, what is (xxxus) after (xxms) ping? i never seen that before upgrade. Thanks
Oh, thank you so much!, its possibe to disable or remove? thanksMicroseconds (μs).Upgrade my devices, all working property, but, what is (xxxus) after (xxms) ping? i never seen that before upgrade. Thanks
I doubt.Oh, thank you so much!, its possibe to disable or remove? thanks
Why?Oh, thank you so much!, its possibe to disable or remove? thanks
Works for me. Please double check your configuration.
still only one peer can use ipv6, not fixed
/ipv6 address
add address=fd02:28::1 interface=lo1
add address=fd02:29::1 interface=ep1
/ipv6 route
add disabled=no distance=1 dst-address=/0 gateway=fd03:1337::1 scope=30 target-scope=10
add disabled=no distance=1 dst-address=2000::/3 gateway=njalla scope=30 target-scope=10
/interface wireguard
add listen-port=51820 mtu=1420 name=ep1
/interface wireguard peers
add allowed-address=10.2.9.2/32,fd02:29::2/128 interface=ep1 public-key="NFxnCJgrsp/o87nTEXlfyfYdzy5RpD7Ysdx0jzcpwGU="
add allowed-address=10.2.9.3/32,fd02:29::3/128 interface=ep1 public-key="00ka4gYSojyUJuZipcmh/AYJwAQn2gKs/5QGZe4b2E4="
add allowed-address=10.2.9.4/32,fd02:29::4/128 interface=ep1 public-key="OKp0T9mnMi6uM2UO1T6u+Kzns9ylDAQHItTuC+zfwEQ="
add allowed-address=10.2.9.5/32,fd02:29::5/128 interface=ep1 public-key="eD+4f2PefzL3TakT7afLzxinHrEB06Y92jfbtWy+z1I="
add allowed-address=10.2.9.6/32,fd02:29::6/128 interface=ep1 public-key="tpkpl9xSDZL96SPmEawAi32Y2NRvDQYjOt+dAG1XOQQ="
add allowed-address=10.2.9.7/32,fd02:29::7/128 interface=ep1 public-key="URQWbJaNgjGDvBr0aXRk+7lfBQpRRPx3bA5+308tpyg="
add allowed-address=10.2.9.8/32,fd02:29::8/128 interface=ep1 public-key="Grbg3TtJ4YrGu4Lzi75SWuArWriJWqrgnAd2kZn4HXI="
/ipv6 firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=njalla src-address-list=njalla
/ipv6 firewall address-list
add address=fd02:28::/64 list=njalla
add address=fd02:29::/64 list=njalla
Quite accurate description. Upgrading from 6.x to 7.x is an experiment that I would not risk in a production environment. We use Mikrotik routers since more than a decade in an amateur radio envorinment at https://hamnetdb.net/?m=as&q=db0hup and even there we will not upgrade to 7.x. I haven't seen such a mess with upgrading before, not exactly a success story.Upgrading to 7.1.3 on RB1100AHx4 removed some of the device configuration. Lost part of the firewall, nat, mangle, static dhcp and other. This is beginning to threaten the functioning of the networks. The situation is simply catastrophic. The situation has not changed for last half year, RouterOS 7 is not working and has a huge number of bugs. Support is playing guess what release candidate will help, but there is no result.
Yesterday I upgraded RB3011 from 7.1.2 to 7.1.3 and it also ended to boot loop. Not sure which firmware there was installed, but in serial port console it was saying version "7". After netinstall I also updated firmware to 7.1.3 and it also shows version "7.1.3" on serial port console. So could this version "7" firmware cause the problem?My device was running RouterOS 7.1.2 with firmware 7.1.1 active (and firmware 7.1.2 pending a reboot) when I installed the update.Kindis, eworm, timnis - currently we have not managed to reproduce such an issue, however, we are trying to gather information in order to find a root cause of the problem. Most likely the issue is related to the version from which the router is upgraded, not the version to which it is upgraded;
All my other devices did not suffer any show stopper issues. I did all the upgrades (6.49.2 -> 7.1 -> 7.1.1 -> 7.1.2 -> 7.1.3) with auto-upgrade for firmware enabled.
Well, if that is the worst of your "problem"s... I guess you should be able to live with that.Update rb4011 from 6.49 to 7.1.3.
everything works fine, only 1 problem, i have 2-5% cpu usage at all times doing nothing.
Proof again you can't please all, everytimeWhy?Oh, thank you so much!, its possibe to disable or remove? thanks
I see that blackhole routes in the main table can be used to allow BGP to announce networks in bgp-networks list. Is that the best way so far or are there other ways or one that is less cumbersome? Any downsides to using BH routes to accomplish this?We don't.How do we aggregate routes in bgp now?
That is an interesting suggestion... that could be a workaround for us as well (we use aggregation for a large number of tunnels terminated at a single router).I see that blackhole routes in the main table can be used to allow BGP to announce networks in bgp-networks list. Is that the best way so far or are there other ways or one that is less cumbersome? Any downsides to using BH routes to accomplish this?
Power-off is only fixed in >= 7.2rc2. I am running testing branch until 7.2 (stable) is out. Thanks.No. I am using 7.1.3 and my hAP ac² always reboots when I try to shut it down. I haven't tested 7.2rc[23] yet.zapata - Do you mean that it is not working properly for you?
That sounds like a mistake in your configuration.Hi.
There is a lot of problems with Guest network. Same pass for Guest and private network? And than, guest pass become SSID for 2,4 GHz network. WTF
And also a lot of problems with scheduler. Not work properly. 7.x.x is total mess.
Device: RB4011.
The kernel does not allow them to be turned off, according to MikroTik support.SUP-75572 created accordingly.Code: Select all[admin@MikroTik] > /ip/firewall/service-port/disable dccp failure: module dccp is built-in and cannot be individually disabled [admin@MikroTik] > /ip/firewall/service-port/disable sctp failure: module sctp is built-in and cannot be individually disabled [admin@MikroTik] > /ip/firewall/service-port/disable udplite failure: module udplite is built-in and cannot be individually disabled
Finally, RB5009 switch chip is simply not able to handle dst-address related ARP traffic, while CRS317 has more advanced switch features, and so properly handles it.Strange issue on RB5009 where the following rule does not handle the related ARP traffic :No issue on (for example) CRS317.Code: Select all/interface ethernet switch rule add dst-address=192.168.192.200/32 new-vlan-id=100 ports=ether2 switch=switch1
SUP-74646 created accordingly.
Installing v.7.1.3 in Hap ac2 and keeping other end (750Gr3) in v.6.4X broke my IPSEC IKEv2 too. Gre-tunnel interface didn't go up despite established connectionDoes v7.1.3 give us working IPSec site-to-site tunneling between two ROS 7 devices?
Previous v7 releases stop routing traffic between two ROS7 devices after 10-15 seconds of establishing site-to-site tunnel. Tunnels work if either end is v6.x device though.
Can anyone confirm improvement in v7.1.3 IPSec?
For IPSec I found this viewtopic.php?t=176522Wireguard is working since the very first version of ROS7.
So it must be something in your config.
Start a new thread, provide all required details and export of config.
Disabling keep alive in Gre-Tunnel Interface was all it needed to have Gre-Tunnel up on both sides with v.7.1.2 and .v7.1.3. Though still no IP Sec connectivity. Will research more.Mikrotik has a Mik-only keepalive mechanism, so try disabling that.
Make backup first then try.Is it possible upgrade to 7.1.3 from 7.1beta directly without downgrade to V6?
Thanks.
I just edited my 2 posts above, got answer from your support team, many thanks Strods !benlg - What is the actual issue here?
@edupreI have a "PSU Fail" error in my CCR2116-12G-4S+ following this, the fans turn on and off and the system health show wrong reading. I have to restart the CCR to fix it. I wonder if the problem it hardware or firmware related. It happen sporadically and on all 7.x versions. Anyone can help with this?
IPsec-SA expired before finishing rekey: xxx.xxx.xxx.xxx[4500]<->MYIP.MYIP.MYIP.MYIP[4500] spi=0xc8379e9a
killing ike2 SA: NordVPN-CH MYIP.MYIP.MYIP.MYIP[4500]-xxx.xxx.xxx.xxx[4500] spi:0b7b960ee824441a:ddc090a26674e5ec
# mar/01/2022 12:09:29 by RouterOS 7.1.3
# model = CCR1016-12G
Same issue with my hAP acc³, system always reboots when I try to shut it down, instead in halt state condition.No. I am using 7.1.3 and my hAP ac² always reboots when I try to shut it down. I haven't tested 7.2rc[23] yet.zapata - Do you mean that it is not working properly for you?
19:20:06 system,info,account user XXXX logged in XXXX via winbox
19:20:27 interface,info ether1 link down
19:20:27 interface,info ether2 link down
19:20:27 interface,info ether3 link down
19:20:27 interface,info ether5 link down
19:20:27 interface,info ether7 link down
19:20:27 interface,info sfp9 link down
19:20:28 interface,info sfp9 link up (speed 1G, full duplex)
19:20:28 interface,info ether7 link up (speed 100M, full duplex)
19:20:29 interface,info ether2 link up (speed 1G, full duplex)
19:20:29 interface,info ether5 link up (speed 1G, full duplex)
19:20:29 interface,info ether1 link up (speed 1G, full duplex)
19:20:30 interface,info ether3 link up (speed 1G, full duplex)
19:20:50 system,info,account user XXXX logged out from XXXX via winbox
It is a known problem that you cannot upgrade to 7.x (which is single-package) on a router where multiple packages were installed, on devices with only 16MB of flash.RBcAPGi-5acD2nD (cAP ac): Upgrading from 6.49.3
Unfortunately the space of the cAP ac is too small for doing an easy in-production update. Of course, all files (e.g. logs) were removed before to gain some more free space.
I needed to delete all packages until only the system package was left. Then I was able to do the upgrade.
*) wireless - correctly preserve WMM priority when receiving packets;
I guess people asking these kind of questions are the first ones, that cry out load when a long-term isn't as bug-free as they take for granted.Hi, when 7.1 version Long Term? Thanks
I'm having the same problem. Have two CRS328-24P-4S+ in a very low network usage warehouse area. After upgrade last night to 7.1.3 things were bad. SFPs reported link downs and throughput to connected devices dropped as well. Interestingly, the CSS610 these switches were connected to reported no link downs. Running 6C-SFP+-LR SFPs. No problems in 6.49.x. Booted both switches to SwOS and all is well. No flapping and nothing monitoring down in the hour or so it's been since rebooting into SwOS.Unfortunately, all of the SFP+ ports are still flapping in 7.1.x for me, even with 7.1.3, on a CRS328-24P-4S+.
For chateau and rb5009 owners, 7.1 is the minimum supported version.Hi, when 7.1 version Long Term? Thanks
Sorry, it is a confirmed problem, see e.g. SUP-66267 which has been "Closed with resolution Done" but it is not specified what is the proper way of avoiding the problem.pe1chl - You can upgrade directly from v6 to v7 from separate packages, if you have enough space for v7 and your configuration, and stored files.
@strods No packet loss.mada3k - Are you sure that all of them are missing, not just a part of them? Please write to support@mikrotik.com and send supout file from your router.
leosedf, PSz, mcskiller, avaz - Please send supout file from your router to support@mikrotik.com.
sebasGST - Simple definition from Wikipedia - "A microsecond is an SI unit of time equal to one millionth (0.000001 or 10^−6 or 1⁄1,000,000) of a second. Its symbol is μs, sometimes simplified to us when Unicode is not available. A microsecond is equal to 1000 nanoseconds or 1⁄1,000 of a millisecond.". No, it is not possible to change this behavior.
borr, elbob2002, akarpas, edupre, qatar2022, smyrosnik, smyrosnik - We will look into this.
Patrinus - Please send supout file from your router to support@mikrotik.com. We have fixed a similar problem with UPnP. However, it was fixed after this build was created.
BrateloSlava - Yes, it is not possible to disable these few helpers as explained in the error message.
ksteink - In 99% of cases like this, the problem is communication between computer and router, not the GUI itself. Is it possible that there is a packet loss un this connection?
Cray - In general, IPsec is working just fine in this version. If you still experience this problem, then please provide supout file to support@mikrotik.com from both endpoints of this IPsec connection. Make sure that files are generated after the connection was lost without any apparent reason.
AshuGite - It seems that we have managed to resolve this problem. The fix should be included in all of the upcoming releases.
starfotr - Please provide actual examples to support@mikrotik.com. Provide supout file and detailed description of what is missing after an upgrade. We have not received any complaints like this from anyone else.
benlg - What is the actual issue here?
dakkonsoulblade - Does this device have a serial port?
Tporlapt - This will be fixed in the upcoming releases.
stevekwok - Yes, it is. Why do you think that a downgrade is necessary before an upgrade?
strods any update about ticket 67221 and 45619 (same issue)?pe1chl - My colleague replied to you and did not receive any answer from you for 90 days. Then the ticket is automatically marked as done. The ticket is done, not the issue. The only issue here is a problem with ARM devices with separate packages on v6 and only when you are living on the edge (regarding free disk space). Unfortunately, we can not fix this problem, because the upgrade happens on the old version, not the one which is being installed. We can not install fix on old versions so this is one exception where you will either need to uninstall one package and then upgrade or re-install the router. For example, on your example, you can uninstall the wireless package and upgrade to v7.
ksteink - Then please provide supout files from the server and client to support@mikrotik.com
Some new news about the issue itself??????rpingar - We would really appreciate it if you and anyone else would not create duplicate tickets regarding the same problem. First of all, it makes a double work, second of all that fragments information, if both tickets are not processed by the same support employee. And in the end, it slows down the process, not boosts it up. The reply is provided as soon as possible. If there are any news, we deliver them to you. We do not have any intention to delay ticket processing.
The reply is provided as soon as possible.
I understand that the root of the problem is in the old version, but you should understand that these installs (separate packages on a 16MB Flash ARM system) can still be upgraded to a newer version with the same structure. I.e. an upgrade to 6.49.4 works just fine, and it remains separate packages. However, when a combined package of 6.49.x is uploaded to a router which has separate packages installed, it fails.pe1chl - My colleague replied to you and did not receive any answer from you for 90 days. Then the ticket is automatically marked as done. The ticket is done, not the issue. The only issue here is a problem with ARM devices with separate packages on v6 and only when you are living on the edge (regarding free disk space). Unfortunately, we can not fix this problem, because the upgrade happens on the old version, not the one which is being installed. We can not install fix on old versions so this is one exception where you will either need to uninstall one package and then upgrade or re-install the router. For example, on your example, you can uninstall the wireless package and upgrade to v7.
Hello,
Thank you, indeed there is an issue with hap ac2, we will check and fix it asap.
Thanks again.
That is a reason why I do not understand why in the forum release topic, when people describe problems so that everyone can read them and avoid reporting the same thing, it is always emphasized that problems should be reported in tickets.rpingar - We would really appreciate it if you and anyone else would not create duplicate tickets regarding the same problem. First of all, it makes a double work, second of all that fragments information, if both tickets are not processed by the same support employee.
Report. OpenVPN connection in UDP mode on CCR1009-7G-1C-1S+ still causes CCR1009 to reboot, like on 7.1.2 version.
Very bad.
You can force the ports to 1G and that seems to work as well. Based on the response a few posts prior, it sounds like they want you to create a support ticket, which is hilarious since they literally just asked us not to create duplicate support tickets at the same time, and I already have a ticket open for this, with no response in over three months.I'm having the same problem. Have two CRS328-24P-4S+ in a very low network usage warehouse area. After upgrade last night to 7.1.3 things were bad. SFPs reported link downs and throughput to connected devices dropped as well. Interestingly, the CSS610 these switches were connected to reported no link downs. Running 6C-SFP+-LR SFPs. No problems in 6.49.x. Booted both switches to SwOS and all is well. No flapping and nothing monitoring down in the hour or so it's been since rebooting into SwOS.Unfortunately, all of the SFP+ ports are still flapping in 7.1.x for me, even with 7.1.3, on a CRS328-24P-4S+.
Confirmed on hAP AC2 (arm) running 7.2rc4, both wlan1 (2Ghz) and wlan2 (5Ghz)Can anyone reproduce that WMM thiny on a wireless device too?
That's another discussion.I always have wmm support enabled. Why would you want to turn that off???
Not worried at all.Well, when you are so worried about it being enabled, you should be able to see the effects of it on the outside, right?
Connect a client that cannot handle wmm and that will fail, or connect and check the status in the client (is it using wmm?).
As this change also was introduced on 7.2rc4, maybe is related.) wireless - correctly preserve WMM priority when receiving packets;
We have tons of these in service and have no issues with any 7.x builds. are you doing any special configs and what power supply are you using (we use 48v)CRS112-8P-4S: Not usable after upgrade from 6.49.3 to 7.1.3 (soft- and firmware)
Working for some minutes after booting, then ports are starting to flapp and the data transfer between the clients is interrupted permant.
No further errors / information in the log.Code: Select all19:20:06 system,info,account user XXXX logged in XXXX via winbox 19:20:27 interface,info ether1 link down 19:20:27 interface,info ether2 link down 19:20:27 interface,info ether3 link down 19:20:27 interface,info ether5 link down 19:20:27 interface,info ether7 link down 19:20:27 interface,info sfp9 link down 19:20:28 interface,info sfp9 link up (speed 1G, full duplex) 19:20:28 interface,info ether7 link up (speed 100M, full duplex) 19:20:29 interface,info ether2 link up (speed 1G, full duplex) 19:20:29 interface,info ether5 link up (speed 1G, full duplex) 19:20:29 interface,info ether1 link up (speed 1G, full duplex) 19:20:30 interface,info ether3 link up (speed 1G, full duplex) 19:20:50 system,info,account user XXXX logged out from XXXX via winbox
Downgrade to 6.49.x solved the issue.
Update: Port flapping tested and reproducible with several CRS112-8P-4S. Disabling auto-negotiation didn't help.
Yes, probably there was some mistake while implementing that.As this change also was introduced on 7.2rc4, maybe is related.) wireless - correctly preserve WMM priority when receiving packets;
That is another problem, but I mentioned that elsewhere.And it is not like at other vendors, that WMM just works by just enabling it. In ROS you need to use mangle rules, queue tree and need to adjust ampdu priorities to get it even work properly.
We have tons of these in service and have no issues with any 7.x builds. are you doing any special configs and what power supply are you using (we use 48v)CRS112-8P-4S: Not usable after upgrade from 6.49.3 to 7.1.3 (soft- and firmware)
Working for some minutes after booting, then ports are starting to flapp and the data transfer between the clients is interrupted permant.
No further errors / information in the log.
Downgrade to 6.49.x solved the issue.
> system/resource/usb/print
Columns: DEVICE, VENDOR, NAME, SPEED
# DEVICE VENDOR NAME SPEED
0 1-0 Linux 5.6.3 ehci_hcd RB400 EHCI 480
1 1-1 American Power Conversion Back-UPS RS 550GI FW:857.L1 .I USB FW:L1 12
> system/ups/add port=serial0
alarm-setting check-capabilities comment copy-from disabled min-runtime name offline-time
uptime: 1w5d13h27m42s
version: 7.1.3 (stable)
build-time: Feb/11/2022 19:20:55
factory-software: 7.0.9
free-memory: 174.4MiB
total-memory: 256.0MiB
cpu: ARMv7
cpu-count: 4
cpu-frequency: 716MHz
cpu-load: 1%
free-hdd-space: 2092.0KiB
total-hdd-space: 15.2MiB
write-sect-since-reboot: 90890
write-sect-total: 91932
bad-blocks: 0%
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
How to know exactly what's writing to that flash ?
What about DNS cache? In particular with DOH enabled?
Mine is writing to flash every hour. It's a reasonable compromise, between keeping history and flash usage. It isn't much, anyway...I have the graphing setup to write to memory instead of disk. So it will only have graphs for the current uptime. It would be nice if you could write the graphing data to an sd card, but it's ok.
mada3k - Are you sure that all of them are missing, not just a part of them? Please write to support@mikrotik.com and send supout file from your router.
leosedf, PSz, mcskiller, avaz - Please send supout file from your router to support@mikrotik.com.
sebasGST - Simple definition from Wikipedia - "A microsecond is an SI unit of time equal to one millionth (0.000001 or 10^−6 or 1⁄1,000,000) of a second. Its symbol is μs, sometimes simplified to us when Unicode is not available. A microsecond is equal to 1000 nanoseconds or 1⁄1,000 of a millisecond.". No, it is not possible to change this behavior.
borr, elbob2002, akarpas, edupre, qatar2022, smyrosnik, smyrosnik - We will look into this.
Patrinus - Please send supout file from your router to support@mikrotik.com. We have fixed a similar problem with UPnP. However, it was fixed after this build was created.
BrateloSlava - Yes, it is not possible to disable these few helpers as explained in the error message.
ksteink - In 99% of cases like this, the problem is communication between computer and router, not the GUI itself. Is it possible that there is a packet loss un this connection?
Cray - In general, IPsec is working just fine in this version. If you still experience this problem, then please provide supout file to support@mikrotik.com from both endpoints of this IPsec connection. Make sure that files are generated after the connection was lost without any apparent reason.
AshuGite - It seems that we have managed to resolve this problem. The fix should be included in all of the upcoming releases.
starfotr - Please provide actual examples to support@mikrotik.com. Provide supout file and detailed description of what is missing after an upgrade. We have not received any complaints like this from anyone else.
benlg - What is the actual issue here?
dakkonsoulblade - Does this device have a serial port?
Tporlapt - This will be fixed in the upcoming releases.
stevekwok - Yes, it is. Why do you think that a downgrade is necessary before an upgrade?
This seems related to my issue, after a couple of hours, winbox keeps kicking me off the device when trying to connect. Only a hard reboot lets me get in again.RB5009UG+S+ version v7.1.3 hotspot captive portal all pages turn to status 404 after couple of hours. even reset html has also the same error after 2-5 hours. I want to downgrade to 6.48.6 but i cant. please fix this. i tried netinstall to downgrade but not working. minimum version requires is only v7.0.9.
Thanks for sharing and glad to hear that I am not the only one with this issue!. Hope like 7.2 gets fixed both issuesI have a RB4011 and while I do not see the reboot due to kernel failure, I did see the "all the IPSec Identities are basically erased" problem.
It seems to have been solved for me at installation of 7.2rc4 but I did a fresh netinstall and load of the configuration I exported before (not backup, export).
I don't know if it is 7.2rc4 that fixed it or the fresh start. The 5009 kernel failure reboots are a common problem.
On RB750Gr3, and I just upgraded to 7.1.3 from 6.49.5.
It is advisable to do a export (remember show-sensitive), download the exported file, then completely netinstall the router with format (no keep configuration) and reset it to clean state (no default config) and import the exported file again. It sometimes needs minor tweaks using a text editor to accept everything.Version 7.1.3 is definitely NOT stable. It crashes at my RB3011UiAS at least twice a day, and it is just during regular network operations, no changes are made at the router at that time. That's why I cannot really identify where it is crashing in particular, it just looks like a memory leak or something.
It was rock solid before the upgrade from 6. After the upgrade
Though not configured graphing, I did increase the setting to 24h - as "never" is not a valid option.Yes, writing of /tool/graphing is every 5 minutes as well. Can be changed to "never" or "24h" for example.
Setting this to never and graphing every 24h. I now have about 50 flash writes per hour. Where do these come from? I can't find anything suspicious in a /export verbose. Is this something that can't be lowered? Why are there disk-writes?/ip/dhcp-server/config/store-lease-disk seems to be 5m by default. I changed that to "never" and we'll see of that brings down write-sect numbers. I do not care for DHCP leases to survice reboots either.
The router received that route via ospf.Why the routing table shows the connected interfaces as DIUoH?
I did exactly that with our Metal 52ac access point but it keeps going down every few hours. I tried downgrading to long-term (7.1) but to no avail, it still does the freezing. Devices are connected to the wireless AP, cables are fine and ether1 is up with internet, but then suddenly it loses connectivity internally. The wireless link is still there between client and AP, the router still sees the Metal 52ac just fine, I can ping its bridge IP, but internet is gone. I fear this is related to memory or queue changes. I have set it entirely back to defaults a week ago, still happens.It is advisable to do a export (remember show-sensitive), download the exported file, then completely netinstall the router with format (no keep configuration) and reset it to clean state (no default config) and import the exported file again. It sometimes needs minor tweaks using a text editor to accept everything.Version 7.1.3 is definitely NOT stable. It crashes at my RB3011UiAS at least twice a day, and it is just during regular network operations, no changes are made at the router at that time. That's why I cannot really identify where it is crashing in particular, it just looks like a memory leak or something.
It was rock solid before the upgrade from 6. After the upgrade
After that, all traces of your previous v6 install are gone and it tends to become more stable after that.
It is clear that he gets this route by ospf. But why does it show it at all?The router received that route via ospf.Why the routing table shows the connected interfaces as DIUoH?
It had been discussed multiple times: the fix for routing performance drop is not coming. Live with it.... My real-life scenario involves transferring large files across the router. I need a fix. In the meantime, I rolled back to 6.49.5, and it works fine.It's been said numerous times: in ROS v7 underlying routing engine is changed, it doesn't use route caches any more. This can affect routing capacity, specially if traffic uses only a few routes. That's particularly true when running speed tests or large file transfers between different LANs, but in usual real-life scenarios the difference is not so big. And for the same reason CPU load does increase.
I hear you loud and clear. What I'm trying to say (and obviously failed to make it clear) is that observed performance did not match the published diagrams. And behaviour changed recently (not sure about exact ROS versions as I don't have first hand experience with hEX). The thread I linked is not really about your case, but illustrates that you should not blindly rely on diagram alone.Maybe I'm not being clear. I'm trying to engage the no-switch version, but it doesn't seem to work.
No it is a change in the export command not explained well in the documentation.AS you can see there is no IPsec secret neither password.
It is a bug in export commmand.
It is advisable to do a export (remember show-sensitive), download the exported file, then completely netinstall the router with format (no keep configuration) and reset it to clean state (no default config) and import the exported file again. It sometimes needs minor tweaks using a text editor to accept everything.
After that, all traces of your previous v6 install are gone and it tends to become more stable after that.
this is the contingency plan. They won't let me buy equipment to test on, and they don't care when a site is down.My advice: roll back ... and prepate contingency plan for the next time.
this is the contingency plan. They won't let me buy equipment to test on, and they don't care when a site is down.My advice: roll back ... and prepate contingency plan for the next time.
Next time study the topic of "partitioning a router" before you do such an upgrade.this is the contingency plan. They won't let me buy equipment to test on, and they don't care when a site is down.My advice: roll back ... and prepate contingency plan for the next time.
yea, read the release notes a few times. thanks for being a troll. hurr durr RTFM.Next time study the topic of "partitioning a router" before you do such an upgrade.
this is the contingency plan. They won't let me buy equipment to test on, and they don't care when a site is down.
Or read the release topic before you begin.