Community discussions

MikroTik App
 
User avatar
mrz
MikroTik Support
MikroTik Support
Topic Author
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Routing rule use cases

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
just joined
Posts: 11
Joined: Sat Nov 20, 2021 8:32 am
Location: Kenya

Re: Routing rule use cases

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.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Topic Author
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Routing rule use cases

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
just joined
Posts: 11
Joined: Sat Nov 20, 2021 8:32 am
Location: Kenya

Re: Routing rule use cases

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19106
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Routing rule use cases

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.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Routing rule use cases

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.
Last edited by Amm0 on Wed Dec 28, 2022 7:40 pm, edited 1 time in total.
 
gabacho4
Member
Member
Posts: 330
Joined: Mon Dec 28, 2020 12:30 pm
Location: Earth

Re: Routing rule use cases

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.
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Routing rule use cases

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
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2990
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Routing rule use cases

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
 
User avatar
dioeyandika
just joined
Posts: 19
Joined: Fri Feb 08, 2019 11:30 am

Re: Routing rule use cases

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
 
User avatar
sirbryan
Member
Member
Posts: 303
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: Routing rule use cases

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
Member Candidate
Member Candidate
Posts: 285
Joined: Wed Feb 16, 2022 2:04 pm

Re: Routing rule use cases

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).
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1041
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: Routing rule use cases

Fri Mar 31, 2023 8:27 pm

Ehhh… Anavs ghost?? 👀😄
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Routing rule use cases

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.
 
User avatar
savagedavid
Trainer
Trainer
Posts: 320
Joined: Thu Aug 25, 2005 12:58 pm
Location: Cape Town, South Africa
Contact:

Re: Routing rule use cases

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
just joined
Posts: 5
Joined: Wed Nov 21, 2018 5:06 pm

Re: Routing rule use cases

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
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: Routing rule use cases

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.

Who is online

Users browsing this forum: No registered users and 15 guests