We would like to know the typical use cases of routing rules and the reason why such an approach is used.

Routing rules in MikroTik are used to specify how traffic should be routed through a network based on certain criteria, such as the destination address, protocol, or port. There are several use cases for routing rules in MikroTik devices, including:

• Load balancing: Routing rules can be used to distribute traffic across multiple WAN connections or interfaces to improve network performance and reliability.

• Traffic filtering: Routing rules can be used to block or allow traffic based on various criteria, such as the source or destination address, protocol, or port. This can be used to implement security measures or to control access to certain network resources.

• Policy-based routing: Routing rules can be used to specify different routing paths for different types of traffic based on policy. For example, you might want to route traffic from a specific IP address or subnet through a different interface or gateway.

• QoS (Quality of Service): Routing rules can be used to prioritize certain types of traffic over others based on their importance or bandwidth requirements. This can be used to ensure that critical applications have sufficient bandwidth and to prevent network congestion.

Overall, routing rules are an important tool for configuring and managing network traffic in MikroTik devices, allowing you to customize the behavior of your network according to your specific needs and requirements.

We are well aware of theoretical usecases.

What is being asked is use case in the real setup and why the route rules were used instead of other means to achieve the goal.

There are several reasons why routing rules were and "are" used instead of other means or methods:

• Flexibility: Routing rules offer a high degree of flexibility in terms of the criteria that can be used to specify routing policies. This allows you to customize the behavior of your network according to your specific needs and requirements. For example, you can use routing rules to specify different routing paths for different types of traffic based on the source or destination address, protocol, or port.

• Granular control: Routing rules allow you to specify routing policies at a very granular level, which can be useful in scenarios where you need to fine-tune the behavior of your network. For example, you can use routing rules to prioritize certain types of traffic over others based on their importance or bandwidth requirements.

• Ease of use: Routing rules are easy to configure and manage, making them a convenient tool for network administrators. In many cases, routing rules can be created and modified directly from the MikroTik RouterOS interface, without the need for complex scripting or programming.

Bored in Latvia........ do your own homework, its not rocket science, use of routing rules for most people is
a. easy
b. avoids mangling
c. best method to force user to use a particular route ( when its a small number of users or entire subnets )

If you are looking for information on complex scenarios and how routing rules help out, then ask specifically,
the vague wide question you posed seems ludicrous for your level of knowledge.

My actual uses cases all involve LTE devices, specifically with multiple LTE modules/modems & routers that may be deployed for different short-term needs, in different, typically remote place. But often there is a desire to direct traffic of some set of devices out a specific LTE (or other WAN) by someone who may know how enough to setup a Netgear Nighthawk...but VLAN/bridging be a mystery, and FW rules ("mangle") to control routing isn't the first idea even seasoned IT would have. @anav is more patient than I on the latter, why I like the "routing rules" - less explaining.

While there is a lot of config to deal with multiple WANs, we abstract that into a set of 6 fix routing tables*, each with a specific "role" (e.g. going out "primary LTE" only, "secondary LTE" only, ECMP, etc.). We also use recursive routing, and it's 6 since the old/orginal BBN DNS still work and helpfully since sequentially numbered: 4.2.2.1 ... 4.1.1.6, a routing table "route1" match the 1st recursive route, etc. So any potential "extra WAN" are "pre-wired" to use the routing rules.

所以“路由规则用例”是“non-Mikrotik雷竞技网站admin" can at least define what define what range or IP goes out where on their own – without having knowing nothing much about the rest of the configuration needed to support thatflexibility. And redirecting a subnet or device be may be need for a few reasons:
- if one LTE carriers/WAN becomes slow/unavailble
- if both work well enough ECMP can be used
- someone wants to break up traffic so "mission critical" device has a dedicated LTE connection
- a satellite uplink, or some fiber, cable, etc WAN is available at the temporary location.

Since we control the 6 "WAN slots", the "dumb admin" just picks the right table for the subnet in most cases to select the internet path to use.

