Guide to gated

Another program you have heard much about in earlier chapters is gated. There are actually three different versions of this program. You can utilize gated for either unicast or multicast use, for either IPv4 or IPv6, or any combination of these you require—just make sure you have the correct version (see Table 5.2) for each. This routing daemon comes with many versions of Linux, though it might be on a second disk or among supplementary materials. If this is the daemon you decide to use and don’t have it, want the latest version, or need a capability that didn’t come with the version packaged with your distribution, go to www.gated.org or www.gated.merit.edu to obtain them.

The public version is a slightly older but very stable version. The unicast, multicast, and IPv6 versions are all newer and available through the main site as well. Access to the public version’s source code is possible but not to the newer versions unless you obtain a license—if you require source code access, the zebra (http://www.zebra.org) daemon might be a better choice for you.

It is the public version we’ll focus on in this chapter.

How Public gated Works

Like most routing daemons, the gated routing daemon typically starts at boot time— you’ll want to be sure that it is set up to do so on the Linux box you use for your router. See the section “Running Public gated” for ideas on using the gdc program to interface with the daemon rather than directly starting it by hand.

When gated starts, it first determines how much space it needs in memory for its arrays and other data structures. After it knows how much room it needs, gated is assigned a virtual machine with a 32-bit address space in either RAM or on a hard drive (this is how Linux handles all processes). The daemon then reserves a section of its space to hold the information and then clears out anything already stored there—a process called initializing memory. After this, it reserves another section of its space for each of the threads it will use to keep track of its state and serve other functions. The gated daemon then creates the memory framework for the data structures, such as routing tables, to which it needs fast access.

After the entire framework is in place, gated reads the kernel’s routing tables into its own RAM—something it won’t do again unless specifically instructed or restarted. It then finds the interfaces on this specific machine and records both their addresses and whether they are currently up or down.

Now the individual threads—multithreading programs are made up of the various things a program must swap between doing—have to get initialized. The gated daemon first sets values for all of the global variables for each thread. It then reads its configuration file, /etc/gated.conf, into memory. Because gated is modular, it does not load the capability to run every single protocol it supports. Instead it looks in /etc/gated.conf for the protocols that have been enabled and sets up a framework to run each, including loading the appropriate modules of code.

When you configure gated’s behavior, one thing you do is set up rules for how it imports routes it learns from outside sources. At this point, these rules are loaded into memory. After this occurs, gated loads the rules for how you want it to handle exporting routes to other routers and protocols.

At this time all initializations are complete. The gated daemon enters what the programmers call the forever loop, which means it enters its actual running state—and it will stay there until you tell it to do otherwise. It first sets all of the timers required for different protocol behaviors. The daemon then looks to the sockets, which are files used to transfer information between programs, that gated is interested in and loads any pertinent data from them. If any resulting tasks have to be run, they are queued to start when it’s their turn.

Finally, gated runs the tasks that happen in the foreground and background. Foreground tasks are visible to the administrator and are items that only need to run once. They’re often requests from protocol modules to take care of something whenever CPU time is available. In contrast, background tasks are hidden away and may run constantly or at regular intervals.

Configuring Public gated

The gated configuration file is gated.conf. Statements within this file can stretch beyond one or more lines and so are terminated with a semicolon (;). There are also two different kinds of comments you’ll run into here. One is the standard hash (#), which comments out the entire line. The other is the C-like pair: /* to start the comment and */ to end it. Now, with the basics out of the way, let’s look at how this file is built.

One of the most important things to keep in mind is statement type order. There are a number of main statement types that must be used in the proper order and two additional ones that can be liberally scattered throughout as needed. The statement types and the items within these types are briefly defined in Table 5.3 for reference’s sake.

The options Statement

The typical gated.conf file starts with an options statement, which sets global values that apply to everything that follows.You do not have to have an options statement at all if you don’t see the need. These items do not have to be in any specific order within the overall statement.

A gated options statement is written in the following format:

options 
     setting1 
     ... 
     settingN 
; 

The interfaces Statement

After you set (or don’t set) your global options, it’s time to tell gated about the network interfaces available on this machine. Doing this involves a set of nested statements, the first of which is the interfaces statement. This item provides a framework for all of the rest of the interface configuration in the following manner:

interfaces {
     statement1
								settings 
     ; 
     ... 
     statementN
								settings 
     ; 
} 

There are three kinds of statements you have available to you within the interfaces statement: options, interface, and define. While there are no strict requirements on the order in which you utilize these three statements, it’s a good idea to stick with what we’ve listed here. The first is, once again, options. This is not the same as the global options but instead is a set of options local to all of the interfaces—which it seems would make them global interface options.You have two choices here, as shown in Table 5.5.

Next among the interfaces statements is one or more interface statements. Yes, this could get confusing. Make sure to double-check that you don’t get these two items turned around. You can configure multiple interfaces together in the same statement if you want or break them up if you need some to have different settings than others. The interface statement itself is in the format interface list, where list is a series of IP addresses belonging to each interface you want to configure with this specific collection of settings. The items you can configure within the interface statement are listed in Table 5.6.

Finally, there is the define statement within the interfaces statement. You need to include this item if you set strictinterfaces in the interfaces option statement earlier. For each interface that gated needs to utilize but that may not be up and running when the routing daemon starts, you’ll need to create a define statement that tells strictinterfaces that this interface may be added to routing tables. The define statement itself is used in the format define address, where address is the IP address for this interface. See Table 5.7 for a list of the options you have available within define.

So, since you are probably a bit confused about what a typical interfaces statement might look like, here’s a more fleshed out example:

interfaces {
     options 
        strictinterfaces 
     ; 
     interface 192.168.232.* 
          simplex 
     ; 
     interface 192.168.251.* 
          simplex 
          passive 
     ; 
     define 192.168.232.* 
           broadcast 192.168.232.255 
           netmask 255.255.255.0 
     ; 
     define 192.168.251.* 
           broadcast 192.168.251.255 
           netmask 255.255.255.127 
     ; 
} 

Notice that not all of the IP information is strictly in the form of an IP address. You have a few different formats you can use:

• all. The word all is the same as using just the wildcard ★.

• xxx.xxx.xxx.xxx. Full IP address.

• xxx.xxx.xxx.*, xxx.xxx.*, xxx.*. Partial IP addresses with a wildcard at the end.

• eth*. Wildcarded device name.

• eth0. Nonwildcarded device names.

While the gated documentation also discusses referring to “symbolic names” (host.domain.extension format), doing so can be problematic because that name may not always correspond to the same interface. Therefore, the practice is not recommended.

The Definition Statements

There are three definition statements available, all of which must be used before any of the statements defined later in this chapter—if you decide to make use of them. These statements are autonomoussystem, routerid, and martians. The first two of these statements are required only under certain conditions, and the last is never absolutely required. Table 5.8 outlines the purpose of each of these statements and how to use them.

If you decide to utilize the martians statement, you’ll need to understand how route filtering works in gated to get the most use out of it. However, because we’re talking specifically about martians, only the three filtering components that apply in this case will be covered.The simplest and least useful in this context is:

martians {
     all; 
} 

This keyword would quite literally filter out every single piece of network and host information it received for its routing tables. A more useful item is:

martians {
     network rules; 
} 

For the network portion, you specify the IP information for the network in question. The rules in this case are either the keyword exact, or the keyword refines. These two keywords govern how the network information is interpreted. An exact tells gated to interpret network information in the martians statement strictly by overall network, ignoring netmasks that are not on class boundaries and therefore ignoring subnets. Hosts also are ignored. However, if you use refines for rules, the mask and host information is utilized—though in this case the mask is implied as a class mask.

A more complex version of this format is as follows:

martians {
     network mask mask rules; 
} 

Here, the refines option for rules makes more sense. The mask item refers to the net-mask. An even more refined version is as follows:

martians {
     network masklen bit_mask rules; 
} 

You might remember discussions in Chapter 4, “IPv4 and IPv6 Addressing,” in the beginning of the section, “IPv6 Math,” where the bit mask was introduced. A Class A bit mask is /8, Class B is /16, and C is /24. From there, the bit masks get fancier for subnets and IPv6. It’s this value that goes in the bit mask slot.

A martians statement doesn’t have to be just one line. You can mix and match all of the network definitions you see here within the statement. There is also one more item you have access to: You can set particular addresses or ranges within a blocked out range as valid using the allow option at the end of any of these items. For example, the following ignores routing information from the entire class B 192.168.0.0 except specifically from the Class C subnet 192.168.10.0:

martians {
     192.168.0.0 exact; 
     192.168.10.0 mask 255.255.255.0 refines allow; 
} 

RIP Configuration

Each routing protocol must be individually configured in gated. Let’s start with the oldest and simplest one: RIP. Regardless of whether you want this router to be able to speak with RIP-1 or RIP-2 routers or not, start the RIP configuration section with the following:

rip status 

The status entry can be one of the following:

• no;. Do not handle RIP traffic.

• off;. Do not handle RIP traffic.

• on {. Handle RIP traffic.

• yes {. Handle RIP traffic.

It is not mandatory that you set any more information than this. You could have the following whether on or yes:

rip on; 

However, using the curly brace to build a statement gives you more control over how gated deals with RIP. The options for what you use within the rip statement are listed in Table 5.9.

As you can see, the RIP setup for gated can get quite complex. Two of the options defy quick explanation in the form of a table. These are the interface option (a different one than the interfaces interface option) and both kinds of tracing options discussed in this section.

Under the rip statement, the interface option takes the following form:

rip on {
     options 
     interface list
								settings 
     ; 
     options 
}; 

Building the list follows the same rules given in the interface coverage of the earlier section, “The interfaces Statement.” The options available for the rip version of interface are listed in Table 5.10. Remember that each of these items is relative to the network interface specified in the section. You can have multiple interface statements if you need various network connections to have different settings.

Another difficult statement to pin down is traceoptions. One reason for this awkwardness is that there are two sets of values available: one that applies gated-wide (see Table 5.11) and another that only applies to RIP traffic (see Table 5.12). There are also global tracing options available, but they have no meaning in a specific protocol statement such as rip.

Open Shortest Path First (OSPF) Configuration

One of the more popular internal unicast routing protocols is OSPF. As you might remember from Chapter 1, this protocol includes features such as designated routers and routing areas. Due to this level of complexity, OSPF involves even longer sets of code to configure. So let’s get started.

You begin the OSPF configuration statement with the following:

ospf status
							

The status entry for ospf has the same options as the rip statement had:

• no;. Do not handle OSPF traffic.

• off;. Do not handle OSPF traffic.

• on {. Handle OSPF traffic.

• yes {. Handle OSPF traffic.

Typically, the first substatement within ospf is defaults, so the beginning of the statement often looks like the following:

ospf on {
     defaults {

The items available within the defaults statement are listed in Table 5.13.

After you set the defaults, you can then move on to the main portion of the ospf statement after closing the defaults statement like so:

ospf on {
     defaults {
          option1; 
          … 
          optionN; 
     }; 

The main ospf options are listed in Table 5.14.

Another complex substatement within ospf is the backbone statement.You must set up your OSPF backbone if you have more than one area because it’s the backbone that carries inter-area communications. Following along with the earlier format examples, let’s add to it:

ospf on {
     defaults {
          option1; 
          … 
          optionN; 
     }; 
     statement1; 
     … 
     statementN; 
     backbone area value {
          option1; 
          … 
          optionN; 
     }; 
}; 

The value as mentioned in Table 5.14 is the area number you assigned to the area serving as your AS backbone.Within the backbone area statement there is a small collection of options you can set to define how this backbone interacts with the rest of the AS. These options are outlined in Table 5.15.

EGP Configuration

If you need to exchange routing information with networks outside your own, you’ll need to use one of the border routing protocols. One choice is EGP, as you learned in Chapter 3, “Introduction to Border Routing Protocols.” Fortunately gated can handle this job as well as internal routing. Just be sure to set this aspect up only on your external border router(s).

Given that we’ve covered the general opening for these protocol configuration statements twice now, we’ll just start the EGP setup statement with what you’d use if you intended to activate EGP:

egp on {

The statements available to you in the egp configuration section are outlined in Table 5.17. As usual, some of these are too complex to explore fully in a single table. Specifically, group and its neighbor substatement are just covered in a simplified manner in the table.

As noted in Table 5.17, the egp options available in gated are covered in Table 5.18.

The group statement has many possibilities.To define the EGP neighbors in an autonomous system, you start with something as simple as the following (you might have more than one because there is more than one way to send data in and out of your AS or you need these border routers to allow internal networks using different protocols to talk to one another):

group options {

There are two options available in the group statement itself:

• maxup number. Sets the number of EGP neighbors gated needs to connect to—especially useful if you don’t need this router to necessarily connect to all of your other EGP routers.

• peeras number. Tells gated the AS number it’s a part of.

Inside the curly braces is where the real work begins. Here you must set up a series of neighbor statements, each of which specifically defines one of the other EGP routers in your AS.You must have all of them defined here—which is handy if you’re using gated for all of your EGP routers because you can just copy this section for the other machines and make a couple of adjustments. So now the initial statement looks like:

group options {
     neighbor machine1
								option1 
          … 
          optionN 
     ; 
     … 
     neighbor machineN
								option1 
          … 
          optionN 
     ; 
}; 

The machine entry in a neighbor statement is pretty straightforward; it’s the IP address for the EGP router you’re telling gated about. Everything else in a neighbor statement is optional, depending on the level of detail you need to configure for each machine. Table 5.19 lists and defines the available options.

One thing to note is that you’re seeing layers upon layers of the same settings here. There are multiple places, for example, that you can set traceoptions. The most local version of this setting is the one that takes hold. If you’ve set traceoptions for a specific neighbor, then that’s the setting used even if the overall egp statement says differently.

BGP Configuration

Another potential border routing protocol is appropriately named the Border Gateway Protocol (BGP), which you should be familiar with from Chapter 3. If you would rather run a BGP border router than an EGP, gated can still do the job. You activate this capability by creating a bgp statement starting with:

bgp on {

The main substatements available in the bgp statement are listed in Table 5.20. You will notice that much of the meat in the setup is not this set of statements, but is instead in the child statements within substatements.

The most complicated statement within bgp is group type. Let’s piece this one together step by step.This statement starts as you might expect:

group type 

After this there are five different ways you can continue, depending on the nature of the machines you’re trying to connect:

• external peeras. Defines a group of BGP routers outside the autonomous system.

• igp peeras. Defines a group of routers within your autonomous system that are not border routers but that BGP needs to exchange information with.

• internal peeras. Defines a group of routers within your autonomous system that do not utilize an IP-based routing protocol.

• routing peeras. Defines a group of BGP routers within your autonomous system used with your internal routers to resolve address forwarding.

• test peeras. Defines a test BGP router that you can use to make sure information is propagating properly.

So, depending on which type of group you’re setting up at the moment, you begin with one of the following lines to start your statement:

group type external peeras 
group type igp peeras 
group type internal peeras 
group type routing peeras 
group type test peeras 

The word,“begin,” is used here because you’re not done with the initial line yet. No matter which of these you choose, the next item is the AS number to which this particular group belongs. So now you have:

group type gtype peeras as 

If you’re setting up an external, internal, or test group the first line is finished. For a routing or test group you have two new items to add.You start with:

group type gtype peeras as proto 

The name of the interior protocol this specific group uses to communicate goes after proto, with the options being rip, ospf, or isi—see the sidebar, “gated and the IS-IS Protocol,” for more information on this last option. Finally, if you’re setting up the group type routing statement, you can choose to give specific interface information, which first involves expanding the statement to:

group type routing peeras as proto prot interface 

After the interface term, include the IP information for specific internal interfaces that you want to have treated as though they are external.

At this point you need to start the group type substatement, which you do by adding a curly brace, so you might now have:

group type external peeras as 
{

There are actually only two clauses that go within the group type substatement: allow and peer. You must include both of these items to properly set up the bgp group type. The allow clause gets inserted into the substatement as follows:

group type blahblahblah 
{
     allow 
     {

Every option in the allow clause involves identifying hosts and networks belonging to this particular group type. We’ve covered the various ways of specifying machines for gated a number of times now so we’re just going to fill out the allow clause with one of each of the possible formats, giving us:

group type blahblahblah 
{
     allow 
     {
          192.168.15.0 
          192.168.15.0 mask 255.255.255.0 
          192.168.15.0 masklen 24 
          all 
          host 192.168.15.5 
     }; 

The next clause in the group type substatement is peer, which gets added like so:

group type blahblahblah 
{
     allow 
     {
          192.168.15.0 
          192.168.15.0 mask 255.255.255.0 
          192.168.15.0 masklen 24 
          all 
          host 192.168.15.5 
     }; 
     peer hostIP
								option1 
          … 
          optionN; 

The extensive list of options available within the peer clause are listed in Table 5.22. You’ll recognize a number of these from other sections of gated.conf.

Configuring SNMP Interaction

Let’s switch gears away from routing protocols and look at the Simple Network Management Protocol (SNMP). Administrators use this tool to aid in managing large computer networks.The gated daemon does not actually run the SNMP protocol, but it does allow your Linux (or other) routers to interface with SNMP if you are using it as part of your network management solution. See RFC 1157 for more about SNMP itself.

The configuration statement for SNMP interactions is actually quite short. It starts, predictably, with:

snmp on {

Within the parentheses, there are only three options available:

• debug;. If you are having troubles with the SNMP daemon on your Linux box, add this line to activate the debugging features.

• port value;. If you are running SNMP but have set it to use a port that is not the default port 167, use this statement to tell gated.

• traceoptions options. As usual, you use this statement to configure logging. You have access to all of the items available in Table 5.11, as well as those listed in Table 5.23.

Configuring Static Routing

While most Linux users know how to use the standard routing commands for their static routing on their individual machines, it’s a good idea to make sure and give the static information to gated as well. Doing this allows your network to be more efficient by sparing individual hosts from having to do as many lookups.

You start a static routing statement (there can be more than one in a gated.conf file) with:

static {

Notice that there is no on or off. Static routing by its very nature is always available. There isn’t a long list of options available within the static statement. Instead, there are a lot of variations of format you can use and a few options along with that. The substatement types available to you start with one of the following mostly familiar sequences:

• default gateway gateIP. Informs gated that one specific interface, whose IP address fills gateIP, is the default for sending data.

• host hostIP gateway gateIP. Informs gated that traffic for the host whose IP address fills hostIP should pass through the interface specified by gateIP.

• netIP mask netmask gateway gateIP. Informs gated that traffic for the network specified in netIP, which is narrowed down by the netmask contained in the netmask portion, should pass through the interface specified by gateIP.

• netIP masklen len gateway gateIP. Informs gated that traffic for the network specified in netIP, which is narrowed down by the mask length contained in the len portion, should pass through the interface specified by gateIP.

• netIP mask netmask interface interface. Informs gated that traffic for the network specified in netIP, which is narrowed down by the netmask contained in the netmask portion, goes to the interface specified by interface.

• netIP masklen len interface interface. Informs gated that traffic for the network specified in netIP, which is narrowed down by the mask length contained in the len portion, goes to the interface specified by interface.

• netIP interface interface. Informs gated that traffic for the network specified in netIP goes to the interface specified by interface.

• interface interface. Sets the default interface that gated should use for routing traffic.

The gateway statements are specifically for when you want to send data through a particular interface to get to particular destinations. On the other hand, if you have hosts or routers that are sharing a single interface but pretending they have different IP addresses, you need to use the interface statement.

After you have this initial portion set up, you fill in the rest of the substatement in the format:

specifier gateway gateIP options;
							

The options available here are listed in Table 5.24.

Configuring Route Importation

Your routers don’t just advertise your network’s information to the Internet or external networks. They also receive advertisements from the outside containing vital data for directing packets from place to place.This data is not just collected blindly into a routing table by gated. You have to set up the rules for how the importation of routes operates on each gated router.

The gated.conf file allows you to set up different rules for each protocol type. They’re covered here in the order they were covered in Chapters 1 and 3. That means the first item of interest is how you set up how RIP routes are imported.

You start the RIP import statement in the following format:

import proto rip 

From here, you might prevent routes from being imported from other routers using the following structures:

• restrict;. Do not install any RIP routes matching in the routing table.

• interface ilist restrict;. Do not install any RIP routes that match ilist in the routing table. To build ilist: use all if you want to match everything; the format xxx.xxx.xxx.xxx to match a full IP address; the formats xxx.xxx.xxx.*, xxx.xxx.*, or xxx.* to match partial IP addresses; eth* to use a wildcarded device name; or the full name of the device such as eth0.

• gateway glist restrict;. Do not install any RIP routes that match glist in the routing table. To build glist, use the same rules as discussed previously but apply them to the gateways that matching data packets would travel through rather than the interface from which they were first sent.

Alternatively, you might instruct gated to import routes in a similar fashion. Once again, it starts with:

import proto rip 

After this you have one of two options:

• interface ilist. Install RIP routes that match ilist in the routing table.

• gateway glist. Install any RIP routes that match glist in the routing table.

Subsequently, you might have one of these two lines so far:

import proto rip interface ilist 
import proto rip gateway glist
							

Next you have the choice of adding or not adding preference value, which is used to assign how preferred a route from RIP matching the given rules is compared to its alternatives. The default is 100. So now you might have one of the following four statements:

import proto rip interface ilist 
import proto rip gateway glist 
import proto rip interface ilist preference value 
import proto rip gateway glist preference value
							

No matter which of these you choose, you now add an opening curly brace () at the end of the line and drop down to the next line. This new line of code starts with one of the standard ways of specifying a host or network, which will be illustrated by repeating the example formats given earlier:

192.168.15.0 
192.168.15.0 mask 255.255.255.0 
192.168.15.0 masklen 24 
all 
host 192.168.15.5 

After starting the line with one of the above structures, you might end it with only a semicolon, or you might proceed with one of the following additions:

• restrict;. Do not import the routes that meet this rule.

• preference value;. Import the routes that meet this rule and assign them the specified preference value.

Finally, at the very bottom of the statement, add:

}; 

Build as many of these RIP rules as necessary. You can put multiple statements between the curly braces, as long as each of these is meant to match the same list of interfaces or gateways. If you want to set other rules for other interfaces or gateways, you need to build a whole new statement.

Now you need to tell gated how to handle incoming routing data from OSPF. The first thing to understand is that gated has no control over what routes it imports from OSPF within the area and autonomous system—also referred to as ASE. However, you can control the information imported from outside your AS. You start this statement with:

import proto ospfase 

After this, you might or might not want to add tag value afterwards. An OSPF tag consists of the originating router’s ID, plus a checksum value that helps to ensure that the packet’s contents have not been mangled during transmission. So, if you want to watch for routing updates from a specific router within another AS, add this item on the end of your ospfase statement.

If you want to use this rule to prevent any external AS OSPF routes from being imported, then just end this statement in restrict;, such as:

import proto ospfase restrict; 

However, if you want to use this rule to enable a specific collection of external AS OSPF routes to be imported, you need to continue the statement longer. First, if you don’t want the preference for OSPF routes learned from external autonomous systems to be 150, continue the statement by adding preference value. At this point, you start a clause with a curly brace:

import proto ospfase 
     options {

The first term(s) within the curly brace specify the networks and hosts that this rule applies to, using the same five formats shown in the example earlier. So, now you may have something such as:

import proto ospfase 
     options {
         192.168.15.* 

After you specify which networks, hosts, and so on this rule applies to, you can add either the word restrict to prevent these specific routes from being imported or preference value—where once again the default preference is 150. The final format looks similar to:

import proto ospfase 
     options {
         192.168.15.* preference 200; 
     }; 

Now we move on to telling gated how to handle routes advertised through EGP and BGP. As usual, there are a number of ways to accomplish this. You start either statement with the now familiar:

import proto 

If you’re configuring EGP route importation, you continue this with:

import proto egp autonomoussystem 

Next add the AS number for the autonomous system to which you want this rule to apply. After this, if you do not want to save routes learned from this AS through EGP in your routing tables, complete the phrase as follows:

import proto egp autonomoussystem value restrict; 

If you want to allow routing for items that match this rule, then you have a choice. You can either add the phrase preference value after the autonomoussystem value entry or stick with the default of a 200 preference for EGP. Then, expand the statement to the familiar format:

import proto egp autonomoussystem value 
preference value {

This statement ends in the usual manner. Inside the curly braces you define the networks, hosts, and so on to which you want the rule to apply and then end the statement with one of the following: the word restrict, the phrase preference value, or neither. In the end, you’ll have something similar to:

import proto egp autonomoussystem value 
preference value {
     all; 
}; 

You can use the same exact formats for BGP as you do for EGP; you just use bgp in place of egp. However, BGP contains some additional features. The other type of BGP configuration statement allows you to tell gated how to handle importation of a wider variety of routing protocol data into its routing tables. This statement type begins with the following:

import proto bgp aspath value 
     origin type
							

The value variable contains a regular expression that contains a list of autonomous systems to which this rule applies. In this case, we’re not looking for which AS the data comes directly from—though this information can be included here too. Instead, value contains AS numbers that the data may have passed through.

Choosing what to place in the type variable’s place is a bit more straightforward. The following settings are available:

• blank. You can choose to put nothing at all here.

• any. Sets that this rule applies to routes no matter from which protocol group they come.

• egp. This rule refers to External Gateway Protocols, or EGPs.

• igp. This rule refers to Internal Gateway Protocols, or IGPs.

• incomplete. This rule refers to routes where the given data is not complete.

You can actually have one or more of egp, igp, and incomplete if necessary.

On the next line, you’ll have the following to finish the rule if you want to prevent the defined routes from being imported:

restrict; 

There’s another format of this statement available that allows you not only to set protocol types, but also data about which routes the rule should apply. It starts with what we just covered:

import proto bgp aspath value 
     origin type
							

Now decide whether you want to use the default BGP preference of 170 or start the next line with:

preference value {

You need the curly brace even if you don’t set a preference. Proceed now to the next line and use the usual formats to set the list of routes you want to import. For each of these routes, start the line with the data that defines the address(es) to which you want the rule to apply, so you might start the next line with:

host 192.168.15.5 

Then, set whether you want to save this route to the routing tables by ending the line with one of the following:

host 192.168.15.5; 
host 192.168.15.5 preference value;
							

Or, tell gated that this item points to data that should not be saved to the routing tables with:

host 192.168.15.5 restrict; 

After you’ve entered all of the address lines for this rule, close it with:

}; 

Configuring Route Exports

If the rest of the Internet is to know how to reach you, gated or another border router has to export information to go into others’ routing tables. This doesn’t mean that you have to let everyone under the sun know about every single one of your machines. At the very least, though, the outside world must know how to reach your network gateway. Just as with the import statement, the export statement allows for specific rules to be applied to each routing protocol.

As usual, let’s start with RIP. There are two ways you can specify an RIP export statement that refers to how gated shares data with external RIP routers, but both start with:

export proto rip 

If you instead want to use this rule to set how gated exports routes learned from RIP, then change the first line to:

proto rip 

The second line is also identical regardless of which type of RIP export statement you’re building. If you want to specify a collection of addresses that this rule applies to, you have a choice of two different items you can place on this line:

interface ilist 
gateway glist
							

You actually don’t have to put anything here at all. If you don’t require the second line items just covered, then ignore them and treat the second line as though it’s the third. To set this rule so that it tells gated not to export data that matches, end the statement with:

restrict; 

Otherwise, if you want this rule to set what data can be exported through RIP, decide if you want to assign an RIP cost for the data hop from this border router to its neighbor. If you do, make the next line:

metric value {

If you don’t want to apply a cost, leave the metric value out and just use the curly brace. On the next line and as many after as necessary, use the structure:

elist;
							

All list values are built in the same format. It’s just what you’re representing that’s different.The ilist refers to the specific interfaces on this router that this rule refers to. The glist applies to the external gateways that this export rule refers to. Finally, the elist is a set of values that specify which routes—networks, hosts, netmasks, and more—this rule fits.

After you’ve finished specifying the lists, close the statement with:

}; 

Now let’s take a look at handling gated interaction with external OSPF routers.You start this type of rule with:

export proto ospfase 

You may not need to add anything else to this line. It depends on your needs. If you want this rule to apply to networks that have cost metrics that are compatible with OSPF, then expand this line to:

export proto ospfase type 1 

On the other hand, if you want this rule to apply to networks that have incompatible costs when compared to OSPF, expand it to:

export proto ospfase type 2 

You don’t have to use either of these types if you are unsure. Finally, when it comes to the first line, if you want to limit this rule to an OSPF router within a specific AS, add the following to the end:

tag asnumber
							

Now you finish the line with one of the following structures, both of which should look familiar. Use this one if you want the rule to refuse to export matching routes:

restrict; 

Alternatively, use this one if you want to use this rule to allow for exporting, where the metric item and its value are optional:

metric value {
     evalue1; 
     … 
     evalueN; 
}; 

Then there’s the case of exporting routes learned by OSPF. You start these statements with one of the two following lines:

proto ospf 
proto ospfase 

If you don’t want anything matching this rule exported, end the statement with only:

restrict; 

Otherwise, if you want to add a cost metric to the OSPF or OSPFASE routes you export, and then end this line with metric value { (the curly brace must be there even if metric value isn’t). Then, move to the next line and add the first in a potential series of lines defining the specific routes to which this rule applies. Each one of these lines starts with one of the usual network and host definition items and then has either restrict; or metric value; at the end—or nothing to use the default cost. After the statement is complete, close it with };. An example of what you might end up with is:

proto ospfase {
     192.168.15.*; 
     host 192.168.15.2 metric 300; 
     host 192.168.15.9 restrict; 
}; 

Now we can move on to export rules for both EGP and BGP. In this case, both egp and bgp are interchangeable as far as plugging these items into the format.We’ll use _gp for the examples. First we’ll look at how to set up rules for exporting data to EGP or BGP from other autonomous systems. If you don’t want to export anything to external EGP or BGP routers, use the rule:

export proto _gp as asnum 
     restrict; 

If you want more individual control so you can explicitly list which routes should be exported to EGP or BGP, then use the following format:

export proto _gp as asnum 
     metric value {
          elist1; 
          … 
          elistN; 
     }; 

The metric value clause is optional as usual because you can just leave it to the defaults. You also need rules for how to handle exporting routes learned from BGP or EGP. To prevent these from going out, use the structure:

proto _gp autonomoussystem asnum 
     restrict; 

To individually control which routes are exported and which are not, use the structure:

proto _gp autonomoussystem asnum 
     metric value {
          route1; 
          … 
          routeN; 
     }; 

Once again, the metric value clause is optional. At the end of each route line, you can have either metric value or restrict. As you can tell by now, even though some of the details are different from protocol to protocol, the structure for the statements is pretty much the same.

There are some additional situations you can set up with export as well. You don’t have to do everything according to protocol. In fact, not every route on your network was learned using a protocol at all. To apply routing according to specific interfaces, start with the following:

proto 

After proto, you have one of three choices:

• direct. Refers to the interfaces on this router.

• kernel. Refers to data installed using the route command.

• static. Refers to data installed using gated’s static statement.

So now let’s say that you have:

proto static 

After this, drop down to the next line.You may or may not place here the structure:

interface ilist
							

Add this item only if you want this rule to be specific to one or more particular interfaces. On the next line (or this one if you didn’t use the interface clause) you put restrict; to end the statement if you want to use this rule to prevent exportation. Otherwise, you may want to make the next line:

metric value {

Even if you don’t use the metric clause, you need the open curly brace. Now drop down to the next line.You start this one with the information that specifies what exact route to which you’re referring. As usual, you can have multiple lines here in the format:

     route1; 
     … 
     routeN; 
}; 

If you don’t want to use the default metric, you have the usual two options for the end of each line (before the semi-colon):

• metric value. Set the cost for using this interface instead of using the default costs of 0 for direct, 40 for kernel, or 60 for static.

• restrict. Do not allow routes matching this rule to be exported.

Configuring Route Aggregation

As we discussed in Chapter 4, you can advertise a network address to the outside world as though it is a single-piece entity, when in fact it is broken down into smaller networks with subnets or IPv6. As long as gated, your router, understands where to send the data once it reaches the overall network, everything will work fine.

You start a route aggregation section with one of the following lines of code:

aggregate default 
aggregate networkIP 
aggregate networkIP mask netmask 
aggregate networkIP masklen bitmask
							

You should already be familiar with the terms networkIP, netmask, and bitmask by this point.The second line also has a number of combinations you might use:

{
preference value {
brief {
preference value brief {

You only use the preference option if you don’t want to use the default setting of 130 for aggregate routes. Also you only need the brief term if you want the path specified for the AS to be truncated down to a common denominator.

From here, you have a series of lines that denote which routes should and should not be advertised. No matter which type of rule you’re setting up, it starts with the term proto. After this you might utilize one of six different options:

• aggregate. This rule applies to any route that gated has made an aggregate rather than advertising the individual components.

• all. This rule applies to all types of routes.

• direct. This rule applies to the interfaces attached to this router.

• kernel. This rule applies to routes placed into the routing table with the route command.

• static. This rule applies to routes assigned with a static gated statement.

• value. This rule applies to the specified routing protocol out of those supported by gated.

Another item available for placing after proto (with or without what you see in the preceding list) is a choice of one of the following:

• as asnum. This rule applies to the specified autonomous system.

• as asregexp. This rule applies to the autonomous systems that match the regular expression.

• tag value. This rule applies to the routes that have the specified tag.

Now is when you decide where you’re going with this rule. If it is only meant to prevent a single aggregation, just end it with:

restrict; 

However, if you want to build a series of rules according to what networks and hosts you’re looking at, then you next have to decide if you want to use the default aggregate preference value of 130 or if you want to change it for this rule as an overall new default. If you do, start the next line with:

preference value {

If not, just use the curly brace on this line. On the next line, you use the very familiar format:

								route1; 
     … 
     routeN; 
}; 

As usual, with each route you can add at the end either restrict or preference value. Build as many proto statements as you need within the overall aggregate statement, and then close it all out with an ending:

}; 

Running Public gated

Fortunately, the most complex part of dealing with gated is the configuration. After you reach the point of actually being ready to run the daemon, it’s time to make sure that the router is working as you anticipated. Only then you can finally rest.What I recommend here is typing things manually at the command line and taking notes for what works and what doesn’t. As soon as you know the exact format you need to use when running gated, add the command to /etc/rc.local or to the daemon init script according to how you prefer to start your network services.

As a general rule, you don’t tend to work directly with gated at this point. One of this daemon’s companion programs is gdc, which is the gated controller. Even if you’ve already installed gated, you might not have gdc. It seems that some distributions don’t include gdc as part of the gated package, nor even in a separate one. However, gdc does come with the main gated public source, which you can get by going to www.gated.org.

Starting gdc

The gdc program itself doesn’t run continuously. Each time you want to use it, you have to use the necessary flags and commands. The flags are listed in Table 5.25. As soon as you have gdc and its flags typed in, add the commands specified in the following section. This allows you to manipulate gated without having to actually touch the daemon itself. Doing this can save a lot of angst and heartache down the road.

Items -c, -f, -m, and -s are all used primarily to fix problems with gated running out of space when it tries to run.

Testing gated.conf

One of the first things you’ll probably want to do after you finish configuring gated is to utilize gdc to check /etc/gated.conf for syntax errors and other such concerns. You accomplish this with the commands listed in Table 5.26. One thing to keep in mind is that this routing daemon actually keeps multiple versions of gated.conf in storage. The first time you utilize gated, you’ll have it loading your original gated.conf. After that make sure you work with the correct file—don’t just delete gated.conf when you’re changing configuration settings and do not work directly on gated.conf itself. There’s more on this in the section,“Manipulating gated, ” in this chapter.

Manipulating gated

The gdc handler has many other functions that exist to help you to both start and stop the gated daemon as well as alter its behavior and even update it’s current data. These commands are outlined in Table 5.27. One thing it is important to understand here is that gated maintains three copies of its configuration file, /etc/gated.conf, after you’ve updated its settings at least once. These copies entail:

• /etc/gated.conf+. The new configuration file you want gated to load.

• /etc/gated.conf. The current configuration file in use by gated.

• /etc/gated.conf. The last gated configuration file you used.