Hello,

I have a CCR1016-12G running 6.0rc7 and just experienced loss of ipv4 service. This is the first time I've run a deployed Microtik which had seemed to hold up well in testing, but has run into this issue after just under 1 week in production.

After being alerted to the issue I was unable to access it via the internal network or external on IPv4.

I have IPv6 enabled on the router and was able to connect via ipv6.

Attempting to ping anything over ipv4 resulted in:
The router was doing about 1mbit/s of traffic, no cpu.
I did a /system reboot and the IPv4 worked again.

I am using bgp, netflow services and have a minimal configuration (2 vlans with two sets of 4 bridged ports (8 total) plus uplink.

The buffer issue seems similar to what others have experienced here. Is this a known issue, and if so what is the fix?

In addition, are there any best practices for troubleshooting or grabbing log data when an issue like this occurs that would be helpful for further troubleshooting?

Thanks

I have the same problem with the buffer, but on the x86 core I7-2600K 3600 with RouterOS 6.0r11.
on this router works:
BGP: 4 session fullview and three session localpeers
Traffic around 250000pps in each direction, 1.7 GGb include 500Mbit NAting


I dont know what I can do to solve this problem , because on ROS 5.14 all work good.

I've been back and forth with Mikrotik support on this for weeks, open case - so far no solution. Have tried beta rc12 and it happens there as well.

I'm suspecting a hardware related issue as this only happens on one unit and not others with identical configuration.

We fixed this problem in one of the latest rc12 builds. Contact support to get newer build.

That's great, I've just requested an update in my ticket.

I think i might also be hitting this bug on a CCR, just after booting, i can only do an ARP ping on the router IP but i cant do ICMP ping and connect to TCP but sometimes after unplugging and replugging the cable (cat 6 SFTP non crossed cable) it comes back to life but not always... (but a bridge is still routing without any problem, only access to the CCR IP doesnt works), it seems to do that about 1/2 times i reconnect a cable.

---
ps: i think i found the bug origin, it must be a different bug afterwise.

I had two ports configured with IPs on the same subnet but which were not both connected to the same network, it seems that the preffered route wasnt always the right one (not sending packets to the port connected to the network from which the packets were originated), it happens even if the second port have no link.

In my case, i did have a bridge on ether1 & ether2 configured with 192.168.2.220/24 and ether3 was configured with 192.168.2.221/24, when i changed the IP on ether3 to 192.168.20.201/24, i couldnt access anymore to the router from all the 3 ports, i had to disable/enable the IP from the touchscreen to get the network back.

But good news, the initial problem seems to be gone.

We fixed this problem in one of the latest rc12 builds. Contact support to get newer build.

Unfortunately this appears to still happen for me with the latest build:

version: 6.0rc12
build-time: Mar/18/2013 14:38:02

Unfortunately this is still happening, even in the latest build:
This happens on numerous CCR1016-12G that we have. It does not happen (thankfully) on CCR1036-12G-4S as of yet.

Unfortunately I mist surmise that Mikrotik isn't ready for prime time yet when it comes to basic IP type use (multiple bgp tables + ipt @ edge) as I was hoping. (A ccr with 10g that is rock solid was something that really peaked our interest and got us looking seriously @ the platform.)

Got this message on 6.0RC13

Do you have netflow enabled?

Have been working back and forth with mikrotik support on this - it boils down to netflow. They sent me a patched RC14 version but that stops all bgp from working. AS of now I've run ~5 days (the longest) w/o netflow and haven't seen a crash. Will get back to testing the latest RC since netflow is critical to our operations.

Note: after disabling netflow, we still experienced a crash. After that crash w/ it disabled it hasn't occurred again, so you may want to disable and reboot if you had it enabled.

Another thought: I think this may potentially be related to your throughput, since we see the crash more frequently on busier devices.

this is still happening in 6.40.4 version on CRS125-24G-1S.

It works as OpenVpn server. About 50 interface connected for a week and when cache is about 25%-30% the ipv4 gets lost. Bandwith engaged is 5Mb/s. No CPU.

I had to schedule a script to reboot when cache capacity(that grows day by day) reaches 20%.

Any idea when this will be solved?

issue still persisting in V6.42.3.

Any idea if will be ever taken in charge?

issue still persist in the latest versions.

Any idea if this will be at least mitigated?

Hi,
I got this situation on my router with ROS 6.43.14 (long-term)

Situation is even worse with the ROS 6.43.14 (long-term).
I am forced to script a reboot on 8% usage of

/ip route cache get cache-size

.

This is not acceptable, I am forced to reboot once a day disconnecting all VPNs.

You will have to hope that version 7 is released in stable form soon.
Depending on your usage of the router, it may be possible to test with the beta version.

You will have to hope that version 7 is released in stable form soon.
Depending on your usage of the router, it may be possible to test with the beta version.

Thanks a lot for your answer pe1chl!

Unfortunately, I discovered the issue when the environment was already serving 46 customers, and today they increased decisively.
It's not an option to test a beta version with them.

Reboot script is still less impacting than disasters that could happen using a beta version.

The decision to run the v7 beta probably depends more on the available feature set (not all features are available) than on stability.
The stability likely is OK (I have not seen frequent complaints about that) but it simply may not be able to do what you need.
(when your router is only OpenVPN server it will likely be no problem)

The decision to run the v7 beta probably depends more on the available feature set (not all features are available) than on stability.
The stability likely is OK (I have not seen frequent complaints about that) but it simply may not be able to do what you need.
(when your router is only OpenVPN server it will likely be no problem)

Are you aware of any improvements from this standpoint, or any changes in the implementations of this feature, so I can hope to correctly address the issue?

Mine is just an OVPN/L2TP server, including big number of netmaps and Mangles

Well, the newer Linux kernel used in v7 does not support the IP route cache anymore, so this known problem no longer should occur.
There also are other improvements in OpenVPN on v7.