No ofcourse. I am network admin in my company (over 12 big factories in one system with over 4000 employee). We have cisco routers everywhere but also, we have mikrotik routers for wireless on few places (ap access and p2p links). I was considering is-is but MT inability was discouraged me. I could do redistribution but that just make my configuration more complicated so I stayed with ospf.I must admit I'm an IS-IS fan as well, and I believe that it does a few things better than OSPF, such as the TLV concept making it much more flexible. Read http://www.nada.kth.se/kurser/kth/2D149 ... 1.txt.html for a good analysis of the various differences.
However, I don't think IS-IS should be a focus for MikroTik at the moment. They would have to invent an ISO-protocol stack with CLNS, ISO addressing and all that in order to make it work. There are no such implementations for Linux, so they would have to engineer it from the bottom. I believe that MikroTik should focus on the areas they are already involved in, trying to extend the protocols they support, eg. extending the current MPLS implementation, extend IPv6, extend BGP etc.
Out of curiosity, what are your motivations for requesting IS-IS support? If you have a large telecom backbone that runs IS-IS, do you want to place MikroTik equipment inside of that backbone (no critique meant, just plain curiosity)?
quess he meant IGP
what? ibgp <> ospf.
with IS-IS you have one protocol daemon instead of two, the less complicity the better
OSPF and OSPFv3 handle IPv4 and IPv6 so whats the comparison here?
with IS-IS you have one protocol daemon instead of two, the less complicity the better[/quote]
OSPF and OSPFv3 handle IPv4 and IPv6 so whats the comparison here?
i guess for same reason why CISCO didn't support things like IPIP and other MikroTik -specific things(there was Several and many of them STILL remain Very popular among MT consumers).Well... Cisco and Juniper also have OSPF but that didnt stopped them thinking: well IS-IS is... IS-IS after all
It is thinking of big league players...
Can't tell if those are the words of a man who has had a sneak peek of something…we may see it in v7 whenever that comes out. :-)
I'd really like to know where hell I can use it in real life, so please tell the truth :)Its just sooooo coooooooooool protocol...
IS-IS can scale much larger than OSPF due to the way it designs the hierarchy of flooding domains and by using Incremental SPF. This is why it's used as the IGP of choice for most large ISPs and Data CentersI'd really like to know where hell I can use it in real life, so please tell the truthIts just sooooo coooooooooool protocol...
So to say, I have neither ISPs to establish ISIS with, nor software/hardware within the LAN to use it internally.
But the proto is nice, really.
I have an ISP customer with around 200 POP's and OSPF scalability is a real problem. We have had to make active efforts to remove any dynamic interfaces from OSPF and reduce the prefix count to minimise SPF re-calculations from loading up router CPU's. IS-IS would vastly minimise these specific problems.IS-IS can scale much larger than OSPF due to the way it designs the hierarchy of flooding domains and by using Incremental SPF. This is why it's used as the IGP of choice for most large ISPs and Data Centers
I have an ISP customer with around 200 POP's and OSPF scalability is a real problem. We have had to make active efforts to remove any dynamic interfaces from OSPF and reduce the prefix count to minimise SPF re-calculations from loading up router CPU's. IS-IS would vastly minimise these specific problems.IS-IS can scale much larger than OSPF due to the way it designs the hierarchy of flooding domains and by using Incremental SPF. This is why it's used as the IGP of choice for most large ISPs and Data Centers
We do not have plans to implement ISIS at least not in near future.
I have an ISP customer with around 200 POP's and OSPF scalability is a real problem. We have had to make active efforts to remove any dynamic interfaces from OSPF and reduce the prefix count to minimise SPF re-calculations from loading up router CPU's. IS-IS would vastly minimise these specific problems.IS-IS can scale much larger than OSPF due to the way it designs the hierarchy of flooding domains and by using Incremental SPF. This is why it's used as the IGP of choice for most large ISPs and Data Centers
I recently found out at the European MUM that OSPFv2 has a bug that will only allow 120 LSAs under certain conditions and cannot fragment the data beyond a single packet in the OSPF database exchange. The workaround is to use the highest MTU possible but it still can't be fixed in the current RouterOS version.
Wonder if this is at the root of issues with large scale OSPF deployments that we've seen
They would have to invent an ISO-protocol stack with CLNS, ISO addressing and all that in order to make it work. There are no such implementations for Linux, so they would have to engineer it from the bottom.
What are those conditions? I haven't seen anything like that, and checking just now, I have 296 'router' LSAs and 344 'network' LSAs (plus 4 external LSAs that shouldn't be there... got some fixing to do there :-/ ), all working fine.
--Eric
This shouldnt be the answer from official support team!I don't see any reason why MT needs IS-IS, it already have OSPF which is also coooool protocol
So if you want IS-IS support, start testing RouterOS v7 routing functionality and providing reports back to Mikrotik. This will help RouterOS v7 stabilize more quickly, so the devs can move on to cool new stuff like IS-IS.Our main priority at this point is to make currently implemented protocols stable enough and only then we can consider adding something new that never existed in ROS.
So if you want IS-IS support, start testing RouterOS v7 routing functionality and providing reports back to Mikrotik. This will help RouterOS v7 stabilize more quickly, so the devs can move on to cool new stuff like IS-IS.
haha ... EIGRP ... would be fun yes. would be GREAT yes.+1 for IS-IS
+1000 for EIGRP which is not Cisco proprietary and hasn't been for years
Differences between OSPF and ISIS
OSPF operates on the top of IP layer whereas ISIS operates over Layer 2.
OSPF can support virtual links but ISIS can not support (as it operates on Layer 2 directly).
OSPF elects a DR and BDR on broadcast networks which can not be pre-empted however, ISIS elects a single DIS which can be pre-empted.
IP connectivity between the routers to share the routing information is required in case of OSPF, while ISIS doesn’t require IP connectivity as the updates are sent via CLNS instead of IP.
OSPF is prone to attacks hence security overheads are required for protection. The possibility of attacks is very less in case of ISIS as it runs over Layer 2.
OSPF designates a backbone area and standard or non-backbone area for inter-area advertisements whereas ISIS organizes the domain into different levels.
To identify a router on the network, OSPF uses Router ID and ISIS uses System ID.
OSPF is less flexible with more strict requirements for forming neighbor adjacencies. The hello and dead intervals, and the subnet mask must match (except on point-to-point links).
Completely off-topic, but both features are needed and long overdue.I'd rather like to see IPSEC VTI in ROS. Shouldn't be too much of an issue since it is possible with the Kernel currently used in ROS 7...
I am ecstatic about IS-IS making it's way into RouterOS.
...or implement a .npk package of FRRoutingWell, there probably was an important customer/prospect who insists on having IS-IS.
In general I do not like that MikroTIk embarks on so many new projects, while leaving existing ones unfinished.
I would say: first make sure all those red and yellow squares in the routing status page are removed, only THEN start adding a new protocol...
because there really isn't one that handles this explicitly. I've asked for batman-adv in mikrotik which handles metric via quality measurement rather than link state but it seems there's no interest. I've even posted on here to see if other users would support it because mikrotik may consider it if it's a popular want, low response.What could be of value in the typical wireless network is to have automatic adjustment of metric values (cost) depending on values retrieved from a wireless link (via SNMP, as the link devices may be separate from the router devices).
The usual naive "prefer least number of hops" does not work well in a partly meshed WiFi-linked network, and it often surprises me that MikroTik does not offer a routing protocol that handles this case (which is typical for clients of their product gamma).
In fairness, they do have HWMPplus (which I've always thought was batman-adv clone, perhaps not...) but never used it.I've asked for batman-adv in mikrotik which handles metric via quality measurement rather than link state but it seems there's no interest. I've even posted on here to see if other users would support it because mikrotik may consider it if it's a popular want, low response.What could be of value in the typical wireless network is to have automatic adjustment of metric values (cost) depending on values retrieved from a wireless link
[...]
[...]
batman-adv would also present a flat layer2 to the operator without layer2 pitfalls which would dramatically simplify networks.
It's a real problem e.g. lack of innovation in routing beyond Dijkstra / link-state protocols. i.e. choosing path with multiple LTE uplinks, where signal metrics change frequently...and signal is likely most important thing for upstream route selection.Yes I know it is a difficult problem, but still it surprises me that there is no support for it at all.
This would just add complexity with ASIC/Hardware offloading....or implement a .npk package of FRRouting
Ok children, gather around the fire. Story time!However, it says a routing protocol suite, not an operating system? What is it you are proposing?
How easy is it, for example, to rip out the RoS routing stack and inject a new one........ is it a modular thing?
LOL. For a company that likes re-writing routing code, EIGRP would seem like an ideal canvas. IS-IS gets them "current" for sure ... but I could see how EIGRP actually sell more routers ... than different yet another branch of Quagga...Ok children, gather around the fire. Story time!However, it says a routing protocol suite, not an operating system? What is it you are proposing?
How easy is it, for example, to rip out the RoS routing stack and inject a new one........ is it a modular thing?
Yes, I fully agree with that. In wireless networks, a link with multiple hops may well be better than a link of a single hop.(long text)
You can do a lot in script, but if all your routing logic is in a long/complex scheduler/netwatch script, it quickly becomes an ugly hack and difficult to maintain. I think @msatter's [PROPOSAL] Event driven scripting deserves some consideration. If scripts to control routing were more tied to "events" (change in config/counters/snmp/routes/etc)... it be WAY less of a "hack" and cleaner to apply heuristic-based routing on top of existing protocols (and, eventual, IS-IS)."Preferably not via a scripting hack."
[...]
I would be pretty cool to have a config item in a peer setup that was like "get capacity metric from snmp: snmpwalk oid x multiply by y to get it into usable" and then "get utilization from" etc. Then poll that and average it over a configurable timeframe.
That could make an ISIS implementation (that has partial updates... not OSPF....) much more dynamic.
[...]
What would be great is some signaling protocol using some of the batman-adv traits but then wrote routes straight to the FIB so native HW accell and fast tracks would work would be awesome.
I don't know. But what I do know is the open source network community is moving at light speed vs network vendors. The price to performance/feature ratio is better with open networking vendors like say Cumulus or vBNG vendors that are using DPDK/XDP to push 100Gbps line-rate networking on commodity x64 hardware or ONIE hardware.How easy is it, for example, to rip out the RoS routing stack and inject a new one........ is it a modular thing? Would one then have to redefine all the ICDs between modules...... imagine that many are standard so maybe only modify proprietary items?
Maybe, maximal possible throughput at any cost on x86_64 should *not* be Mikrotiks focus since there are so many alternatives already?MikroTik should make use of DPDK for packet forwarding/originating from the router itself and use XDP hardware offloaded mode for packet filtering. Their existing hardware line can definitely hit peak line-rate performance.
What are you talking about? I'm talking about CCR, CRS and RB series, arm64 devices.Maybe, maximal possible throughput at any cost on x86_64 should *not* be Mikrotiks focus since there are so many alternatives already?
/routing/stats/process/print where tasks=isis
# TASKS PRIVATE-MEM-BLOCKS SHARED-MEM-BLOCKS PSS RSS VMS ID PID RPID PROCESS-TIME KERNEL-TIME MAX-BUSY MAX-CALC
11 isis 0 0 0 0 0 12 402 1 2s870ms 3s340ms 10ms 10ms
/ip/route/print where is-is
/routing/route/print where is-is
ip/route/print where
.dead bgp comment distance gateway is-is pref-src static vrf-interface
.id bgp-mpls-vpn connect dst-address hw-offloaded local-address rip suppress-hw-offload
.nextid blackhole dhcp dynamic immediate-gw modem routing-table target-scope
active check-gateway disabled ecmp inactive ospf scope vpn
I see no mention of it in the patch notes and no routing is-is menu or CLI commandsThis page was updated along with 7.12 release:
/routing fantasy
It a feature to test BGP (or presumable IS-IS, eventually)MikroTik playing a cruel joke perhaps?Code: Select all/routing fantasy
100%All I can say is FANTASTIC!!!! I won't ask for any concrete information but I do hope its at least IPv4 functionally capable for production use within a years time. OSPF is, always has been and always will be an utterly shit protocol for ISP and especially WISP environments. It's just completely the wrong protocol for it and does not allow growth and implementation that matches reality. So the sooner I can dump it in favor of IS-IS for backhaul the better
quick guess ... they are working on it right now.yep, it's in 7.13b1. I've got it up in the lab. pretty straight forward, although I'm having some issue with it forgetting disabled or removed routes. but it does bring routes up so that's step 1! Also, no BFD toggle, BFD is essential for ISIS.
oh yeah, no criticism here, I'm happy to have rought it up in the lab so easily.quick guess ... they are working on it right now.yep, it's in 7.13b1. I've got it up in the lab. pretty straight forward, although I'm having some issue with it forgetting disabled or removed routes. but it does bring routes up so that's step 1! Also, no BFD toggle, BFD is essential for ISIS.
depends. and 'virtual links' is a big ambiguous. IS-IS requires an ethernet-like layer2 interface, it wont run over IPIP or Wireguard for example, but it will certainly work over anything that looks like layer2, EOIP tunnels, VPLS, WDS, etc.Looking way back at the comparison table, Virtual Links Supported ( ospf yes / is-is NO ). Isnt that a plus for OSPF?
I am looking forward to try IS-IS over primarily Zerotier tunnels (Layer 2). Either than, or VXLAN tunnels (over Layer 3 tunnels). Not to keen on maintaining OpenVPN tap tunnels.depends. and 'virtual links' is a big ambiguous. IS-IS requires an ethernet-like layer2 interface, it wont run over IPIP or Wireguard for example, but it will certainly work over anything that looks like layer2, EOIP tunnels, VPLS, WDS, etc.Looking way back at the comparison table, Virtual Links Supported ( ospf yes / is-is NO ). Isnt that a plus for OSPF?
yes, and we do this, prefer it to OSPF (way faster...)When you are just looking for a routing protocol that can do routing in a MikroTik environment, e.g. for VPN, you can just as well use eBGP.
It works quite well and is easy to configure (although in v7 not as easy as in v6). Once you get the hang of it, you get it working in 5 minutes.
It might interest you to know that Ubiquiti (yes, them) is using VPP on their 60Ghz Wave line now. I’m not a big fan of how ADHD Ubiquiti is, so don’t worry about me being a fanboi. It was just interesting when I dug in to the CLI in a Wave device and found a vppctl binary; was able to tease the config out and, yep.I don't know. But what I do know is the open source network community is moving at light speed vs network vendors. The price to performance/feature ratio is better with open networking vendors like say Cumulus or vBNG vendors that are using DPDK/XDP to push 100Gbps line-rate networking on commodity x64 hardware or ONIE hardware.How easy is it, for example, to rip out the RoS routing stack and inject a new one........ is it a modular thing? Would one then have to redefine all the ICDs between modules...... imagine that many are standard so maybe only modify proprietary items?
Times are changing fast, to the point Cisco themselves stole from open source:
https://fd.io/
MikroTik should make use of DPDK for packet forwarding/originating from the router itself and use XDP hardware offloaded mode for packet filtering. Their existing hardware line can definitely hit peak line-rate performance. But that's not going to happen with MikroTik. Hence, we should move to open source derivatives.
Hell even VyOS added support for DPDK/VPP recently to support 100Gbps performance.
Anyone that has a decent 60Ghz product uses vpp. UBNT was using it before "Wave". Their initial Qualcomm 60Ghz utilized vpp as most vendors were jumping on the terragraph wagon and terragraph uses vpp and dpdk. Even if manufactures opted for PTMP over terragraph mesh I think that terragraph really brought the pieces together and gave the manufactures the software concepts to make these products a reality. It's a no-brainer that Mikrotik should implement vpp / dpdk. The question is if they are chasing consumer markets or service provider markets. They would see much more service provider sales with routers that have muscle. The only real way forward is L3HW that is big enough to handle full tables or 8 & 16 core vpp / dpdk routers that can move 100G w/o L3HW offload.It might interest you to know that Ubiquiti (yes, them) is using VPP on their 60Ghz Wave line now. I’m not a big fan of how ADHD Ubiquiti is, so don’t worry about me being a fanboi. It was just interesting when I dug in to the CLI in a Wave device and found a vppctl binary; was able to tease the config out and, yep.
I don't know. But what I do know is the open source network community is moving at light speed vs network vendors. The price to performance/feature ratio is better with open networking vendors like say Cumulus or vBNG vendors that are using DPDK/XDP to push 100Gbps line-rate networking on commodity x64 hardware or ONIE hardware.
Times are changing fast, to the point Cisco themselves stole from open source:
https://fd.io/
MikroTik should make use of DPDK for packet forwarding/originating from the router itself and use XDP hardware offloaded mode for packet filtering. Their existing hardware line can definitely hit peak line-rate performance. But that's not going to happen with MikroTik. Hence, we should move to open source derivatives.
Hell even VyOS added support for DPDK/VPP recently to support 100Gbps performance.
On a related note, I think there might be a niche to be filled in our market. It might make sense to offer a generic arm64-based routing appliance that runs all open source software. Run whatever you want on it. It’s just Linux. Offer a value-add OS and support maybe.
I know Netgate offers something like this with TNSR, but it’s not quite a perfect fit for us.
I really like Winbox, and especially couldn’t live without RoMON (which has saved me countless truck rolls in the middle of the night).
It would be stupid if they have a 128 core ampere doing 90s routing vs running vpp / dpdk.remember, there's new ampere chips coming soon. that might come with some routing surprises as well. I doubt those are being brought it just for control plan on marvell switch chips.
exactly.It would be stupid if they have a 128 core ampere doing 90s routing vs running vpp / dpdk.remember, there's new ampere chips coming soon. that might come with some routing surprises as well. I doubt those are being brought it just for control plan on marvell switch chips.
I'm a bit mixed on the new high core count moves. Frankly, for pure routing the 2004 and 2116 are blazing fast, optimizing routeros to use more cores would just keep making those better and better.
The biggest problem I'm seeing still comes down to single core performance. BGP is way faster, but still can get stomped handily by a FRR box on a modern intel chip. A shaping tree get's stuck in a single CPU core. SNMP gets stuck on a single CPU core.
Granted, you could work through some of those limitations by making them multi-threaded but some things are just not well suited for it. A shaper tree for instance sort of needs to have the top level HTB on a single core or some careful balancing of average traffic which would need a separate and new tool from mikrotik, and BGP needs to have each peer on a single core because moving data between cores is so much slower as to negate multi-threading gains.
I think it's a long shot but mikrotik dropping a 13-14th gen xeon box or similar ryzen box with really high core speeds would be awesome. I know there are ways to get routeros on that hardware, CHR, hacking x86 installer into a CHR on bare metal etc, but I'm not really interested in that. I want a *MIKROTIK* box in 1U with port options etc. Like a CCR2004-* but with a very high clock high performance CPU. Frankly, the only ARM series chip that would be interesting here is Apple's, everyone else is well behind on single core performance. Frankly, the i3-13100F would be so incredible in a ccr2004-12SFP+ format...
why use CHR ?? is mikrotik v7 RoS runs great in bare metal...
Hello,7.13 IS-IS is available on cli .
Thank you Mikrotik.