Hi,
Every now and them we got that problem. Today another AS network engineer called me becouse his IP prefix couldnt reach our prefixes.
After troubleshooting he told me that they lost they connection in a national wide IXP and when doing a traceroute from our bgp router, the next hop showed was our IXP ip address. After checking the routes, we're receiving their routes via another service provider but RouterOS were trying to get to them via a cached route that doesnt even exists anymore.

To fix the problem we have to disable the IXP interface on our router and them reenable it. After that RouterOS finnaly forgot the route and them everything started to work.

Anyone more having that problem? Is there any command to clear routing cache?

Thanks!

Hi,
Every now and them we got that problem. Today another AS network engineer called me becouse his IP prefix couldnt reach our prefixes.
After troubleshooting he told me that they lost they connection in a national wide IXP and when doing a traceroute from our bgp router, the next hop showed was our IXP ip address. After checking the routes, we're receiving their routes via another service provider but RouterOS were trying to get to them via a cached route that doesnt even exists anymore.

To fix the problem we have to disable the IXP interface on our router and them reenable it. After that RouterOS finnaly forgot the route and them everything started to work.

Anyone more having that problem? Is there any command to clear routing cache?

Thanks!

I don't think there is a command to flush the route list/cache. It generally does this automatically. You should contact support@mikrotik.com and request such a feature or workaround.

thanks!

Hi,

This specific bug is causing some frustrations for me as well. It appears that the stale route remains in cache for as long as any IP sessions are trying to make use of the path. In this regard think of any TCP connections that might need to time out etc - the route could therefore stay in cache for far longer than one would reasonably expect. From past reading it looks like items typically expire from the cache after around 10 minutes - but not for 'in-use' routes.

The forcible shutting of an interface has on occasion not solved it for us - and we actually had to perform a reboot.

This is one of the frustrations I hope gets addressed on next RouterOS builds. While being able to forcibly manually clear the cache would help it would be better for TIK to remove 'in-use' routes if the routing entry supporting it is removed from the main routing table.

Thank for your statement about that bug. Please open a support ticket. So way the MikroTik trama will see that more ppl have the same stuck route problema.

Hi all,

Was this problem solved? I can notice a lot of people asking about the same problem.

Artur

I get nothing on my support ticket about this issue....

The same problem.
I have a test that pings the remote server. Sometimes the ping test fails but all the devices on the way are UP and running. Disabling and enabling route to this destination on mikrotik solve the problem.

Im experiencing this problem on 3 x86 (5.7) and 1 RB433 (5.14).

Hey Guys!

I have exaclty same problem reported at top of this thread (dec 2011?!?). Two routers connected to IXP and when
a peering partner stops sending a prefix my router removes old route from table but still trying to use that
route to forward packets... and worst still sendind that prefix through ibgp to my core router.

I`m wondering if that problem still the same problem reported in 2011 or its is new. Hope it`s new because
one year to solve a routing problem is too much if you have in mind we are talking about ROUTERS.

PS: Version in use are 5.18 and 5.20

Hi,

Still present, yesterday I have the same issue again with a router with a low route count ( about 300 routes). I had to disable and reenable the interface that had the stale stuck route and everything back to work..

I don't know why RouterOS guys fix this or create a tool to clear the route cache.

The router that have this issue is running 5.17.

Hi...


You should take in consider that BGP need time to be updated.. its not like of other routing protocol.. update the route DB as soon ad there is change apear in network..!!

So you have to wait even my take up to 5min..!!!! till most of Upstream provider got the update..!!


Also there is another option is that you can refresh you peer update / routing bgp peer refresh-all afi=ip


Regards
Ali Sami

Hi...


You should take in consider that BGP need time to be updated.. its not like of other routing protocol.. update the route DB as soon ad there is change apear in network..!!

So you have to wait even my take up to 5min..!!!! till most of Upstream provider got the update..!!


Also there is another option is that you can refresh you peer update / routing bgp peer refresh-all afi=ip


Regards
Ali Sami

The bug related here is that even if you wait a month, if you dont reboot the router or disable and reenable the interface that the related bgp route were using, the traffic destinated to that destination will use the stale route for ever..

