Routing rule use cases

mrz · Wed Dec 28, 2022 2:13 pm

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

B20016 · Wed Dec 28, 2022 4:31 pm

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.

mrz · Wed Dec 28, 2022 4:40 pm

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.

B20016 · Wed Dec 28, 2022 4:53 pm

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.

anav · Wed Dec 28, 2022 5:05 pm

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.

Amm0 · Wed Dec 28, 2022 7:28 pm

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.

So the "routing rule use case" is so "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 rules only 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!":

/routing rule {
    add action=lookup disabled=$norules dst-address=10.0.0.0/8 table=main
    add action=lookup disabled=$norules dst-address=172.16.0.0/12 table=main
    add action=lookup disabled=$norules dst-address=192.168.0.0/16 table=main
}

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.

gabacho4 · Wed Dec 28, 2022 7:39 pm

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.

pcunite · Thu Dec 29, 2022 1:30 am

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:

/ip route rule

#"LAN Destinations that should only use main (active) routing table. ISP1 when not in failover state."
add action=lookup-only-in-table dst-address=10.1.1.0/24 table=main
add action=lookup-only-in-table dst-address=10.2.2.0/24 table=main

#"PBX Server and VideoStreamer force out ISP2. Change action to "lookup" if there is a desire to failover to ISP1 if ISP2 is down"
add action=lookup src-address=10.2.2.20/32 table=ISP2_Route
add action=lookup src-address=10.1.1.50/32 table=ISP2_Route

Thu Dec 29, 2022 1:38 am

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

dioeyandika · Thu Dec 29, 2022 2:28 am

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 this viewtopic.php?p=938538#p938538 , i dont have much hope with that but it really help if route rule can overide conflict address for me

sirbryan · Thu Dec 29, 2022 2:30 am

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.

404Network · Fri Mar 31, 2023 7:45 pm

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).

Larsa · Fri Mar 31, 2023 8:27 pm

Ehhh… Anavs ghost??

Amm0 · Fri Mar 31, 2023 9:44 pm

I wish MT would add address lists as an entry for 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.

savagedavid · Mon Apr 17, 2023 8:26 am

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.

hyxion14 · Tue Jan 23, 2024 7:21 pm

Hello,

I have always used Mangle to mark traffic to different routes, but I don't know without the routing rules it is better, worse or a different way to do it.

This is an example of marking traffic and then routing it:

