We can confirm the following good, bad and the ugly with the 2.9.12 routing-test package. Anyone else seeing similar ?
BGP Bad:
BGP appears to always redistribute other bgp no matter what. Outbound Filtering is strictly required if you are multihomed.
redistribute-static and redistribute-other-bgp dont do anything, because, as it seems, actually defaults to ‘redistribute-them-all-no-matter-what=yes’ and you just cant stop them without filtering.
Outbound filtering is only useable when filtering at the ‘instance’ instead of the ‘peer’. Any peer filtering seems to stop BGP advertising altogether. (Manual states they both should work the same but ‘instance’ filtering takes precedence. This is not how it works in practice.)
Matching routes recieved from upstream peers do not get chosen properly. Shouldn’t the path with the least AS ‘hops’ get chosen as prefeered route if all other factors are equal? (it sometimes does, but sometimes doesn’t)
You MUST disable then enable the BGP instance to initiate changes properly. Not too bad, at least it doesnt require a reboot.
BGP Good:
AS path prepending works good
MD5 works good (upstream peers are Cisco)
Inbound filtering works as it should so far (havent fully tested yet)
OSPF overall:
Seems to work well, but when changes dont ‘take’ (as they sometimes dont) you got no choice but to reboot.
Others:
RIP etc cannot comment have not used them yet
I found some problems with RIP and version 2.9.13.
Well, I have One main router and two acces servers. Between all of them RIP is set up. The problem is that sometimes the router (version 2.9.13) have uncorrect rip rules. For example, a host is connected to AS1, while the router has a route rule (rip) for AS2 for this host. After reboot it looks like it’s working. (Bote Access Servers are 2.8.26 version)
In the RIP setup there is one network for all the hosts and eveyone has the other two hosts as neighbours.
Also for me routing is not OK on 2.9.14.
BGP peer connection is put in “unknown” state, and no route is received from my peer.
Same thing with 2.9.12 and 2.9.13; to recover to a working condition I have to fall back to 2.9.11.
I’m going to write to MT support, I have a supout.rif detailing that bug…
Well, there are several things fixed in the last few versions (incomplete, just from memory: IPsec, problem with vlans and bridging, …) that were not even mentioned in the changelog as being fixed - for starters
maybe they were not? maybe they didn’t work because of another problem that was in the changelog as fixed? ok i get your point, but all important changes are already there.
if something is completely remade, how you could describe the differences? something there are changes made that noone would understand, code improvements that dont’ have anything to do with routeros, then there are things that improve stuff for one person, but not for other. it is very hard to describe
) for a more detailled change log?
? we rarely release something when we know that there is a broken feature