Manual:Using scope and target-scope attributes
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, RadioOS 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.