Manual:Using scope and target-scope attributes

From MikroTik Wiki
Revision as of 15:19, 19 April 2013 by Janisk (talk | contribs) (→‎The problem: typo)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The problem

Not all routes that are in routing table are active. Main condition for route to be active is state of its nexthop. It should be resolvable. Inactive routes are not used for packet forwarding. Dynamic routing protocols will only redistribute active routes.

Route scope and target scope attributes can be used to change nexthop resolving. Normally nexthops can be resolved only through routes that are on link. On the other hand, routes in BGP updates frequently has nexthops from networks that are not directly connected. By default, these routes will be installed in routing table but will not be active: 

 [admin@A] > ip route pr detail
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf,
 B - blackhole, U - unreachable, P - prohibit
  0  Db  dst-address=3.0.0.0/8 gateway=192.65.184.3 interface=""
         gateway-state=unreachable distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,7018,701,703,80" bgp-local-pref=100 bgp-origin=igp
         received-from=10.0.0.128

  1  Db  dst-address=4.0.0.0/8 gateway=192.65.184.3 interface=""
         gateway-state=unreachable distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,3356" bgp-local-pref=100 bgp-atomic-aggregate=yes
         bgp-origin=igp received-from=10.0.0.128

  2  Db  dst-address=4.21.104.0/24 gateway=192.65.184.3 interface=""
         gateway-state=unreachable distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,7018,26207,26207,26207,26207" bgp-local-pref=100
         bgp-origin=igp received-from=10.0.0.128

  3  Db  dst-address=4.21.112.0/23 gateway=192.65.184.3 interface=""
         gateway-state=unreachable distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,7018,26207,26207,26207,26207" bgp-local-pref=100
         bgp-origin=igp received-from=10.0.0.128

Solution using scope attribute

One way to make all routes active is to allow to resolve nexthops through default route. To do that, you can make use of recursive nexthop resolving. Add default route with scope < target-scope of BGP routes: 

 [admin@A] > ip route add gateway=10.0.0.1 scope=10
 [admin@A] > ip route pr detail
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf,
 B - blackhole, U - unreachable, P - prohibit
  0 A S  dst-address=0.0.0.0/0 gateway=10.0.0.1 interface=ether1
         gateway-state=reachable distance=1 scope=10 target-scope=10

  1 ADb  dst-address=3.0.0.0/8 gateway=192.65.184.3 interface=ether1
         gateway-state=recursive distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,7018,701,703,80" bgp-local-pref=100 bgp-origin=igp
         received-from=10.0.0.128

  2 ADb  dst-address=4.0.0.0/8 gateway=192.65.184.3 interface=ether1
         gateway-state=recursive distance=20 scope=255 target-scope=30
         bgp-as-path="513,8220,3356" bgp-local-pref=100 bgp-atomic-aggregate=yes
         bgp-origin=igp received-from=10.0.0.128

Solution using target-scope attribute

When there is need to change target-scope? Possible problems with previously described approach are that all routes in the table always will be active. This may be not what you want.

An example: router with two interfaces, ethernet and wireless. All BGP routes are resolved through ethernet; wireless interface has some additional static routes. You want these static routes to be active only when wireless interface is in running state. Normally this is the case. However, when there is a default route with low enough scope, all routes will be switched to ethernet interface after wireless interface loses it's running bit.

One possible solution is to leave the scope of default route intact and modify the target-scope of BGP routes. 

 [admin@A] > ip route set 0 scope=255     
 [admin@A] > routing filter add chain=bgp-in set-target-scope=255
 [admin@A] > routing bgp peer set peer1 in-filter=bgp-in
 [admin@A] > ip route pr detail
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf,
 B - blackhole, U - unreachable, P - prohibit
  0 A S  dst-address=0.0.0.0/0 gateway=10.0.0.1 interface=ether1
         gateway-state=reachable distance=1 scope=255 target-scope=10

  1 ADb  dst-address=3.0.0.0/8 gateway=192.65.184.3 interface=ether1
         gateway-state=recursive distance=200 scope=255 target-scope=255
         bgp-as-path="513,8220,7018,701,703,80" bgp-local-pref=100 bgp-origin=igp
         received-from=10.0.0.128

  2 ADb  dst-address=4.0.0.0/8 gateway=192.65.184.3 interface=ether1
         gateway-state=recursive distance=200 scope=255 target-scope=255
         bgp-as-path="513,8220,3356" bgp-local-pref=100 bgp-atomic-aggregate=yes
         bgp-origin=igp received-from=10.0.0.128

How not to use them

Possibility to set both scope and target scope of nexthops is a powerful feature and as such can be easily abused. It is possible to create nexthop resolving loops. If there will be a logical loop in the routing table, RouterOS will not freeze, it will simply stop nexthop resolving at some point.

Simple loop example (three routes, each one wanting to resolve through another): 

[admin@A] > /ip route add dst-address=1.1.1.0/24 gateway=2.2.2.2 scope=10 target-scope=10
[admin@A] > /ip route add dst-address=2.2.2.0/24 gateway=3.3.3.3 scope=10 target-scope=10
[admin@A] > /ip route add dst-address=3.3.3.0/24 gateway=1.1.1.1 scope=10 target-scope=10
[admin@A] > /ip route pr
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf,
B - blackhole, U - unreachable, P - prohibit
  #      DST-ADDRESS        PREF-SRC        G GATEWAY         DISTANCE INTERFACE
 0   S  1.1.1.0/24                           2.2.2.2         1
 1   S  2.2.2.0/24                           3.3.3.3         1
 2   S  3.3.3.0/24                           1.1.1.1         1
 3 ADC  10.0.0.0/24        10.0.0.133                        0        ether1

Change the gateway of any of the first three routes to 10.0.0.x and they all will become active.

More complex loop example: 

 [admin@A] > ip route add dst-address=1.1.1.0/24 gateway=3.3.3.3 scope=10 target-scope=10
 [admin@A] > ip route add dst-address=1.1.1.0/24 gateway=10.0.0.1 scope=10 target-scope=10 distance=3
 [admin@A] > ip route add dst-address=3.3.3.0/24 gateway=1.1.1.1 scope=10 target-scope=10
 [admin@A] > ip route pr detail
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf,
 B - blackhole, U - unreachable, P - prohibit
  0   S  dst-address=1.1.1.0/24 gateway=3.3.3.3 interface=ether1
         gateway-state=recursive distance=1 scope=10 target-scope=10

  1 A S  dst-address=1.1.1.0/24 gateway=10.0.0.1 interface=ether1
         gateway-state=reachable distance=3 scope=10 target-scope=10

  2 A S  dst-address=3.3.3.0/24 gateway=1.1.1.1 interface=ether1
         gateway-state=recursive distance=1 scope=10 target-scope=10

  3 ADC  dst-address=10.0.0.0/24 pref-src=10.0.0.133 interface=ether1 distance=0
         scope=10 target-scope=0

Note that now the active route has larger (i.e. worse) distance.

Interface routes, unreachable routes and nexhops

Nexthops cannot be resolved through interface routes (i.e. routes that have interface index instead of gateway address as nexthop). Nexthops also cannot be resolved through unreachable routes (with type B, U, or P) even when they are active. They also do not have nexthops themselves.

Retrieved from "https://wiki.mikrotik.com/index.php?title=Manual:Using_scope_and_target-scope_attributes&oldid=25244"