Are you sure that problem is actually in BGP and not in some problem with policy routing?
There is a known change in handling of “route marks” that may affect your configuration for cases like this.
When you want to advertise a default route you likely are running 2 (or more) route tables. When you load the BGP-advertised default route into the table, you must make sure that the original route for the BGP session to the peer router(s) stays in place and is not taken up by that default route, else the session would flap.
At the moment I am running v7 as test on a router with a BGP session to a v6 router that advertises the default route, and that works fine, the route gets and stays in the (2nd) table. I also advertise that route through to another v7 router and that also works. But I do not have the situation where the real origin is on a v7 router.
(I cannot update that router to v7 until BGP is improved further)
that can’t be a policy routing issue, because the bgp session goes over two ‘connected’ ip’s of the /29 transfernetwork between both boxes, which is more precise than a default route and also has the distance of ‘1’ because it’s directly conected.
the bgp session starts to flap in the moment, when the ros7 box starts to advertises the default route. even when there is a route-in filter on the ros6 box, to not learn any route from the ros7 box. when i create a route-out filter to prevent advertising the default-route on the ros7 box, the session stays stable, but useless…
can be that it’s some wired thing in the route arithemitcs on the ros7 box, but thats not normal behaviour, when there is nothing configured to override the connected route for the session, which shall always win.
Still, that can be the reason when your /29 network route does not appear in both of your routing tables.
I have to explicity copy the automatically added “C” route from the main table to the 2nd table used with BGP to make things work correctly.
(I open the C route in winbox, click COPY, change the routing table field and set the distance to 1 (0 is invalid for manually added routes) and save it).
This would not be required when using VRF, but I still have too many issues with that.
Hi I have a problem with OSPF stub areas, if I reboot the ABR router, the router in the stub area gets all kinds of LSAs. The only workaround is to change the default cost to a random number apply the config, and then revert back to its original value and all works as it should.
Link to post in the forwarding forum: http://forum.mikrotik.com/t/abr-leaks-lsas-to-stub-routers-after-reboot/159503/1
the /29 and the bgp is in the ‘main’ table and the connected route always exists there ‘visible’. there is a vrf for management (which is not related to bgp or ospf or connected route), but the problem even pops up, when there is no management vrf.
can be that there is some strange workaround by making some things static, which are supposed to work dynamic, but anyhow, thats everything else than stable nor ready for production. and thats a serious issue, if you want to feed your transit customers with bgp transit with just a default route. ros7 just isn’t able to do this yet.
Oh I fully agree with you that it is not ready for production. I have written that many times, so many even that a “forum admin” (outside MikroTik) has “warned” me about that.
But that does not change the truth. It requires work. When asking MikroTik, it is a “work in progress”. So for now we run 6.49, every 7.x beta hoping that the word “bgp” (and “bfd”) once again appears in the change notices.
Other than that, I just tried to help you. I have seen before (in v6 as well) that distributing default route can cause interesting problems. But apparently you know you are not affected by that.
Can’t remove NAT rules created via UPNP - “Couldn’t remove NAT Rule … not permitted”
got following reply from the support team - doesn’t sound promising for a solution soon, because the bug is well know since end of 2021 already…
— snip —
Hello!
We are very sorry but this bug is not fixed yet and I still can’t provide ETA.
This bug is very important however there could appear issues with higher priority and they are resolved primarily.
— snap —
Yeah, that really is unfortunate. It seems that BGP is not high on the priority list, for whatever reason. We have seen before that MikroTik people commented that “most users are perfectly happy with v7” but that cannot include BGP users. Apparently BGP users are only a small fraction of the total user community. But if that is true, then why did they even start rewriting it??
I would be happy with an optional “bgp6” package that just puts everything back to what it was in v6 and that we can use until they fix the v7 code…
I guess developers did not want to migrate legacy code to the new platform. Instead they opted to re-implement it using a expression-language (as a proof of concept) and then in long-term can re-use this expression-language for various areas in ROS.
The talk about an “entirely new routing engine” already started ~10 years ago, when the mythical v7 was introduced that would solve all our problems and fulfill all our wishes.
While I agree it is sometimes useful to start from scratch, every programmer with a little experience knows that this is always easier said than done. At first you think about a very clean new design that would be so much more modular and would be able to use multiple cores, etc etc, but when you start detail design and coding you invariably hit snags that cause problems in the new implementation, and also even when you do not find them yourself there always are new bugs reported by the users.
So such a rewrite is a lot of work, and during initial release it requires a lot of attention from the developers, both to make sure it is feature complete and also to solve the reported problems. “critical omissions” surface (e.g. the unavailability of a “number of received prefixes” and associated filter to drop connections when it exceeds some limit), that require more effort in the new design than they did in the old one.
It looks like either the whole project was under-estimated (and the manpower is now allocated to features that more users use, or that newer devices require), or the existing developers somehow left the scene and the project slowed down while new developers are found and have studied the matter.
And now we are left with a half-finished solution where before we at least had something that worked within the limitations that were well known…
The transition to v7 would have been a lot smoother when the new routing was offered as an optional package (like wifiwave2) with the old code available as a fallback. And now it could be resolved by offering the old code as an optional package until there has been opportunity to fix the new version.
RB1200 from 6.49.6 > all ros 7 version even 7.4rc2
ether1-8 not working
Only 9 and 10 eth working.
Downgrade to 6.49.6 working fine
Anyone with RB1200 and ros 7 with normal operation ?
I believe that when MT Developers adopted the newer Linux Kernel [the very heart of the OS ] for version RoS v7 they came up with unexpected challenges … I am also 100% certain that those same developers are far more frustrated by those challenges than you or I and the goal post would declare. Your BGP comments are very valid and I for one empathize. Patience is the only recourse available. I am also 100% certain that MT will resolve this issue sooner vs later.
Hi MikroTik,
This runs fine on my Chateau 5G for home use, is there a new rc soon?
I use mikrotik for bgp a lot, not only for internet but vpn as well and i am using their flagship hardware such as ccr1036 or ccr1072 and the whole life we are running with a lot of bugs in bgp, i have some tickets regarding bgp/ routing bugs on v6 and mikrotik said that all problem will be solved in v7.
And now v7 has been released and i still cannot use the new v7 for production in my environment, at least for particular issue that i already report it.
Did u realize that your customer (maybe some bgp customer) are waiting years and put their hope to your product? And their have effort years run their network.with all existing bugs in v6?
And wait patienly for improvement in v7?
Thx
New version v7.4 has been released!
http://forum.mikrotik.com/t/v7-4-stable-is-released/159556/1