Yes it is still an old code, but we did some major fixes.

Thanks for your reply.
But what about the bug this thread is about? Is it fixed?

I would like to know that too...

I tried to reproduce bug in lab without success, someone get?

Yes it is still an old code, but we did some major fixes.

I tried to reproduce bug in lab without success, someone get?

During lab testing yesterday I was able to reproduce (but its not consistent) - will try push v6rc11 to the units and see if I can get it to break again

This bug has cost me customers in the past and we're now considering alternatives ourselves. Its just been there too long without meaningful interactions sadly.

During lab testing yesterday I was able to reproduce (but its not consistent) - will try push v6rc11 to the units and see if I can get it to break again

This bug has cost me customers in the past and we're now considering alternatives ourselves. Its just been there too long without meaningful interactions sadly.

Let me know about your tests with v6rc11

Well, I`m not sure if my post can be considered as forum rule breaker but by the way. There it goes.

To start, I would like to say that Mikrotik products are great, just their SUPPORT on routing package is not good enought, sadly.

Looking for a solution to my problem related with that bug and time took by mikrotik or solve it, I started a test on low cost router running vyatta, called EdgeMax Lite and results are great so far! IMPORTANT: Low cost, not a core router and no full bgp table, no MPLS, but with ipv6, ospfv3 and ospf.

Once mikrotik releases their new routing package I will be happy to come back and try it again!

Same problem here. We are connected with two BGP Speaker's (BGP1, BGP2) and when BGP2 goes down we are unable go out across BGP1. Because of Mikrotik's cache the thing keep trying to send across BGP2. BGP2 has the full route table and BGP1 has only the default route.

Device is CCR1036 with RouterOS version 6.0rc13.

I can confirm (partial) what you are seeing. Our CCR (RC13) is connected to several peers. As soon as I shutdown the session to one peer (with active route), the route disappears completely from the Route List, even though I get this route over serveral(!) other peers too.

All routes which get into the main routing table will never be replaced by routes learned from other peers. Even if one resets the peerings. The router has to be restarted (restart of the BGP instance won't help)...

- Mat

The problem that developers are not knowing what to do, and do not want to pay a professional trained to solve problems. Ai is that of trying to hit, so more are missing.
How to use a CCR 1036 as BGP and traffic of 300mgs?
For CCR 1036 not even have 20% of the stability of a RB1100.

What's new in 6.0rc14:

*) route - automatically repair FIB inconsistencies;

I wonder whether it will fix those 'stuck routes'...

What's new in 6.0rc14:

*) route - automatically repair FIB inconsistencies;

I wonder whether it will fix those 'stuck routes'...

Finally, let's test it.

Enviado de meu GT-N7100 usando o Tapatalk 2

Yep, I noticed that too a few days back. I'm going to test it later this week since we can reliably produce the problem.

What's new in 6.0rc14:

*) route - automatically repair FIB inconsistencies;

I wonder whether it will fix those 'stuck routes'...

This fix should potentially fix the problem when BGP route is withdrawn from routing table, but router still routes packets via that non existent route.

This fix should potentially fix the problem when BGP route is withdrawn from routing table, but router still routes packets via that non existent route.

Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.

Thanks,

-- Nathan

Hi Maris,

Should 6.0rc14 fix the issue with stale routes inside VRF's ?

e.g. routes received via L3VPN.


Regards,




Andrew

What's new in 6.0rc14:

*) route - automatically repair FIB inconsistencies;

I wonder whether it will fix those 'stuck routes'...

This fix should potentially fix the problem when BGP route is withdrawn from routing table, but router still routes packets via that non existent route.

/me impatiently waits for the RC download to complete.....

Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.

-- Nathan

Agreed!! Please, if fix really works make a 5.x version!
I can test RC at one or two routers, but not on production net.

By the way, when or where it's avaliable to download? while looking into download section I have found rc13 only.

Jorge

You can contact support to get pre release version.

This fix should potentially fix the problem when BGP route is withdrawn from routing table, but router still routes packets via that non existent route.

Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.

+1
thanks.

Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.

+1

I know rc14 was just recently released, but has anyone been able to reproduce the whole issue again with stuck routes?

We do OSPF peering with our data center with 2 routers in a separate OSPF instance. We then redistribute the default route to our internal OSPF instance.
We have huge issues with the default route from the wrong instance becoming stuck in the routing table. (the proper default route didnt replace it like it should, it was blue in the routing table)

v6 build 17/May/2013 14:04:20

Default route still gets stuck...

I can confirm the issues we were having with stuck BGP and OSPF routes have been resolved by this release.

We still have a number of issues with route filters and have opened a ticket with Mikrotik but so far have had no respinse.

I can confirm the issues we were having with stuck BGP and OSPF routes have been resolved by this release.

We still have a number of issues with route filters and have opened a ticket with Mikrotik but so far have had no respinse.

I have problems with filters too. Sometimes if I copy a filter it`s doesn`t work. I need to configure a new filter from scratch to work.

I have problems with filters too. Sometimes if I copy a filter it`s doesn`t work. I need to configure a new filter from scratch to work.

Yes. This is one of the issues. We also found even on new filters sometimes you need to disable/enable them to get them to work. (Yes even with bgp peer refresh)

I did some more testing, and never mind, the issue still persists.

As soon as I take down the datacenter OSPF instance, and then bring it back up, the old default route is still stuck in the routing table.
You can see in the screenshot that the route with distance 121 is installed in the routing table as the default route, altho there is a better route with distance 20, that is blue in the routing table, and not used.

I am very unhappy now...

tomaskir best email support@mikrotik.com and let them know. I doubt they will see it here

tomaskir best email support@mikrotik.com and let them know. I doubt they will see it here

Emailed the second I posted
Lets just hope it gets fixed.

I did some more testing, and never mind, the issue still persists.

As soon as I take down the datacenter OSPF instance, and then bring it back up, the old default route is still stuck in the routing table.
You can see in the screenshot that the route with distance 121 is installed in the routing table as the default route, altho there is a better route with distance 20, that is blue in the routing table, and not used.

I am very unhappy now...

hello

what you show is a default route in instance VNET and a default route in instance DEFAULT
may be coming from this

a+
Thierry

hello

what you show is a default route in instance VNET and a default route in instance DEFAULT
may be coming from this

a+
Thierry

Yes, we peer with datacenter in a separate OSPF istsance, and then have our own internal OSPF instance.
Both instances redistribute a default route, for redundancy in case something fails.

But as you can see, the default route from the wrong instance gets stuck in the routing table when its supposed to go away.
This of course happends only if the datacenter link goes down and then back up.

you have two routes from different OSPF instances installed in the routing table, both with the same distance. the choice is 'random', as far as I remember from docs. you may use routing filters to decrease distance of your preferred default route

you have two routes from different OSPF instances installed in the routing table, both with the same distance. the choice is 'random', as far as I remember from docs. you may use routing filters to decrease distance of your preferred default route

They dont have the same distance. One is distance 20, the other 121 in OSPF Routes.
They get installed in the routing table with distance 110, because that is default for OSPF routes.

Here is the exactly same router, all I did was reboot it:

you write to support@mikrotik.com and wait for response. they will say when they fix what you need

Or nothing at all...

Ticket#2013050266000072
Ticket#2013043066000404

Bad news guys - x86 RouterOS 6.0 still has the route cache bug.

We receive a customer route via EBGP (1); forward it internally on our IBGP (2) to one of our peering edges(3). This edge then EBGPs with a number of peers (4).

Even after removal of the announce by (1) the edge (3) continues to announce the route to our peers (4).

Grumble. I hate to say it ... but ITS NOT FIXED

regardtv it is a different problem. We fixed problem when route was withdrawn but router continued to route packets using that non existent route.

Do you have a test setup where we can connect and see the problem?

Hi ,

Thanks for the reply. All information (including multiple sup-outs) included in Ticket#2013052366000443 ( yes, origional subject incorect

Just to add to that for the rest of the Mikrotik user base:

[Client] --eBGP-->[RouterA] --iBGP-->Core[RouterB & RouterC] --iBGP-->[IXP Edge RouterD] --eBGP-->[IXP Participants RouterN]

Scenario that seems to cause the issue:
1) Customers announce routes to RouterA
2) Customer withdraws routes to RouterA
2) RouterB & RouterC see the withdraws and pulls them
3) RouterD removes the route from its routing table ( as instructed by B&C)
4) RotuerD continues to announce the withdrawn routes to RouterN
5) Traffic from RouterN for the withdrawn route sent to RouterD is forwarded to Router B&C as if the route is still there.

This is identical behaviour in 5.16 as well as 6.0 (both x86 based).

While I don't dispute that it may be a separate bug - it certainly presents identically -- ie the same issue occurs.

Come on guys time for that devel.npk

In terms of test setup - contact me in the ticket and lets see what we can do

We too are experiencing this issue. Our symptoms are similar to regardtv

I have supplied screenshots and supout.rif's from our RouterOS 6.1 testing in Ticket#2013061366000148

What we are seeing is

RT00 VRF --L3VPN--> RT01 VRF
--L3VPN--> RT02 VRF

RT00 originates a route, this is seen by RT01 and RT02. If the route is withdrawn, it will only sometime be removed from RT01 and RT02. If it is NOT withdrawn, the only way to remove it from RT01 and RT02 is by rebooting them.

We noticed that if the route is originated then withdrawn within about 30 minutes, it seems to work flawlessly. It is only when the route has been received bt RO01 and RT02 for more than 30 minutes, and is then withdrawn that they will not reflect the change.

When the route is stuck, the CPU usage shown in Winbox and /system resource print jumps from 0% to 25% but the Profiler does not show which process is causing this.

nz_monkey,

Thanks for the confirm - just a question - you running a mixed Cisco & Mikrotik BGP environment? I'm trying to localise as far as a I can and my "all mikrotik" testbed is just not able to recreate it.

My production environment is mixed Cisco/Mikrotik on the iBGP side.

regardtv

No it is happening on a 100% mikrotik test bed

There are still issues on v5.25 with the route cache. If you are using route redistribution for static routes (for example) then even if you delete a route from the routing table, the route will sometimes get advertised as redistributed. Disabling the peer and then enabling the peer does not do the trick.

Only a flush for the cache would do the trick.

+1 for that.

Regards,
Mihai

There are still issues on v5.25 with the route cache. If you are using route redistribution for static routes (for example) then even if you delete a route from the routing table, the route will sometimes get advertised as redistributed. Disabling the peer and then enabling the peer does not do the trick.

Only a flush for the cache would do the trick.

+1 for that.

Regards,
Mihai

As per the prior posts here the fix is NOT in the v5 series - I agree flush cache would help but the reality is that we as users should be following the v6 release chain now - and helpling Mikrotik squash bugs.... if only they'd get back to me on my open ticket

As per the prior posts here the fix is NOT in the v5 series - I agree flush cache would help but the reality is that we as users should be following the v6 release chain now - and helpling Mikrotik squash bugs.... if only they'd get back to me on my open ticket

They are possibly working on the problem

HI,

This problem solve? My CCR36 make stuck route with iBGP quagga / CCR. News?

HI,

This problem solve? My CCR36 make stuck route with iBGP quagga / CCR. News?

It is not fixed. Mikrotik are too busy working on other things to fix it.

Log a support ticket with support@mikrotik.com and include supout.rif

Hopefully if enough people log tickets they can give the problem some priority.

I'm post new " [Ticket#2013073166000808] RE: Stuck routes BGP ". Let's see how they respond.

It seems that this is the more critical problem about Mikrotik.
It's the only reason I'm not using Mikrotik for BGP, but certainly I'll do after fixed.

Again occurred. iBGP routes with fangs disappear after the eBGP. I had to download all the Peers of CCR to normalize. When Mikrotik will fix this?

Again occurred. iBGP routes with fangs disappear after the eBGP. I had to download all the Peers of CCR to normalize. When Mikrotik will fix this?

Hi Jonatas. You've forgot to mention the RouterOS version which you experienced this problem.

Again occurred. iBGP routes with fangs disappear after the eBGP. I had to download all the Peers of CCR to normalize. When Mikrotik will fix this?

We are seeing this behavior on 5.12, 5.14, 5.16, 6.0, 6.1, 6.2

We often will get routes that are not in the RIB but exist in the FIB. We have to add static routes manually to over ride them

I am really looking forward to 7.0 and the "new routing". We are experiencing multiple separate major issues with routing on RouterOS v5 and v6.

Hello guys!

Any news about this famous issue?

Just remembering its 2nd aniversary since I saw this on MK routers.

It seems to be fixed in 6.5

It seems to be fixed in 6.5

Can anyone test and report in this thread?

In the 6.5 changelog: route - fixed crash that could be triggered by change in nexthop address resolution;

Yes I can confirm it is fixed.

Isn't this the same issue as discussed here? http://forum.mikrotik.com/viewtopic.php ... 90#p407090

I had this issue happen with 6.7 (route cache is full, networking stops). Is anyone from this thread still experiencing the issue with version 6.5 or later?

Looks like this issue is much worse in 6.11. We downgraded several routers back to 5.24.

Is there any news about fixing this bug?
Still have problems with CCR1016-12G and RB751G-2HnD on 6.20
We are using OSPF and IPSEC.