Realms and Information Bases

   

Realms and Information Bases

To start with you need to consider how an actual routing engine works. Up to this point you only considered the Routing Policy Database (RPDB) as containing the state of the routing, more particularly the Policy Routing, structure. But this structure has several components .

Recalling the discussion of the RPDB from Chapter 3, "Linux Policy Routing Structures," the concept of the actual Routing Information Base (RIB) describes what you would call a routing structure. This RIB consists of all the elements necessary to describe how to propagate a packet based on the destination address. It contains many items of information including such details as the interface, MTU, nexthop router, TOS tag, and other information that may be needed to forward the packet. In most routers this is the complete routing table itself.

When you begin to think in terms of Policy Routing structures, especially when you consider the independent uses of the various Triad members , you can see that this single amorphous RIB itself is too large and unwieldy to use as a single entity. Considering that the core concept of routing is to send packets to the appropriate destination, most of the mass of information becomes extraneous and irrelevant. Except when you need to actually make decisions based on those additional items of information. So what if you were to consider splitting the RIB into a database of information and a simple routing mechanism?

Now you are looking at the fundamental change implemented in the RPDB: the concept of the RIB as a split entity where you have the information database and the Forwarding Information Base (FIB). The information contained in the information base can be used to influence and select from the paths coded into the FIB. Think again of the use of the u32 classifier from Chapter 6, "Complex Network Examples." You can use any binary information (information base) to determine what TOS tag to set. The TOS tag then selects the route to use (FIB).

It is this divorce of the information from the forwarding that gives Policy Routing power and flexibility. In either extreme, from using all of the information to traditional destination-only routing, the selection mechanism based on the information database is independent of the forwarding mechanism in the FIB. And by establishing that functionality throughout the spectrum between those extremes, Policy Routing can provide all of the uses both in today's Internet and in tomorrow's.

Splitting up these functions makes sense when you consider the complexity driven by routing structures in use. But when you need to think about a complex routing structure, the sheer enormity of the routes that may be present can quickly overwhelm you. Step back and consider what it is that you really want to know.

Within any given complex routing environment there are typically several groupings to consider. These are "meta-routes" that describe larger scale destination groups. The wording used in the ip utility is realm. A realm is best considered as defining a set of routes as selected by human logic. You are not selecting these routes for any network protocol level logic structure, but in order to classify them for your own understanding.

The best way to visualize this is to consider a simple example (see Figure 7.1). Suppose you have a router that has four interfaces. One is the primary connection from the Internet, one is the connection from the Internet2 project, one is to your corporate WAN, and the last one is to the local government. You know that your corporate WAN spans three continents when you factor in the vendors and customers who are also connected. The local government is interconnected with all the other local governments throughout your state, which includes some 750 individual government entities. Your boss just came down and asked how much actual bandwidth is being used from local governments to Internet2. What is your answer?

Figure 7.1. Tracking the traffic.

graphics/07fig01.gif

You know that you have OSPF running on the corporate WAN with your router providing the connection to your defined stub area within the corporate OSPF scheme. The link to the local government defines a different OSPF stub area within the state's OSPF routing scheme. You also have independent Border Gateway Protocol (BGP) peerages running on each Internet connection. All of these instances dump into different routing tables and then you have a whole set of rules for implementing your Policy Routing. But you know you can define a realm whose source scope is the local government OSPF area and whose destination scope is the Internet2 BGP peer. Then you simply can issue a command to look at the traffic amounts for that realm.

With this example in mind you should consider what Alexey Kuznetsov has to say about the implementation of realms in the IPROUTE2 utility suite. Remember that the IPROUTE2 suite includes both the ip utility and the tc utility.

rtacct ”Route Realms and Policy Propagation

On routers using OSPF ASE (Autonomous System External) or especially the BGP protocol, the routing tables may be huge. If you want to classify or account for the packets per route, you will have to keep lots of information. Even worse , if you want to distinguish the packets not only by their destinations but also by their sources, the task presents a quadratic complexity, and its solution is physically impossible .

One approach for propagating the policy from routing protocols to the forwarding engine has been proposed. Essentially, Cisco Policy Propagation via BGP is based on the fact that dedicated routers have the entire RIB (Routing Information Base) close to the forwarding engine so that Policy Routing rules can check all the route attributes, including ASPATH (Autonomous System PATH ) information and community strings.

Within the Linux architecture, where we have a split RIB as maintained by a user -level daemon and the kernel-based FIB (Forwarding Information Base), we cannot allow such a simplistic approach.

Fortunately, there exists another solution that allows an even more flexible policy with rich semantics. Routes can be clustered together in user space based on their attributes. For instance, a BGP router knows the route ASPATH or its community, whereas an OSPF router knows the route tag or its area. A network administrator adding routes manually knows the nature of those routes. Providing that the number of such aggregates, which we call realms, is low, the task of full classification both by source and destination becomes quite manageable.

So each route may be assigned to a realm. It is assumed that this identification is made by a routing daemon, but static routes may also be assigned manually through ip route .

Currently there exists a patch to gated , allowing it to classify routes to realms over all the set of policy rules. See the later section, " gated and Zebra," for more information. This classification is implemented within gated by prefix, ASPATH, origin, tag, and so on.

To facilitate this construction in the case when the routing daemon is not aware of realms, missing realms may be completed with routing policy rules.

For each packet, the kernel calculates the tuple of realms (source realm and destination realm) using the following algorithm:

  1. If a route has a realm, the destination realm of the packet is set to it.

  2. If a rule has a source realm, the source realm of the packet is set to it.

  3. If the destination realm was not obtained from route, and the rule has a destination realm, set the destination realm from rule.

  4. If at least one of the realms is still unknown, the kernel finds a reversed route to the source of the packet.

  5. If the source realm is still unknown, get it from a reversed route.

  6. If one of the realms is still unknown, swap realms of reversed routes and apply step 2 again.

After this procedure is completed, we know what realm the packet arrived from and the realm where it is going. If any of the realms is unknown, it is initialized to zero (or realm unknown ).

The main application of realms is in conjunction with the tc route classifier, where they are used to help assign packets to traffic classes for accounting, policing, and scheduling them according to the classification.

A much simpler but still very useful application is packet path accounting by realms. The kernel gathers a packet statistics summary that can be viewed with the rtacct utility.

 
 kuznet@amber~ $  rtacct russia  Realm      BytesTo    PktsTo     BytesFrom  PktsFrom russia     20576778   169176     47080168   153805 
 

This output shows that this router has received 153,805 packets from realm russia and forwarded 169,176 packets to russia . The realm russia consists of routes with ASPATHs not leaving russia .

Note that locally originated packets are not accounted here, since rtacct shows ingoing packets only. Using the route classifier, you can get even more detailed accounting information about outgoing packets, optionally summarizing traffic not only by source or destination but by any pair of source and destination realms.

The important point is that the classification of the routes into bundles can be done by any of the associated metadata for the route. This metadata can be the area for OSPF, the community for BGP, or simply the source address from a rule. This classification into realms follows the logic of the administrator who set up the router. As you saw in the preceding example of accounting, the realm russia is defined by the administrator as the set of all routes whose ASPATH membership does not leave russia .


   
Top


Policy Routing Using Linux
Policy Routing Using Linux
ISBN: B000C4SRVI
EAN: N/A
Year: 2000
Pages: 105

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net