@normis: Do
NOT even say that there is no proof there are routing problems.
We have decided to go with 5.0rc8 for further testing to be able to contribute with information to the further development of Mikrotik solutions (which we are big fans of) but you have to agree that when there are multiple people saying that there are routing problems, well, there ARE routing problems. And we subscribe to the point that there ARE BIG routing problems.
Again I will further detail the info regarding problems of v5:
- - VLANS on bridges do not work AT ALL. Period.
- - IGP does NOT work properly , bgp routes get active status instead of directly connected routes, which results in traffic being routed in a loop between local routers (we get TTL expired as traffic moves between the routers back and forth), thus breaking any IGP setup, which is very bad. (this does NOT happen on v4.16 on the same configuration)
- - The previous bug can be avoided by using force-self option on the backup router (in a vrrp setup) and by not accepting route redistribution from the backup router to the main router (basicly breaking the network loop which I mentioned) - this provides a working setup for us for now.
- - There is also a typo in the "Nexthop Choce" it says propogate instead of propagate
- - If there are multiple VRRP interfaces, and IPs assigned to those interfaces, the IPs do NOT go into the routing table !!!
The IPs have to be disabled manually and re-enabled for the dc routes to appear in the routing table. This is a huge bug which also manifests in v4.16 for IPs assigned to vrrp interfaces.
- - The previos bug also happens for bridge interfaces also on v4.16 stable, I do not know if it happens on v5 as we've disabled bridging as vrrp does not work.
- - VRRP on v4.16 is not compatible with vrrp v5, multiple routers using different versions of Mikrotik get MASTER status in time, although there should be only one master.
- - As Mikrotik says in it's documentation there can be only one active route for a single prefix even if multiple announcements are made from multiple providers. Well, in v5.0rc8 we are getting multiple active routes if IGP is used, which also creates problems. Has this somehow changed between versions? Can we have multiple active paths for a single prefix now? Without manually specifying multiple gateways plus check-gateway option? If so, this is good, but the algorithm should be mentioned so we can work with it properly.
- - Winbox has a problem also: if we check IP / Routes and then we change the routes for some prefixes, we still see the old routes in the routing table. If we close IP / Routes and open it again, the routes show properly, so the internal update function for the routing table does not function properly.
- - The routing filters have a problem regarding the routing filter number. If there are dinamically assigned rules in the filter, we have such rules by using our own custom scripts for some prefixes, well the route filter NUMBER is just way off and affects ALL route number reads by scripts by a factor of -1. This manifests itself in the following manner: if a new manual route filter is being added, it will not work. You have to add a new "passthorough" rule so that the passthrough filter rule is disregarded and the previous rule is taken into consideration. Please see the image for correct assigment:
- - We are using 2 i386 systems, so one is Dual AMD, one is Dual Intel. In the Mikrotik documentation it says that once the routes are received or sent through a single peer only one thread (or core) will be active, so that the router will not overload. In V5, AMD works this way, Intel does not. The Intel 2 core CPU is going into overdrive 100% on full bgp feed, thus loosing packets as the routes are received, and even locking up the console.
All of these are serious problems, part of which were also happening on v4.16. I was personally hoping to see them fixed in v5 as they are seriously affection the functionality of Mikrotik as core routers.
As I've said I am a big fan of everything that is Mikrotik so, if you require further testing we are willing to help for a much better product in the future. But really, I urge the developers to subscribe to the idea of leaving the features alone and instead fixing these problems which are are very, very serious.
