v7 CRS2116 IP-routing stuck after router generates autosupout.rif

RouterOS RouterOS beta
1

Hi,

do you have a hint what may cause latest v7.10.x to stop routing traffic after the CCR generates an autosupout.rif file?
/log/print shows no message for this event.
/routing/route/print freezes with no output after the autosupout.rif file has been generated.

Have to reboot the CCR device every few days due to this error. Very annoying.

Thanks for hints on debugging.

2

I found issues with full BGP tables and high throughput causing sluggishness etc. on 7.10. I loaded 7.11b5 the other day (or 6, whatever the version was before the 24th) and I saw significant improvements in my 2116’s. You might give that a try.

3

sirbryan, thanks for your hint.

The CCR2116 router having the IP-routing gone stuck bug after generating an autosupout.rif is only running a BGP table of a few hundred routes. So it should be no load issue. Nonetheless, I’ve upgraded the device to 7.11b7; it’s worth a try.

Off-topic: Another CCR2116 device running a full BGP table on 7.10 is causing sluggishness with 100% load on one CPU after enabling an input route filter. Has this issue been fixed using 7.11b5 or newer?

4

What’s the filter? I’ve got three inbound filters and they work fine:


if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 95; accept; } # local-pref depends on the peer
if (afi ipv6 && dst in ::/0 && dst-len == 0) { accept; }. # only want default for IPv6 for now
if (bgp-path-len in 1-2 ) {set bgp-local-pref 95; accept; }. # Only allow up to 2 AS's away from us
5

That’s the input filter on external IPv4 BGP4 peers:

add chain=NO-RFC6890-V4 rule="if (dst == 0.0.0.0/0 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 0.0.0.0/0 && dst-len in 25-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 10.0.0.0/8 && dst-len in 8-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 172.16.0.0/12 && dst-len in 12-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 192.168.0.0/16 && dst-len in 16-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 127.0.0.0/8 && dst-len in 8-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 100.64.0.0/10 && dst-len in 10-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 169.254.0.0/16 && dst-len in 16-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 192.0.0.0/24 && dst-len in 24-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 192.88.99.0/24 && dst-len in 24-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 198.18.0.0/15 && dst-len in 15-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 198.51.100.0/24 && dst-len in 24-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 203.0.113.0/24 && dst-len in 24-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 224.0.0.0/3 && dst-len in 3-32 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst == 255.255.255.255 && afi ipv4) {reject}"
add chain=NO-RFC6890-V4 rule="if (dst in 0.0.0.0/0 && dst-len in 1-24 && afi ipv4) {accept}"
6

@sirbryan can confirm that this bug is gone upgrading to the latest v7.11b7. Thanks for your hint.

7

Update: Unfortunately upgrading the CCR2116 to pre-releases of v7.11 did not fix this issue. Log shows the error message:
script error: action timed out - try again, if error continues contact MikroTik support and send a supout file (13)

Hint: To fix the issue a device reboot is required.

Opened a support ticket a few weeks ago uploading all meanwhile collected supout files. But: No response or feedback from MikroTik, yet.

Does anyone have a hint how to debug this error?

Thanks.