• Choose a category
• All
• Classic-Fiction

A real example of an OSPF configuration clause appears in section 2 of the complete gated.conf configuration file on page 365.

Protocol configuration for ICMP redirects

gated lets you exert some administrative control over the handling of routes learned through ICMP redirects (see page 285 for an explanation of what these are).

redirect yes | no | on | off [ {

preference preference ;

interface interface_list [noredirects] | [redirects] ;

trustedgateways gateway_list ;

traceoptions trace_options ;

} ] ;

These options should all be familiar by now. preference sets the route preference for redirect-derived routes in general (the default is 30, which is fairly good). The options redirects and noredirects enable and disable acceptance of redirects per network interface, and trustedgateways enables them only when sent by specific routers. There are no redirect-specific tracing options.

On some systems, the kernel acts on ICMP redirects without allowing gated to intervene and enforce its own handling policy. On these systems, gated checks to see if the kernel accepted a redirect and will manually remove the redirect from the routing table if it is not wanted.

Static routes

Static routes are configured with a static statement:

static {

dest gateway gateway_list [interface interface_list] [preference preference]

[retain] [reject] [blackhole] [noinstall] ;

};

The dest can be specified with any of the usual suspects:

host host

default

network

network mask mask

network masklen length

The gateway_list is the set of routers through which this destination can be reached. While there may in theory be more than one gateway, most kernels do not support multipath routing.

If the designated gateway is not on a directly connected network (via one of the interfaces specified in the optional interface_list), the route will be ignored.

The route preference defaults to 60, which allows it to be superseded by OSPF-computed routes or by ICMP redirects.

If a route is marked with retain, it will be left in the kernel’s routing table when gated exits. Normally, gated cleans up after itself and leaves only interface and preexisting routes. Conversely, the noinstall option causes the route not to be installed in the local routing table, but only made available for propagation to other routers. This option is useful on routers that act as “route servers,” meaning that they don’t actually route traffic but rather coordinate routing information for the network infrastructure (they may have access to an alternate “management traffic only” network that carries their packets).

Routes marked with the blackhole and reject tags prevent forwarding from occurring on systems that support these features. With reject, an ICMP error is returned to the sender; with blackhole, the packets just mysteriously disappear without a trace, kind of like Evi’s email.

A static route example appears in section 3 of the complete gated.conf configuration file example on page 366.

Exported routes

Once gated has computed the routes it likes, it defaults to putting them in the kernel’s forwarding table. For most applications, this is all that’s necessary. Sometimes, however, it’s desirable to configure gated to act as a kind of translator, accepting information from one protocol and distributing it out another. This is done in the configuration file with an export clause:

export proto protocol

[interface interface_list | gateway gateway_list]

restrict ;

or

export proto protocol

[interface interface_list | gateway gateway_list]

[metric metric] {

export_list ;

};

In this case, protocol is the routing protocol that will be advertising the translated information, and export_list is what to translate as specified by listing a proto clause for each dataset to be translated. Here’s a sample export_list:

proto static {

ALL metric 1;

};

This snippet translates all static routes and inserts them into the exported list with a metric of 1.

A complete gated configuration