The only "issue" is since we use the routing rulesonly for WAN/internet traffic, we need to add a boilerplate at top to send [most] private addresses to "main". I do think trying to do both inter-LAN routing and WAN routing using PBR/"routing rules" at the same time is where things can more complex/impossible – why I perfer to defer inter-LAN routing to the "main" and firewall. Generally we use VLAN only to limited broadcast scope, and want global Layer 3 routing between all devices/VLAN– this may not be typical. But it is a "don't delete the first three lines!":

In our case, we use a webfig skin to hide most things, so the "Routing > Rules" is quite intuitive (and if you only show PVID in bridging, avoids any mysteries).Long way to say I'm not unhappy with the current situation in routing rules.. But it is a lot of syntax to initially setup things up to use the rules efficiently....

If you're talking more generically about "routing rules" than just PBR. I'd say making /interface/internet-detect smarter – or something other than leaning about BGP scope and recursive routes – actually help more since it's the "failed" route detection that's actual hard today. Similar with the new "netwatch", it be nice if that feed more directly in some generic meaning of "routing rules" – than leave it at "On Up"/"On Down" script (that aren't easy to write well). With new "netwatch" features, it be nice that could replace routing's "check-gateway" (without scripting).

Edit 1
I guess the one generic "routing rule" I lost from V6 is the "dynamic-in" – that was, while odd place, great way set the "default-route-distance" in /ip/dhcp-client etc. In V7, and especially with recursive routes, it now always involves a script. While I like your scripting a lot, I also know one bug/change/etc could break some script and the dhcp-client on is especially important. That about my only complaint actually on this topic.

As @anav already said I use route rules for policy based routing for subnets or individual devices through different routing tablea as I find them much cleaner than mangling and they allow me to continue to use fastrack.

I use them with a client who has multiple ISP connections, one of which is another hardware item supplying LTE. With them, a couple of services always need to go out LTE. Some other rules allow LAN to go out the default route correctly.

Example:

most the time i use route rules to do High speed Load Balancing (PBR) when, mangle method is not feasible because of high CPU usage, route rule allow to achieve PBR at the highest speeds

i use route rule for VPN, now mangle become fisrt priority all my setup before is mest up, mangle cant handle conflict dest address list route rule can, after ROS 7.2.1, my config become like cat and mouse sometime it works sometime not working, some aps like netflix and other streaming service sometimes wont work if using VPN like in thisviewtopic.php?p=938538#p938538, i dont have much hope with that but it really help if route rule can overide conflict address for me

I have a number of routers that have secondary Internet connections that I use as failover when the primary wireless link fails. The router tunnels through the secondary WAN connection back to an aggregation router, and OSPF handles the redirection of all traffic over the WG tunnel.

With a simple DHCP-Client script that updates the default gateway for the secondary provider's routing table, I now have a route rule that forces the router to use that gateway to get back to the VPN aggregator. Everything else comes up via OSPF over the tunnel.

Previously I was using VRF's and tables and it got to be quite complex.

I wish MT would add address lists as an entry for Routing Rules!!
I wish MT would add a failsafe option for Wireguard Client reconnecting after primary goes offline/changes IP
BUT MOST OF ALL
I wish MT would add Zerotrust cloudflare tunnel in an options package (for all devices).

Ehhh… Anavs ghost??

I wish MT would addaddress lists as an entryfor Routing Rules!!

Yeah that is a missing item in the /routing/rules – it certainly be nice to define the subnets used in one place & not have to update the routing rules as add'l step. Now if added, be nice if "print" showing generated "address list dynamic rules" for troubleshooting (e.g. an address-list may have LOT of various address, still like to see the "resolved" list of rules with IPs in /routing/rule/print)

[...]Wireguard[...]

ChatGPT's @anav hallucination goes off-topic...but fair point about WG and PBR I think...

I don't do anything complex with WG. But Linux's "wg-quick" uses "ip rule"... I'd take that as a clue using /routing/rule and /routing/table be better on Mikrotik too. And WG+PBR allow for a direct translation from Linux-based WG topologies, then indirectly converting to mangle/etc. Also, imagine PBR have generally lower CPU, than adding add'l firewall rules too, but dunno. So if I had heavy WG needs, I'd certainly try PBR first.

In my network we have a number of routers that are "shared" devices between different providers. In some cases different default gateways are required depending on source IP address. Routing Rules provide a very simple way to implement this without using Mangle / VRF or another much more complicated setup.