/ip firewall mangle
add action=accept chain=prerouting comment="NO BALANCEAR TRAFICO PRIVADO" dst-address-list=RFC1918 src-address-list=RFC1918
add action=accept chain=prerouting comment="INICIO PCC A ROUTER FTTH" dst-address=172.18.1.0/24 in-interface-list=LAN
add action=accept chain=prerouting dst-address=172.18.2.0/24 in-interface-list=LAN
add action=accept chain=prerouting dst-address=172.18.3.0/24 in-interface-list=LAN
add action=accept chain=prerouting dst-address=172.18.4.0/24 in-interface-list=LAN
add action=accept chain=prerouting dst-address=172.18.5.0/24 in-interface-list=LAN
add action=accept chain=prerouting dst-address=172.18.6.0/24 in-interface-list=LAN
add action=accept chain=prerouting comment="INICIO PCC A ENLACE ROTA" dst-address=195.53.96.0/23 in-interface-list=LAN
add action=mark-connection chain=input comment="MARCADO DE CONEXIONES ORIGINADAS EN INTERNET" connection-mark=no-mark in-interface=pppoe-out_FTTH_01 new-connection-mark=hacia-FTTH_01-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=pppoe-out_FTTH_02 new-connection-mark=hacia-FTTH_02-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=ether3-FTTH_03 new-connection-mark=hacia-FTTH_03-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=pppoe-out_FTTH_04 new-connection-mark=hacia-FTTH_04-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=pppoe-out_FTTH_05 new-connection-mark=hacia-FTTH_05-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=pppoe-out_FTTH_06 new-connection-mark=hacia-FTTH_06-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes in-interface=BR_NO-CGNAT new-connection-mark=hacia-ENLACE-ROTA-conn passthrough=yes
add action=mark-connection chain=input connection-mark=no-mark in-interface=BR_NO-CGNAT new-connection-mark=hacia-ENLACE-ROTA-conn passthrough=yes
add action=mark-routing chain=output comment="MARCADO DE TRAFICO DE RESPUESTA DEL ROUTER A INTERNET" connection-mark=hacia-FTTH_01-conn new-routing-mark=hacia-FTTH_01 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-FTTH_02-conn new-routing-mark=hacia-FTTH_02 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-FTTH_03-conn new-routing-mark=hacia-FTTH_03 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-FTTH_04-conn new-routing-mark=hacia-FTTH_04 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-FTTH_05-conn new-routing-mark=hacia-FTTH_05 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-FTTH_06-conn new-routing-mark=hacia-FTTH_06 passthrough=no
add action=mark-routing chain=output connection-mark=hacia-ENLACE-ROTA-conn new-routing-mark=hacia-ENLACE-ROTA passthrough=no
add action=mark-connection chain=prerouting comment="MARCAR CONEXIONES DESDE LA LAN PARA DISTRIBUIR BALANCEADO PROPORCIONAL" connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN \
    new-connection-mark=hacia-FTTH_01-conn passthrough=yes per-connection-classifier=both-addresses-and-ports:7/0
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-FTTH_02-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/1
add action=mark-connection chain=prerouting comment="MARCAR CONEXIONES DESDE LA LAN PARA DISTRIBUIR BALANCEADO PROPORCIONAL (directo)" connection-mark=no-mark dst-address-type=!local hotspot=auth in-interface-list="LAN_GUEST-01 (HS-FREE)" \
    new-connection-mark=hacia-FTTH_01-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-FTTH_03-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/2
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local hotspot=auth in-interface-list="LAN_GUEST-03 (PAY-B119)" new-connection-mark=hacia-FTTH_03-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local hotspot=auth in-interface-list="LAN_GUEST-02 (PAY-B114)" new-connection-mark=hacia-FTTH_02-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-FTTH_04-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/3
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface-list="LAN_GUEST-04 (GPON)" new-connection-mark=hacia-FTTH_04-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-FTTH_05-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/4
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface-list="LAN_GUEST-05 (LAN-B311 & MERAKI)" new-connection-mark=hacia-FTTH_05-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-FTTH_06-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/5
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface-list=LAN_GUEST-06 new-connection-mark=hacia-FTTH_06-conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address-type=!local hotspot=auth in-interface-list=LAN new-connection-mark=hacia-ENLACE-ROTA-conn passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:7/6
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface-list="LAN_GUEST-07 (ENLACE ROTA NO-CGNAT)" new-connection-mark=hacia-ENLACE-ROTA-conn passthrough=yes
add action=mark-routing chain=prerouting comment="MARCADO DE RUTAS A TODOS LOS PAQUETES QUE TENGAN MARCAS DE CONEXION EN LA LAN" connection-mark=hacia-FTTH_01-conn in-interface-list="LAN_GUEST-01 (HS-FREE)" new-routing-mark=hacia-FTTH_01 \
    passthrough=no
add action=mark-routing chain=prerouting connection-mark=hacia-FTTH_02-conn in-interface-list="LAN_GUEST-02 (PAY-B114)" new-routing-mark=hacia-FTTH_02 passthrough=no
add action=mark-routing chain=prerouting connection-mark=hacia-FTTH_03-conn in-interface-list="LAN_GUEST-03 (PAY-B119)" new-routing-mark=hacia-FTTH_03 passthrough=no
add action=mark-routing chain=prerouting connection-mark=hacia-FTTH_04-conn in-interface-list="LAN_GUEST-04 (GPON)" new-routing-mark=hacia-FTTH_04 passthrough=no
add action=mark-routing chain=prerouting connection-mark=hacia-FTTH_05-conn in-interface-list="LAN_GUEST-05 (LAN-B311 & MERAKI)" new-routing-mark=hacia-FTTH_05 passthrough=no
add action=mark-routing chain=prerouting connection-mark=hacia-FTTH_06-conn in-interface-list=LAN_GUEST-06 new-routing-mark=hacia-FTTH_06 passthrough=no psd=21,3s,3,1
add action=mark-routing chain=prerouting connection-mark=hacia-ENLACE-ROTA-conn in-interface-list="LAN_GUEST-07 (ENLACE ROTA NO-CGNAT)" new-routing-mark=hacia-ENLACE-ROTA passthrough=no

