Ah yes, forgot to mention about BFD
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.
Like I said, those problems are known and will be addressed in the future.
Like I said, those problems are known and will be addressed in the future.
Thank you for all the hard work on IS-IS Maris and team.
Hi
Since 7.15 is just around the corner, can we have the fix in 7.16 please?
7.15 is the 4th release that doesn’t have any improvement on IS-IS
Will be nice to add segment routing as feature request for ISIS
https://datatracker.ietf.org/doc/rfc8667/
Will be nice to add segment routing as feature request for ISIS
https://datatracker.ietf.org/doc/rfc8667/
+1
Second this. As Segment Routing is actually just an extension of IGP, instead of new protocol
SRv6 deserves it’s own thread.
it still requires a separate IGP, and IS-IS would be a pretty nice option.
OSPFv3 is fine. ‘fine’. it’s ok. sure would like IS-IS.
Is is-is support wide metic in v7.15 ??
Is is-is support wide metic in v7.15 ??
IS-IS is basically alpha, so no nothing is really supported. It’s fun to lab up but no where near production.
Yep, asking about features at this stage is a bit like asking if you can move boxes into the attic of your new house and it’s still just a timber frame
Nowhere even close yet. Let’s get fundamentals in and properly integrated before contemplating anything else. Though I wish MikroTik would put some more emphasis and focus on that. It seems nothing has happened for a while
If they’re trying to gauge how important it is and how many people are using it, well it’s completely impossible when we can’t actually run it outside of a lab environment. Once that happens and it has fundamental winbox integration I’ll put it in alongside existing OSPF deployment and start providing feedback
Is is-is support wide metic in v7.15 ??
Don’t think so
Is is-is support wide metic in v7.15 ??
7.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
7.16beta1 is out
and now IS-IS neighbor with cisco is not coming up21: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:C0but 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
Ok I can bring neighbor up, but only as broadcast
Previously, ptp works
And IPv6 neighbor still not coming up, either using ptp or broadcast
Hi 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.
Hi all, again!
At ROS 7.16beta2 when i use default mtu 1500 isis connecting with juniper correctly. But if i set another mtu 1501 or 9000 at RB4011iGS+ isis is not connecting. Dump says that ROS forming incorrect isis hello packet with ethernet frame potocol type field.
Hi 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.
TCPDUMP v4.99.3-1 prints the same error (on Debian Bookworm).
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
(...)
Same error printet by FRR 10.0.1-0~deb12u1 (on Debian Bookworm).
isisd[186043]: [S3Q88-7FRPP] ISIS-Upd (backbone): LSP xxxx.xxd6.2f6a.00-00 invalid LSP is type 0x2
This is with ROS 7.16beta3
& MT+Debian mtu=9194
& MT l2mtu=10218
Also with Huawei CloudEngine 6860-48S8CQ-EI and Huawei WTN 910D-A showing same result like you guys.
For 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.