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.
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?
I recall there was/is kernel support, so maybe it isn't that difficult. Dunno.Back to batman-adv
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.
I totally agree with this. Lost a lot of hours trying to bring up adjacency between RouterOS (CCR2004) and IOS XR (NCS540 Series). Does not work with MTU above 1500; tried tuning l2-mtu, mtu and lsp-max-size with no success. The session was up and LSPs exchanged only when the MTU was set to 1500 on both ends.rc3 , IS-IS still far from usable
1. still limited to 1500 MTU
2. dual stack , IPv6 not established
3. MikroTik and Juniper is not exchanging LSP's
4. no option for metric style wide
5. other routing protocols still can't redistribute IS-IS
if it's far from functional, please put the tag as "initial support" like on 7.12 , instead put it as "working" in hereYes, IS-IS is in early development and there are known problems that will be addressed in the future.
agreed on both points. documentation is ahead of things and ISIS on the bench seems the same as day 1.if it's far from functional, please put the tag as "initial support" like on 7.12 , instead put it as "working" in hereYes, IS-IS is in early development and there are known problems that will be addressed in the future.
https://help.mikrotik.com/docs/display/ ... l+Overview
when we saw it tag as "working", we'll spend a lot of time to make sure we're not doing something wrong why it didn't work
because honestly speaking, I don't see any improvement in IS-IS since 7.12 until now
Ah yes, forgot to mention about BFD
Also, BFD is not an option for IS-IS, basically you cannot trigger down IS-IS adjacency using BFD (option not available, like it is available for OSPF). So, for fast convergence you must rely on tight IS-IS timers.
I would assume that would come with a full release with winbox section etc. lack of BFD prevented many people from using routeros v7 for a long time. ISIS is completely useless to me without BFD.Ah yes, forgot to mention about BFD
Also, BFD is not an option for IS-IS, basically you cannot trigger down IS-IS adjacency using BFD (option not available, like it is available for OSPF). So, for fast convergence you must rely on tight IS-IS timers.
Thank you for all the hard work on IS-IS Maris and team.Like I said, those problems are known and will be addressed in the future.
+1Will be nice to add segment routing as feature request for ISIS
https://datatracker.ietf.org/doc/rfc8667/
Ok I can bring neighbor up, but only as broadcast7.16beta1 is out
and now IS-IS neighbor with cisco is not coming up
21:26:21 route,isis,warning instance 0100.0100.4001 vlan1141 invalid 3way tlv nbr from D4:E8:80:C2:4A:C0
21:26:26 route,isis,warning instance 0100.0100.4001 vlan1241 invalid 3way tlv nbr from 74:88:BB:BB:F6:C0
but the strange thing, Cisco side seeing the neighbor as up
#sho isis neighbors | i 0100.0100.4001
0100.0100.4001 L2 Po1.1141 100.111.4.2 UP 27 03
#sho clns neighbors | i 0100.0100.4001
0100.0100.4001 Po1.1141 e48d.8c7a.8fb1 Up 27 L2 IS-IS
IANA IS-IS PDU RegistryHi all.
If i specify isis level l2 only.
[admin@RouterOS] /routing/isis/interface-template> print
0 instance=isis-instance-1 interfaces=eth1 levels=l2 ptp
Mikrotik generate lsp with mistake isis.lsp.is_type field (wireshark notation) in binary 10. Juniper at other side print errors in logs "bad IS type 2"
When the correct value is 11.
18:04:10.791396 IS-IS, length 340
L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (6), max-area: 3 (0)
0x0000: 831b 0106 1401 0000
lsp-id: xxxx.xxd6.2f6a.00-00, seq: 0x00000002, lifetime: 1200s
chksum: 0x3559 (correct), PDU length: 340, Flags: [ Unused 0x2 (invalid) ]
0x0000: 0154 04b0 xxxx xxd6 2f6a 0000 0000 0002
0x0010: 3559 02
Protocols supported TLV #129, length: 2
NLPID(s): IPv4 (0xcc), IPv6 (0x8e)
0x0000: cc8e
IPv4 Internal Reachability TLV #128, length: 24
(...)
IPv4 Internal Reachability TLV #128, length: 60
(...)
Extended IPv4 Reachability TLV #135, length: 63
(...)
IPv6 reachability TLV #236, length: 154
(...)
isisd[186043]: [S3Q88-7FRPP] ISIS-Upd (backbone): LSP xxxx.xxd6.2f6a.00-00 invalid LSP is type 0x2
From the description. I would assume a Layer 2 misconfiguration. Rather than an IS-IS problem. https://help.mikrotik.com/docs/display/ ... interfaces Concerning why Fast path gets disabledFor me (RB1100AHx2, CRS309-8S+1G, both running 7.15.2 but confirmed on the RB1100AHx2 running 7.15.3) when IS-IS is configured on a VLAN interface that is a slave of a bridge, it kills fast path and fasttrack. I don't know if this is expected behaviour, but took me a couple of hours of digging today why fasttrack wasn't enabling.
This doesn't happen if the VLAN added as an IS-IS interface is a slave of an ethernet port and then that ethernet port or the slaved VLAN is added as bridge port, only when VLAN interface is slaved to the bridge.
/interface bridge
add name=loopback0
/ip address
add address=172.16.8.61 interface=loopback0 network=172.16.8.61
/interface vlan
add interface=sfp-sfpplus1 name=ISICP160BOGLAB vlan-id=5
/ip address
add address=192.168.5.250/30 interface=ISICP160BOGLAB network=192.168.5.248
/routing isis instance
add afi=ip areas=49.0170 disabled=no l2.lsp-update-interval=50 l2.redistribute=connected name=CP136BOGLAB system-id=1720.1600.8061
/routing isis interface-template
add instance=CP136BOGLAB interfaces=ISICP160BOGLAB,loopback0 levels=l2 ptp
isis 1
cost-style wide
timer lsp-generation 1 50 50 level-2
flash-flood level-2
network-entity 49.0170.1720.1600.8254.00
is-name CP160BOGLAB
import-route direct
#
interface GigabitEthernet0/2/1.5
vlan-type dot1q 5
description ISICP136BOGLAB
ip address 192.168.5.249 255.255.255.252
isis enable 1
isis circuit-type p2p
isis cost 2000
mpls
mpls ldp
statistic mode forward
#
memory , route, isis, warning instance 1720.1600.8061 ISICP160BOGLAB max area address mismatch from 60:08:10:19:89:1D
Hi jlopez,Code: Select allmemory , route, isis, warning instance 1720.1600.8061 ISICP160BOGLAB max area address mismatch from 60:08:10:19:89:1D
/routing isis instance
add afi=ip areas=49.0170 areas-max=3 disabled=no l2.lsp-update-interval=50 l2.redistribute=connected name=CP136BOGLAB system-id=1720.1600.8061
Basically, 0==3 when evaluating max-area. It seems that RouterOS does not adhere do this part of the standard, yet.Maximum Area Addresses — number of area addresses permitted for this ISs area, as derived from the value of the System Management parameter maximumAreaAddresses. This field shall take on of the following values:
• An integer between 1 and 254 inclusive, indicated a corresponding number of area addresses supported.
• The value zero, which is treated upon reception as if it were equal to three, and which the IS may use if it supports only a value of 3 for maximumAreaAddresses.
[lexi@a2.i.lfns.org.uk] /routing/isis> /ipv6/route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DA ::/0 fe80::400:ff:fe00:a01%ether5-c2.i 115
DAc ::1/128 lo 0
DA 64:ff9b::/96 fe80::400:ff:fe00:a01%ether5-c2.i 115
DA 2001:8b0:aab5::/48 fe80::400:ff:fe00:a01%ether5-c2.i 115
DA 2001:8b0:aab5:1::1/128 fe80::400:ff:fe00:a01%ether5-c2.i 115
DA 2001:8b0:aab5:3::1/128 fe80::400:ff:fe00:a01%ether5-c2.i 115
DAc 2001:8b0:aab5:3::2/128 lo 0
DA 2001:8b0:aab5:3::3/128 fe80::400:ff:fe00:a01%ether5-c2.i 115
DA 2001:8b0:aab5:3::4/128 fe80::400:ff:fe00:a01%ether5-c2.i 115
[... etc... ]