On routers using OSPF ASE or, especially, the BGP protocol, routing tables may be huge. If we want to classify or to account for the packets per route, we will have to keep lots of information. Even worse, if we want to distinguish the packets not only by their destination, but also by their source, the task gets quadratic complexity and its solution is physically impossible.
One approach to propagating the policy from routing protocols to the forwarding engine has been proposed in . Essentially, Cisco Policy Propagation via BGP is based on the fact that dedicated routers all have the RIB (Routing Information Base) close to the forwarding engine, so policy routing rules can check all the route attributes, including ASPATH information and community strings.
The Linux architecture, splitting the RIB (maintained by a user level daemon) and the kernel based FIB (Forwarding Information Base), does not allow such a simple approach.
It is to our fortune because there is another solution which allows even more flexible policy and richer semantics.
Namely, routes can be clustered together in user space, based on their attributes. F.e. a BGP router knows route ASPATH, its community; an OSPF router knows the route tag or its area. The administrator, when adding routes manually, also knows their nature. Providing that the number of such aggregates (we call them 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
can also be handled manually with
ip route (see sec.7,
There is a patch to
gated, allowing classification of routes
to realms with all the set of policy rules implemented in
by prefix, by ASPATH, by origin, by tag etc.
To facilitate the construction (f.e. in case the routing daemon is not aware of realms), missing realms may be completed with routing policy rules, see sec. 8, p..
For each packet the kernel calculates a tuple of realms: source realm and destination realm, using the following algorithm:
After this procedure is completed we know what realm the packet
arrived from and the realm where it is going to propagate to.
If some of the realms are unknown, they are initialized to zero
The main application of realms is the TC
route classifier ,
where they are used to help assign packets to traffic classes,
to account, police and schedule them according to this
A much simpler but still very useful application is incoming packet
accounting by realms. The kernel gathers a packet statistics summary
which can be viewed with the
kuznet@amber:~ $ rtacct russia Realm BytesTo PktsTo BytesFrom PktsFrom russia 20576778 169176 47080168 153805 kuznet@amber:~ $This shows that this router received 153805 packets from the realm
russiaand forwarded 169176 packets to
russia. The realm
russiaconsists of routes with ASPATHs not leaving Russia.
Note that locally originating packets are not accounted here,
rtacct shows incoming packets only. Using the
classifier (see ) 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.