Manual:Route Selection Algorithm in RouterOS: Difference between revisions
No edit summary |
mNo edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 122: | Line 122: | ||
Now mark the traffic to route appropiately. | Now mark the traffic to route appropiately. | ||
[[Category: Routing]] | [[Category: Routing|Route_Selection_Algorithm_in_RouterOS]] | ||
[[Category: Manual]] | [[Category: Manual|Route_Selection_Algorithm_in_RouterOS]] | ||
[[Category: Case Studies]] | [[Category: Case Studies|Route_Selection_Algorithm_in_RouterOS]] |
Latest revision as of 12:17, 14 April 2010
The information in this article may be deprecated, and is described better elsewhere in the Wiki.
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:
protocol | distance |
---|---|
connected |
0 |
static |
1 |
eBGP |
20 |
OSPF |
110 |
RIP |
120 |
MME |
130 |
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 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.