View source for Manual:Route Selection Algorithm in RouterOS

{{Deprecated}}
<br/>
== Who is who in route selection ==

There are more than one routing table in a running router.

* There is FIB, Forwarding Information Base, that makes packet forwarding decisions. In RouterOS case, FIB is inside Linux kernel.

* There is main routing table. This is where route selection decisions are made. For each destination there can be at least one route from each routing protocol, and one from static configuration, but only the route with the lowest distance will be installed in FIB. If there is more than one route with the same distance, selection is done in random (except for BGP routes). For non-BGP routes this can happen only if you are playing with filters. Scope attribute also determines which routes can be active.

* Each routing protocol (except BGP) has it's own internal tables. This is where per-protocol routing decisions are made. For example, in OSPF there are different types of routes: intra-area, inter-area, external-type-1, external-type-2. If all four type of routes to a single destination are present in OSPF internal LSA tables, only one of them -- intra-area route -- will make it to the common rotuing table.

* BGP has the most complicated selection process (described in [[BGP Best Path Selection Algorithm]]). Notice that this protocol-internal selection is done only after a BGP route is installed in main routing table; that means there can be one route for each BGP peer. Also note that BGP routes from different instances are compared by their distance.

== Route distance ==

Cisco documentation describes "administrative distance" as "This is the measure of trustworthiness of the source of the route. If a router learns about a destination from more than one routing protocol, administrative distance is compared and the preference is given to the routes with lower administrative distance. In other words, it is the believability of the source of the route."

Default distances in RouterOS are:

{| border="1" cellpadding="2" cellspacing="0" 
|-
! protocol
! distance
|- valign="top"
|
connected 
|
0
|- valign="top"
|
static   
|
1
|- valign="top"
|
eBGP 
|
20
|- valign="top"
|
OSPF 
|
110
|- valign="top"
|
RIP
|
120
|- valign="top"
|
MME
|
130
|- valign="top"
|
iBGP        
|
200
|}

== Load balancing and dynamic routing protocols ==

==== With multiple nexthops ====

Normally, there can be only one active route per destination. If you want to do load balancing, multiple nexthops per route is the solution.

{{Note | This will only provide per-connection, not per-packet load balancing!}}

Example: suppose that you have a router that has 10.0.0.0/24 and 10.0.1.0/24 upstream networks.

 [admin@II] > routing filter add chain=bgp-in prefix=0.0.0.0/0 set-in-nexthop=10.0.0.1,10.0.1.1
 # use this filter for a bgp peer 
 [admin@II] > routing bgp peer set peer1 in-filter=bgp-in
 # observe that it's really working
 [admin@II] > ip route print
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
 B - blackhole, U - unreachable, P - prohibit
  #      DST-ADDRESS        PREF-SRC        G GATEWAY         DISTANCE INTERFACE
  0 ADb  0.0.0.0/0                          r 10.0.0.1        1        ether1
                                            r 10.0.1.1                 ether2

What if you want to divide the traffic in uneven parts? Unlike in Linux (for example), you cannot set the weight for nexhtops.
But you can simulate different weights, using specific nexthop more than once. 

e.g. 
 [admin@II] > routing filter add chain=bgp-in prefix=0.0.0.0/0 set-in-nexthop=10.0.0.1,10.0.0.1,10.0.1.1

Now about 2/3 of traffic are routed to 10.0.0.1 and remaining 1/3 - to 10.0.1.1

{{Note | Another way to achieve load balancing is to use multiple recursive next-hop resolution, as described [[BGP_Load_Balancing_with_two_interfaces|here]].}}

==== With policy routing  ====

Another solution is to use policy routes. This way you can have more than one active route to a particular destination. Suppose you already have a static default route, and want to have another one from bgp.

Static route
 [admin@II] > /ip route p
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
 B - blackhole, U - unreachable, P - prohibit
  #      DST-ADDRESS        PREF-SRC        G GATEWAY         DISTANCE INTERFACE
  0 A S  0.0.0.0/0                          r 10.0.1.1        1        ether2

Add policy route rule and tell the filter to set it:
 [admin@II] > /ip route rule add table=aaa routing-mark=aaa
 [admin@II] > /routing filter add chain=bgp-in prefix=0.0.0.0/0 set-routing-mark=aaa

Now, when default route is received from BGP:

 [admin@II] > /ip route print detail
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
 B - blackhole, U - unreachable, P - prohibit
  0 ADb  dst-address=0.0.0.0/0 gateway=10.0.0.1 interface=ether1 gateway-state=reachable
         distance=200 scope=255 target-scope=30 routing-mark=aaa bgp-local-pref=100
         bgp-origin=incomplete received-from=10.0.0.133
  1 A S  dst-address=0.0.0.0/0 gateway=10.0.1.1 interface=ether2 gateway-state=reachable
         distance=1 scope=255 target-scope=10

Now mark the traffic to route appropiately.

[[Category: Routing|Route_Selection_Algorithm_in_RouterOS]]
[[Category: Manual|Route_Selection_Algorithm_in_RouterOS]]
[[Category: Case Studies|Route_Selection_Algorithm_in_RouterOS]]