Multicast has historically had issues on Atheros based wireless links. That goes for Ubiquiti equipment and, I believe, MikroTik equipment in not too distant past. They both seem to do fairly well now. OSPF also tends to use multicast by default.The only thing is you should have multicast enabled links
The only moderators / staff are:...I will tell you to put your Karmas you know where...
Other users can see here: http://forum.mikrotik.com/viewtopic.php ... ow#p431222you'd better to not make such "hurting" mistake again, understand?
yes, sure, if you see lots of bugs and broken things in Ros, then these all should be fixed first and then discussing another topics,You brought up some good points though I don't think you entirely see the point of view we are coming from in that we currently have a lot of functionality out of ROS from the get go but a lot of these features are semi broken or buggy in many cases.I agree with the Virtual Links thing even though I am forced to use these things quite often in my networks to patch IPS's into the backbone.
Every network requires a certain tool from your toolbox to complete a job successfully and if Mikrotik is not the right tool a Cisco or a Juniper or whatnot might be the right tool for the job.
Good afternoonCisco has already opened EIGRP in 2013, when is Mikrotik going to add this protocol to routeros?
using ospf is overkill and not optimal in most networks, Eigrp is the most effective protocol in the networks we are building as Wisps,
It has summarization at each interface and convergence is fast, it's less resource intensive.
The only thing is you should have multicast enabled links
I can't imagine why people are against EIGRP on MikroTik and think OSPF is a better protocol especially for WISP deployments. It isn't, OSPF's design restrictions are AWFUL for todays dynamically expanding networksI can't imagine devoting the resources to bring up EIGRP. As networks continue to stop being Cisco-exclusive, the demand for EIGRP drops even more. You can run OSPF and EIGRP in parallel if you wish to make a transition to OSPF.
OSPF works fine for corporate/enterprise
IS-IS works far better for 'service provider' environments
EIGRP works in both
You can't separate them. OSPF no matter how much you want to try and pretend differently, it has certain design restrictions that are very restrictive for service providers. Those restrictions make sense in many enterprise environments because of the vastly different topologies and real world conditions. As such, of course OSPF is less suitable as a service provider protocol. That's practically the only reason why IS-IS is still around and did not die off long ago, because OSPF simply cannot do many of the things that a service provider needsOSPF works fine for corporate/enterprise
IS-IS works far better for 'service provider' environments
EIGRP works in both
This is **NOT** the way to look at routing protocols. Routing protocols solve problems. We have to stop looking at them as enterprise vs. service provider.
But we have no other protocol to use, we have OSPF and thats it. So rather than picking OSPF to 'solve problems' we have to figure out ways to solve the problems of an OSPF design. Problems like summarization at key points, but spanning multiple areas. I've had to use multiple OSPF area 0 instances with redistribution between them and route marks to prevent loops. Quite frankly horrible, and goes entirely against the 'best practices' philosophy of OSPF but necessary to make the network actually function properly according to the real world conditions. It's not about making a mess just for the sake of it, its because OSPF is not a 'service provider' focused protocol
It creates problems of its own, problems that would be entirely solved with EIGRP or IS-IS
You can't separate them. OSPF no matter how much you want to try and pretend differently, it has certain design restrictions that are very restrictive for service providers. Those restrictions make sense in many enterprise environments because of the vastly different topologies and real world conditions. As such, of course OSPF is less suitable as a service provider protocol. That's practically the only reason why IS-IS is still around and did not die off long ago, because OSPF simply cannot do many of the things that a service provider needs
This is definitely an antiquated and very closed minded view. Let's look over the fact that EIGRP - regardless of its usefulness - was a closed system with a fairly insignificant (comparatively speaking) install base and is very unlikely to ever make it into other platforms with any level of deployment or support. Setting that aside, many fairly significant WANs are built on OSPF and anyone that has used a commercial optical platform that leverages GMPLS is using OSPF-TE on the back end is using OSPF in a carrier network (albeit in a closed system) - I have built very large wide area networks on OSPFv2/3 because ISIS wasn't supported. the point is, it's definitely used in the WAN with a good sized scale and level of support. IS-IS has a larger scale, significantly less overhead, and a far superior protocol model than both EIGRP and OSPFv2/3 which is why it's used in large carriers and campuses (FWIW, I have seen large data centers and campuses using ISIS simply for the reason that it carries multiple routed protocols inside a single routed protocol and doesn't require IPv4 - let alone multicast - to function. What it comes down to is what works in your environment and what you can support. You like EIGRP and can support it - great. that's perfect for you. Sadly, like me asking for ISIS because I want it for my environment, my guess is that you're unlikely to get it in RouterOS.You can't separate them. OSPF no matter how much you want to try and pretend differently, it has certain design restrictions that are very restrictive for service providers. Those restrictions make sense in many enterprise environments because of the vastly different topologies and real world conditions. As such, of course OSPF is less suitable as a service provider protocol. That's practically the only reason why IS-IS is still around and did not die off long ago, because OSPF simply cannot do many of the things that a service provider needsOSPF works fine for corporate/enterprise
IS-IS works far better for 'service provider' environments
EIGRP works in both
This is **NOT** the way to look at routing protocols. Routing protocols solve problems. We have to stop looking at them as enterprise vs. service provider.
Of course there's overlap. No 1 protocol is perfectly suited for all of X business type
But i'd wager that the majority of MikroTik's user base are service providers, primarily WISPs. That's the fastest growing segment
But we have no other protocol to use, we have OSPF and thats it. So rather than picking OSPF to 'solve problems' we have to figure out ways to solve the problems of an OSPF design. Problems like summarization at key points, but spanning multiple areas. I've had to use multiple OSPF area 0 instances with redistribution between them and route marks to prevent loops. Quite frankly horrible, and goes entirely against the 'best practices' philosophy of OSPF but necessary to make the network actually function properly according to the real world conditions. It's not about making a mess just for the sake of it, its because OSPF is not a 'service provider' focused protocol
It creates problems of its own, problems that would be entirely solved with EIGRP or IS-IS
This is definitely an antiquated and very closed minded view. Let's look over the fact that EIGRP - regardless of its usefulness - was a closed system with a fairly insignificant (comparatively speaking) install base and is very unlikely to ever make it into other platforms with any level of deployment or support.
However for WISP networks, hands down EIGRP. And since it's quite simple i'd wager its a lot easier to program and implement than IS-IS
Hah! Love the ASN.