I hope MikroTik does a clean, fresh, codebase for ROS v8 with fresh kernel base (latest long-term version at that point in time). Otherwise, we’re really f***ed. At this point, Debian + FRR or BIRD or VPP is far more stable.
(already said a couple of time in the last months .. and sent support requests)
Old v6 command “ip route check x.y.z.k” still missing!
e.g. /ip route check 8.8.8.8 (linux equivalent “ip route get 8.8.8.8”)
It’s very usefull when you have many routes in your routing table and you don’t want to waste your time looking for the best match (and/or make mistakes chosing the wrong one when in a hurry or under pressure!)
it should be trivial to get it done..
Works for me in any version above 7.11
[admin@MikroTik] /ip/route> /ip vrf/print
Flags: X - disabled; * - builtin
0 name="xx" interfaces=none
1 * name="main" interfaces=all
[admin@MikroTik] /ip/route> /routing/route/print where routing-table=xx
Flags: U - UNREACHABLE; s - STATIC; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE
UsH 0.0.0.0/0 1.2.3.4 ip4 1 30 10
Did you planned fixing upgrade routeros from dude?
Dear Mrz,
please take a look this attachment.
this is when interfaces set to loopback
and this when i set interfaces-list into "none
thx
And what is your previous version? 7.11.2?
Alias Commands (with args) would be a helpful solution to that…
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41570
“MikroTik RouterOS v7.1 to 7.11 was discovered to contain incorrect access control mechanisms in place for the Rest API.”
MikroTik’s stance of pretending that problems don’t happen, and only recording in their release notes the CVEs that have immense repercussions is something they should feel ashamed of doing.
https://www.enricobassetti.it/2023/11/cve-2023-41570-access-control-vulnerability-in-mikrotik-rest-api/
Timeline
I followed the responsible disclosure process described in the “Responsible disclosure of discovered vulnerabilities” page. I reported the vulnerability at 2023-08-19 09:46:00 UTC and received the ACK at 2023-08-24 07:43:00 UTC. The fix was released in version 7.12 at 2023-11-09 09:45:00 UTC (time point from RouterOS changelog).
Has anyone other than me noticed that this 7.12 update “killed” the stub area? I use stub area to summarize the PPPoE IPs and other IPs on each routerboard and only export /24 or larger blocks from the routerboard. I used it as follows and it works on 7.11.2 and earlier, but after updating to 7.12 it stopped working and even deleting, resetting and configuring it again, the routerboard doesn’t work.
/routing ospf instance
add disabled=no name=backbone-v2 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main
add disabled=no name=backbone-v3 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main version=3
/routing ospf area
add disabled=no instance=backbone-v2 name=backbone-v2
add disabled=no instance=backbone-v3 name=backbone-v3
add area-id=0.0.0.66 disabled=no instance=backbone-v2 name=area-stub-v2 type=stub
add area-id=0.0.0.66 disabled=no instance=backbone-v3 name=area-stub-v3 type=stub
/routing ospf area range
add area=area-stub-v2 cost=10 disabled=no prefix=10.177.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=100.70.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=100.71.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=172.17.66.0/24
add area=area-stub-v3 cost=10 disabled=no prefix=2804:XXXX:XXXX::/48
/routing ospf interface-template
add area=backbone-v2 cost=10 disabled=no interfaces=loopback networks=192.168.0.66/32 passive priority=1
add area=backbone-v3 cost=10 disabled=no interfaces=loopback networks=2804:XXXX:XXXX::/64 passive priority=1
add area=backbone-v2 cost=10 disabled=no interfaces=vlan10 networks=172.17.37.8/29 priority=1 type=ptp
add area=backbone-v3 cost=10 disabled=no interfaces=vlan10 priority=1 type=ptp
add area=area-stub-v2 comment="AREA STUB" cost=10 disabled=no networks=10.177.66.0/24,100.70.66.0/24,100.71.66.0/24,172.17.66.0/24 passive priority=1 type=ptp
add area=area-stub-v3 comment="AREA STUB" cost=10 disabled=no networks=2804:XXXX:XXXX::/48 passive priority=1 type=ptp
The only thing that I found strange (but it only works like that), was having to announce the stub area with type=ptp, instead of type=broadcast.
I’ve been struggling with upgrading my hAP AX3 from 7.8. Any releases after, including 7.12, break it with the same disconnection behaviour on the log (see attachment). This setup has worked for me back in the 6.x (hAP AC) up until 7.8 (hAP AX3). I’ve combed through my config several times but couldn’t find any obvious misconfiguration issues. I’m hoping somebody more knowledgeable than me can help. It’s a “simple” setup and a short config. I would really appreciate your help, good people!
My hEX S has been upgrading like a champ and is on the latest 7.12 ROS version.
Update: Issue Fixed
- Turns out I just had to set the wireless interfaces as tagged instead of untagged under interface/bridge/vlan.
I don’t know how I had that setup running for years but it ran without any issue. I had to reread the manual to find the answer for this updated ROS version.
I’ve noticed this problem too. type=PTP doesn’t fix it. I’ll open a ticket with Mikrotik.
Edit:
Or not. Support portal is down lol
That is correct! Many functions that are readily available as open source projects are being re-implemented. Not everything, though.
We can only guess what is the reason. Maybe they don’t like the licensing terms, maybe they don’t want to contribute code back to the upstream when that is a requirement, maybe the open source versions are just too large to fit in that silly 16MB flash that so many MikroTik devices have.
OpenVPN is a wellknown troublespot. It is not an accident that they call it “ovpn” and not “OpenVPN”. It is just a VPN that often interworks with OpenVPN, and also often not.
Another one is the DNS resolver. It has been broken again and again during extenstions with new functions, that are often done in a quite peculiar way (look at DoH…). And after all that, we still don’t have DNSSEC support.
It would have been so much better when a well-developed and tested open source resolver had been taken onboard. I would say “unbound”, others maybe say “dnsmasq”. But it would have been through all the cycles of bugs that we now saw in RouterOS, and more feature-complete as well.
Yet they decide to waste time on development. Probably for a good reason, and the space restriction may be an important one.
…
I would say “unbound”, others maybe say “dnsmasq”
I would also say “powerdns” 
While I agree with your sentiments, at least since we have Docker this can be solved easily.
I started to run PowerDns and dnsmasq images, both working with almost no issues. Especially on the CCR2xxx with internal SSDs. But also on RB5009 with external USB SSD.
something like that really needs to be implemented ASAP.
even a route table below 200 routes is a PITA to search and look if a given DST matches a fdb installed route!
look at the cisco equivalent “show ip route x.x.x.x” or checkpoint “show route destination x.x.x.x”
cisco “show ip route x.x.x.x” is not equivalent to “ip route check”.
You can already do the same as ciscos show ip route with
ip route print where x.x.x.x in dst-address
neither is
ip route print where x.x.x.x in dst-address
an equivalent to cisco “show ip route x.x.x.x”
cisco gives a definitive result which mirrors the routers routing decision rather then MTs version of “hey i got these routes which MIGHT could be used to route your asked DST”
a “show” cmd. to reflect the routers routing decision to the current FDB would be great.
maybe there is one i do not know about yet…
It seems that v7.12 stable will not generate OSPF LSA type3 - “inter-area-prefix“ while v7.11.2 stable is ok.
Here are configs:
[admin@ROS7.11.2A] >export
/ip address
add address=10.0.0.1/24 interface=ether1 network=10.0.0.0
add address=192.168.1.1/25 interface=ether2 network=192.168.1.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.1.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1
/routing ospf area range
add area=1 disabled=no prefix=192.168.1.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=1 disabled=no interface=ether2
[admin@ROS7.11.2B] >export
/ip address
add address=10.0.0.2/24 interface=ether1 network=10.0.0.0
add address=192.168.2.1/25 interface=ether2 network=192.168.2.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.2.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2
/routing ospf area range
add area=2 disabled=no prefix=192.168.2.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=2 disabled=no interface=ether2
[admin@ROS7.12A] >export
/ip address
add address=10.0.0.3/24 interface=ether1 network=10.0.0.0
add address=192.168.3.1/25 interface=ether2 network=192.168.3.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.3.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3
/routing ospf area range
add area=3 disabled=no prefix=192.168.3.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=3 disabled=no interface=ether2
[admin@ROS7.12B] >export
/ip address
add address=10.0.0.4/24 interface=ether1 network=10.0.0.0
add address=192.168.4.1/25 interface=ether2 network=192.168.4.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.4.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4
/routing ospf area range
add area=4 disabled=no prefix=192.168.4.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=4 disabled=no interface=ether2
I’ve opened a ticket in support portal, SUP-134571
What makes you think mikrotik does not comply? Internet rumors? posts from 10 years ago?
Unfortunately it is not that easy. Remember you can have multiple routing tables with rules, route marking in mangle, and even VRF.