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.
Any ideas if it's a bug or how to fix it?
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.
Any ideas if it's a bug or how to fix it?
See 7th post here re very broken 2.9.13 routing-test
http://forum.mikrotik.com//viewtopic.php?t=6874
http://forum.mikrotik.com//viewtopic.php?t=6874
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....
Riccardo
P.S: routing-test is not solving too...
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....
Riccardo
P.S: routing-test is not solving too...
) for a more detailled change log?even if the problem was fixed by fixing another problem which had this one as side effect, this should be noted in the changelog in my opinion.
And sometimes things noted in the changelog could be explained a bit more. Let's take the 2.9.13 changelog for example:
Best regards,
Christian Meis
And sometimes things noted in the changelog could be explained a bit more. Let's take the 2.9.13 changelog for example:
So: What was improved exactly? What are the effects/benefits, or what could be problems with earlier versions before that improvement?*) improved WPA link establishment for WDS;
Best regards,
Christian Meis
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
? we rarely release something when we know that there is a broken featureYep. But I meant a bug tracker where your co-workers (support/development) can submit (confirmed!) bugs and everyone can read them. Making that read-only access limited to MikroTik customers would be OK (like logging in with account server credentials, as for the chat room).
Best regards,
Christian Meis
Best regards,
Christian Meis
My post from another thread.
In my opinion, Mikrotik should little bit revise its testing procedures and give more information to users about changes between versions. I think nothing serious happens, when some minor errors are found in new releases, but it is not possible to release version with serious errors.
I am programmer so I know it is not always simple task to release new version of software, but from user's point of view I must say that I DO NOT WANT TO BE INVOLUNTARY TESTER OF EVERY NEW RELEASE.
I had problems when upgrading from version 2.9.8 to 2.9.9 and 2.9.10. There was problem with IPSec and there was even no mention about changes in IPSec in changelog, I supposed no problems during upgrade and oops. This experience forced me to have two Routerboards at the table and test every new version, but why should I do it?
Please do not take my post as attack, Mikrotik is great product, but there are always things to improve...
I must agree with Christian, the more information (about bugs and expected timeline of solution) presented in this area the better for Mikrotik I think.
In my opinion, Mikrotik should little bit revise its testing procedures and give more information to users about changes between versions. I think nothing serious happens, when some minor errors are found in new releases, but it is not possible to release version with serious errors.
I am programmer so I know it is not always simple task to release new version of software, but from user's point of view I must say that I DO NOT WANT TO BE INVOLUNTARY TESTER OF EVERY NEW RELEASE.
I had problems when upgrading from version 2.9.8 to 2.9.9 and 2.9.10. There was problem with IPSec and there was even no mention about changes in IPSec in changelog, I supposed no problems during upgrade and oops. This experience forced me to have two Routerboards at the table and test every new version, but why should I do it?
Please do not take my post as attack, Mikrotik is great product, but there are always things to improve...
I must agree with Christian, the more information (about bugs and expected timeline of solution) presented in this area the better for Mikrotik I think.
Maybe what Mikrotik should do is post somewhere in thier web site all bug or issuses that are found after a version is release. Something that will get updated everytime mikrotik finds that what customer are compalining about is true. That way the rest of us that do not understand why something is not wotking can see aall current bug and we can downgrade or wait, but not get frustrated with a configuration that will never work.
Would be nice if there was already a public site (sure there is somewhere) that would do this for the community, and then simply mikrotik uses that to determine what needs to be fixed...
http://lab.msdn.microsoft.com/productfe ... 1a01235cf1
Microsoft does this - an example is above. Very detailed about whos having the issues, how many people can validate it, what the workarounds are, etc.
Sam
http://lab.msdn.microsoft.com/productfe ... 1a01235cf1
Microsoft does this - an example is above. Very detailed about whos having the issues, how many people can validate it, what the workarounds are, etc.
Sam