/ip route
add comment="RUTA PRINCIPAL MARCAS FTTH_01" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_01 pref-src="" routing-table=hacia-FTTH_01 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PRINCIPAL MARCAS FTTH_02" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_02 pref-src="" routing-table=hacia-FTTH_02 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PRINCIPAL MARCAS FTTH_03" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=172.18.3.1 pref-src="" routing-table=hacia-FTTH_03 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PRINCIPAL MARCAS FTTH_04" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_04 pref-src="" routing-table=hacia-FTTH_04 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PRINCIPAL MARCAS FTTH_05" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_05 pref-src="" routing-table=hacia-FTTH_05 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PRINCIPAL MARCAS FTTH_06" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_06 pref-src="" routing-table=hacia-FTTH_06 scope=30 suppress-hw-offload=no target-scope=10
add comment="RUTA PPAL PARA MIKROTIK - MAIN" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out_FTTH_06 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10

Would it have been easier to use routing rules?

Thanks

Amm0 · Tue Jan 23, 2024 7:54 pm

I have always used Mangle to mark traffic to different routes, but I don't know without the routing rules it is better, worse or a different way to do it.

@mrz kinda starts with that assumption. I've never know if it was "better or worse" – I use them more for explainability to someone who knows networking but not RouterOS ("go to the firewall to change routing" vs goto /routing/rules) since concept exist in linux/macOS.

I guess I've assumed that since standard linux has rules/route tables, they're more "primitive" in networking stack than conntrack. But dunno. Good question.

volkirik · Thu Jul 25, 2024 2:25 pm

set min-prefix=129 for ipv6, 33 for ipv4 rules,
if you are going to use Routing->Rules, to disable suppress feature.

It is a known bug, by default, it suppress default route (/0 and ::/0)

anav · Sat Jul 27, 2024 3:45 pm

set min-prefix=4294967295 if you are going to use Routing->Rules, to disable suppress feature.

It is a known bug, by default, it suppress default route (/0 and ::/0)

Can you explain this more fully please.

1. What bug are you talking about ( has it been reported)>?
2. What is the purpose of setting min-prefix=4294967295

The reason I ask is that typically when forcing a subnet out wireguard one has to be careful if there is still local traffic required.
Example subnetA going out wireguard, subnetB not going out wireguard but subnets A and B still need to talk to each other.
The conventional approach

/routing rules
add dst-address=subnetA action=lookup-only-in-table table=main
add dst-address=subnetB action=lookup-only-in-table table=main
add src-address=subnetA action=lookup table=use-Wireguard

Note1: if your local subnets were close together in nomenclature one could use a single subnet to span both local subnets saving a rule etc....

Now recently a wise person figured out that instead of the preamble to define local subnets first that may need to chat before going out wireguard one could use min-prefix

/routing rules
add min-prefix=0 action=lookup-only-in-table table=main
add src-address=subnetA action=lookup table=use-Wireguard

Sadly, I do not know exactly what this means or does, but it does seem to allow local subnets to talk prior to being forced out a tunnel.
Thus curious as to your different min-prefix discussion!!

anav · Sat Jul 27, 2024 3:47 pm

@hyxion. What is the purpose of this ALL encompassing rule???
/ip firewall mangle
add action=accept chain=prerouting comment="NO BALANCEAR TRAFICO PRIVADO" dst-address-list=RFC1918 src-address-list=RFC1918

If by that you mean to allow connected networks to communicate on the router, then you should define those connected networks and then apply them in specific rules.
Not a fan of wide ranging rules like that.

++++++++++++++++++++++++

Your scenario is very complex and mangling probably makes the most sense!
The approach is simple, in this typical order..........
a. ensure required traffic passes first ( accept ) aka traffic that needs to avoid mangling
b. mangle traffic headed to the router ( router services )
c. mangle traffic to LAN servers
d. mangle traffic for PCC

Remember that mangling overrides routing rules in ver7, so routing rules if used have to be with the understanding that any conflicts with mangling will not work.
Thus one needs to be as precise as possible within mangling, first because its a good habit and b. it allows other rules to exist more easily such as routing rules.
Example if mangling for port forwarding to servers. Identify the servers in a LIST vice use the lazy dst-address=subnet.

Routing rule use cases

Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases

Re: Routing rule use cases