Rules and Dynamic Structure
Rules and Dynamic Structure
All of the testing you have performed to this point has shown you how to implement dynamic routing using either gated or the Zebra suite. But you do not know how these dynamic routing suites can interoperate with Policy Routing. You note that to this point all of the routes from either gated or Zebra have been installed into routing table main .
What if you could specify which table to use for the routes? Then you could use the rules to set up special implementations of dynamic routing interfaces. You could run many different versions of dynamic protocols on the same system and have different versions of the routes connecting through your network.
gated and Multiple Routing Tables
This is where Alexey's patch to gated provides needed extensions. In addition to providing for the provisioning of realms, it also adds a command-line switch that tells gated what routing table to use. As you recall, gated is monolithic and runs with all interactions providing data to a single routing structure. This command-line switch is simply -T{ #} , where you would replace { #} with the number of the routing table to use.
[root@paksecured /root]# ip ro li tab 128 [root@paksecured /root]# [root@paksecured /root]# /usr/local/sbin/gated -T128 [root@paksecured /root]# ip ro li tab 128 127.0.0.1 dev lo proto gated/conn scope host 192.168.1.0/24 dev eth0 proto gated/conn scope link src 192.168.1.1 128.1.1.0/24 via 192.168.1.2 dev eth0 proto gated/ospf 128.1.2.0/24 via 192.168.1.4 dev eth0 proto gated/ospfase [root@paksecured /root]#
As you can see, this has placed all of the gated routes into the routing table 128. If you want you can use this fact to assign realms to these routes based solely on the routing table:
[root@paksecured /root]#ip ru add pref 32000 table 128 realms 2/3
Now you have assigned a source realm of 2 and a destination realm of 3 to all routes in table 128. Then all of the standard commands listing realms apply.
Zebra and Multiple Routing Tables
As of the release of Zebra considered herein, 0.89a, only one official usage of assigning a routing table is allowed. This is within the zebra daemon itself and refers specifically only to static routes. You can specify in the configuration file that you want all static routes to be placed within a single table.
Suppose you wanted all of your static routes to be placed into table 129. You would configure the zebra.conf file with the following:
! Static default routes. ! Select table 129 for static routes table 129 ip route 0.0.0.0/0 192.168.3.254 !
This would place all the following static routes into table 129. But those are the only routes that would be placed into that table.
Based on several private conversations I have had with other people active on the Zebra mailing list, this type of functionality is being actively considered for both the OSPF and RIP daemons in both IPv4 and IPv6. Recent indications are that this type of command will be available through patches for all of the various daemons.
For example, as of 10/10/2000 an unofficial patch to the bgpd daemon exists that allows bgpd to use a specific route table. This specification is coded as part of an extension to the route-map command. The route-map command allows you to specify filters to be applied to the BGP protocol inputs and outputs. Using this patch you can specify specific ASPATH IDs for matching and assign them to a specific route table. This is a very powerful feature especially when you consider larger multi-connected peerings. Simply being able to separate out the AS by table is a very powerful tool when considering applying Policy Routing structures within such an environment.
gated & zebra & rules = FUN
As it stands now one of the tricks of the trade is to run gated with OSPF only or maybe RIP and OSPF and send it to a single table, such as table 128. Then run zebra to handle the static routes to a table, say 129. Finally, run the bgpd from zebra and tell it to send its information to table 130 and higher.
From there you can assign realms for tracking and use rules to determine which traffic gets routed through which set of connections. Think about modifying the Bounce Table Walking and Tag Routing examples from Chapter 6 using this new set of tables. The possibilities are limitless.
In all of this you must remember that dynamic routing is simply a means to distribute a complex routing table between systems. You need to realize that a dynamic routing protocol, such as OSPF or even BGP, effectively provides a distribution mechanism for a single routing table. Most routers today only possess a single FIB, which is derived from all of the routes presented by the various dynamic protocols. This makes mixing and matching dynamic routing protocols not very flexible because you end up discarding duplicate routes according to a predetermined formula. So you have the concept of weighting which selects the "best" route from the routes presented by the various protocols. By contrast, in the RPDB the FIB actually can be thought of as existing per routing table. You can conceive of each routing table as defining an independent FIB. And the rules then select the FIB to use for the packet. Thus none of the routes are ever filtered out except by direct specification, and all routes from all protocols are available for use.
Policy Routing's multiple routing tables enable multiple dynamic routing protocols to be treated just as you treat multiple IP addresses. You can have a different dynamic routing protocol running for different networks on the same physical connection. The ability of each protocol to have its own routing table allows you as the policy administrator to govern and control the structure of the network without having to hassle with which protocol is weightier than the other. This provides you with the best of both worlds .
| Top |