Refresh don`t work.

As I said before, route disappear from routing table... Looks like bgp receive routing update from neighbor, remove it from routing
table but it still present on route-cache. What I dont know is why the removed prefix keep advertised to other routers.

As far I know, bgp use messages to update routes, it don`t have a holdown timer to wait before removing a route, like RIP does.
(I`m talking about updates and not neighbors timers)

On my case routers a connected to IXPs and prefixes are exchanged by MLPA on those IXPS, what give me only 11.000 prefixes and
updates occour only inside that group.

I`m going to downgrade to version 3.27 and see what happens. Support told me that problem is known since 4.x.

Jorge

Have the same problem. Two routers. Versions 5.13 & 5.20.

Refresh don`t work.
I`m going to downgrade to version 3.27 and see what happens.

Did you do downgrade? Does it help?
Thanks in advance.

yes, no problems with stuck routes so far.

But I did it only on RB1000 hardware because RB1100/RB1200 dont support that version.

Also... I downgraded to 3.30 and I`m using default routing package, looks like routing-test is the same used as
default routing package on versions > 3.30.


Don`f forget to check if 3.30 can do all tasks that you need on your router, mikrotik did a lot of improvements
5.x versions.


regards

Here in Brazil, the biggest IXP in South America (PTT-SP) there is a mailing list in which several users posted they are suffering from the same problem (with different ROS versions) and also complaning support tickets are left unanswered. Some companies migrated to Quagga because of that issue (and mainly due the lack of consistent response). I strongly suggest this issue to be reviewed with a higher priority.

Hello Kurt,

I`m one of those users connected to PTT-SP and saw a thread on [GTER] list about that problem just after my first post here.
Also... I definitely agree with you about mikrotik must increase priority to solve this bug.

C`mon Mikrotik help us to keep supporting your products! give us an workaround at least!

Hello Kurt,

I`m one of those users connected to PTT-SP and saw a thread on [GTER] list about that problem just after my first post here.
Also... I definitely agree with you about mikrotik must increase priority to solve this bug.

C`mon Mikrotik help us to keep supporting your products! give us an workaround at least!

+1 member! ( and BR too)

Gustkiller, anything on your support ticket about this issue?


Lyma.

I gave up...

Hello Kurt,

I`m one of those users connected to PTT-SP and saw a thread on [GTER] list about that problem just after my first post here.
Also... I definitely agree with you about mikrotik must increase priority to solve this bug.

C`mon Mikrotik help us to keep supporting your products! give us an workaround at least!

+1 member! ( and BR too)

Gustkiller, anything on your support ticket about this issue?


Lyma.

Hi...


You should take in consider that BGP need time to be updated.. its not like of other routing protocol.. update the route DB as soon ad there is change apear in network..!!

So you have to wait even my take up to 5min..!!!! till most of Upstream provider got the update..!!


Also there is another option is that you can refresh you peer update / routing bgp peer refresh-all afi=ip


Regards
Ali Sami

The bug related here is that even if you wait a month, if you dont reboot the router or disable and reenable the interface that the related bgp route were using, the traffic destinated to that destination will use the stale route for ever..

same problem with OSPF routes... I sure it is a basic problem with routing package
I send many bug report to support and each time answer is "it will be fix later"... time after time...

The lack of official and public response from Mikrotik, for me, is an evidence they don't have a clue on why this happens and how to fix it. So, no fix soon, even in the first v6.0. If such severe problem were about to be fixed in the next v6 stable release, they would be annoucing it heavily.

OSPFv3 just doesn't work, BGP has stale routes... They've been too busy devoting all their time to building the CCR which is great and all, but the adage "learn to walk before you try to run" springs to mind. It makes absolutely no difference to me how many packets I can push over a device, how many queues I can have on it (I don't personally use any - we only trade in wirespeed), if I can't rely on it having a valid/complete routing table in the first place and know that the packets will actually get where they're supposed to be going.

I kept getting told that the problems I have will be fixed in "the new routing package" but that they have no real information on when it will be available. There's no talk at all in the v6 Changelogs of a new routing package, so it presumably still hasn't been addressed. Like others, I gave up asking support because it was a waste of my time.

I'd have been game for grabbing a pair of CCR1036's but after buying two of their former flagship tins (RB1100AHx2) to use in a testbed for customer access routing and getting - mostly - no useful support it seems like a waste of time (which is in shorter supply than money) - and I have no reason to believe that support will get any better. By support, I include rolling out software fixes in less than a couple of weeks for major functionality defects rather than things being broken for over a year. I even offered to buy additional licences to bribe them into fixing their product.

It's actually pretty hilarious to me that the MUM in the US had a presentation from one of the guys at Hurricane about how IPv6 is no longer optional whilst current builds of RouterOS can't even maintain adjacency in OSPFv3.

I *want* to back the underdog, but I *can't* when there are major problems with the way the product's firmware is supported. MikroTik don't seem to get that I and others will spend more money to get a product that just WORKS and they are limiting their own growth potential - refurb/grey Cisco and Juniper is not so expensive as to be an unattractive alternative, because Cisco et al without support is better than MikroTik with support right now.

This strikes me as a dumb position to be in, when you're proposing to have a box that can shift 24mpps at $1000 and you're still not coming out on top simply because the software and support is bad - I might need a router, I might want a <$5000 router, but I certainly don't need - or want - a $1000 paperweight that's going to tie up hours of my time (which has a very real cost).

The worst of it is that nobody really seems to care. There is no sensible response to any of this. Presumably the WISPs et al are buying enough of the smaller bits of kit to keep the lights on, so why change the model, right?

Great comment!

Here we have to buy a Juniper MX router that cost here about U$30K dollars, but in the last 8 months since we change our x86 mikrotik border router with the Juniper, we have yet to see any kind of issue or hicup. Sometimes I really forget that we have a router running here.

I really "loved" mikrotik router os and products, since 2005 . But when you go large ( full tables, and more routing complexity) it lacks "software" reliability.

I'm really looking forward to try the CCR product, but we will not be able to deploy as a backup router for our Juniper or even in our most crowed PoPs because of these routing issue.

I'm felling betrayed..

I suppose it's fortunate that because I started from a more complex environment to begin with - dual stack full table access routing - that I uncovered the flaws before we got too involved with MT.

If I had spent time getting a certification, and had a pile of their kit, I would definitely be in the CCR announcement thread making myself unwelcome asking if the CCR actually did BGP/OSPFv3 properly or if it was broken (and likely to remain broken for a year+) in them too.

In the absence of any meaningful response from MikroTik, has anyone found a workaround short of rebooting the router every X hours ? I have the same problem with two routers (out of several hundred). Neither do any advanced routing (OSPF, BGP), but both use bridges to terminate VLANs. Each will invariably stop processing IP traffic once the route cache fills up. The rate is dependent upon traffic, one takes several days, the other just hours. Interestingly, you can MAC telnet into the router which at least allows me to remotely reboot from an adjacent device.

In the absence of any meaningful response from MikroTik, has anyone found a workaround short of rebooting the router every X hours ? I have the same problem with two routers (out of several hundred). Neither do any advanced routing (OSPF, BGP), but both use bridges to terminate VLANs. Each will invariably stop processing IP traffic once the route cache fills up. The rate is dependent upon traffic, one takes several days, the other just hours. Interestingly, you can MAC telnet into the router which at least allows me to remotely reboot from an adjacent device.

Disable and Reenable the affected interface do the trick here. But as I changed our border router from MK to Juniper, I don't have this issue anymore.

I would try that if the router was not an hour's drive away. I suppose I could experiment with a script to accomplish this, but it is a little scary if something goes awry and customers are down for hours. They just hate that.

I actually solved my problem by splitting the functionality between two MT routers. One does the VLAN tagging, the other does NAT. Stupid, but what else am I going to do with all those RB532's ....

Cheers,

Reading this thread is very disappointing. Route manipulation in any dynamic routing protocol needs to function reliably. I was hoping to deploy MikroTik devices at the edge. This thread just killed any future plans with MikroTik with exception for use as a wireless home IP access product.



Respectfully,

--ISO

Aparently this issue is fixed in the new routing package.

It is disappointing it is taking Mikrotik such a long time to fix such a visible, repeatable and widspread fault.

with new routing package?

Staff i have been trying to fix a little issue i had i was basicly adding static routes and removing them
and re creating nats and so forth, and some where along the line one of the routes i am certain of got stuck, but it was not in the route table

it took a reboot to clear the mysterious issue.

I really dont have much in my router but i have rb450g i dont think you need my config in this case

just simple static routes and Nats nothing else

Aparently this issue is fixed in the new routing package.

Hello nz_monkey,

Just checking but you mean the issue WILL be fixed right? Do you know something about when that new package will be avaliable?

tks

Hello nz_monkey,

Just checking but you mean the issue WILL be fixed right? Do you know something about when that new package will be avaliable?

tks

Hi jthiele, I have no idea when this will be fixed, I am guessing the answer is "When it's ready". Maybe Maris(MRZ) or Janis from Mikrotik can provide a better answer

I have just discovered another bug.

During some testing of a dual border router, dual provider setup with OSPF re-distributing a default route between the two border, I discovered that the default route being re-distributed in to the OSPF is being received according to the OSPF routes tab, but does not appear in the main routing table under /ip routes. Oddly, it still appears to be active as I can still reach the router, but it certainly is not appearing in the winbox output!

i see the routing table bug as well. entry's don't go away for routing mark till a reboot of the router is done.

please fix or allow flush command.

running 5.22

i see the routing table bug as well. entry's don't go away for routing mark till a reboot of the router is done.

please fix or allow flush command.

running 5.22

Yes we have seen this too when using Route Marks with L3VPN.

Hopefully it gets fixed in the very near future.

Anyone try last ROS 6 rc to see if the bug is still present ?

Anyone try last ROS 6 rc to see if the bug is still present ?

Unfortunately we cant take the risk on production networks

Mikrotik are fully aware of this issue and have acknowledged it, but they have not provided a timeframe in which it will be fixed

We are happy to test new routing code, under NDA if required.

hi guys,

can you give a roadmap how to repeat bgp-cache bug with CCR or 1100AHx2 in LAB?
if necessary i have several copies of 440k routing table to share in iBGP

andis,

Isn`t necessary to have many routes in the table for the problem appears. Here I have ~ 20.000 routes on router
connected to an IXP (NAP).

Some information that can help:

- My peers are IXP Route Servers running Quagga (not 100% sure if quagga still).
- There are routing filters implemented, nothing special. Discarding bogons, and setting community on input filter.
- Mikrotik redistritute learned bgp routes from IXP to a local quagga working a Looking Glass server

What happen:
- If a IXP member stop announcing a prefix it desapears from Mikrotik routing table but Mikrotik keep announcing it to My LG Server
- Despite route not part of Mikrotik routing table, router keep using it to send traffic
- Refresh ou reset on bgp session does not help, reboot needed

Last time it happened to me I had two prefixes from an ASn, one was 186.x.y.0/21 learned from IXP and the other was a 186.x.y.0/20 learned from my transit peer. When prefix owner removed /21 from his announce router ignored /20 and keep sending traffic to /21 gateway.

Hope it helps

Hi,


Could anyone test if this issue is still present in the latest RouterOS v6?

Hi Kurt,

To the best of my knowledge v6 is still currently running the old routing code base - I'm not willing to put v6 into my main production network at this point to test it.

I do know there were plans from Mikrotik on a new routing-test package but haven't seen or heard anything of late. Maybe support@mikrotik.com can assist in this case?

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

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?

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

Hi! Why not all fixes submitted in changelog?
I can not see routing fixes in latest http://forum.mikrotik.com/viewtopic.php?f=1&t=69932 (6.0rc10)
or in http://forum.mikrotik.com/viewtopic.php?f=1&t=69442 (5.23)
or in the early changelogs...

it's because MikroTik's 'changelog' is not always 'fixlog', unfortunately

it's because MikroTik's 'changelog' is not always 'fixlog', unfortunately

Okay, but how we can know about all fixes? It is important!

We are very confused by developers point of view...
We should learn about fixes in telepathy mode?

not telepathy, but laboratory mode

not telepathy, but laboratory mode

Cool! So many useless work for finding hidden surprises...
We need to test ALL releases instead reading changelogs...
Like Russians say: "Find something, do not know what".


[irony]Very very important know about LCD displays improvements instead routing fixes [/irony]

you should test only current release for your needs - they don't fix old releases. if something is not working - you write to support@mikrotik.com and wait for response. they will say when they fix what you need

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.

problem still exist, now it has relations with IPSEC
I have static rout to 51.75.*.*/24 network via my provider's ip but BGP tcp session goes to ipsec vpn
all other tests shows me the route via my default gateway.
only direct use of local IP for outgoing connection makes BGP to go from correct source IP via correct route.