Redirect Processing

The redirect code is passed ICMP or ISO redirects learned by monitoring ICMP messages, or via the routing socket on systems that support it. It processes the redirect request and decides whether to accept the redirect. If the redirect is accepted, a route is installed in the gated routing table with the protocol redirect. Redirects are deleted from the routing table after 3 minutes.

If GateD determines that a redirect is not acceptable, it tries to figure out if the kernel forwarding table has been modified. On systems where ICMP messages are monitored this is accomplished by trying to second guess what the kernel would have done with the redirect. On systems with the routing socket, the kernel provides and indication of whether the redirect was accepted; GateD ignores redirects that were not processed.

If GateD has determined that the state of the kernel forwarding table has been changed, the necessary requests to the kernel are made to restore the correct state.

Note that on currently available systems it is not possible to disable the processing of ICMP redirects, even when the system is functioning as a router. To ignore the effects of redirects, GateD must process each one and actively restore any changes it made to the kernel's state. Because of the mechanism's involved there will be windows where the effects of redirects are present in the kernel.

By default, GateD removes redirects when actively participating in an interior gateway protocol (RIP, HELLO, OSPF or IS-IS). It is not possible to enable redirects once they have been automatically disabled. Listening to RIP or HELLO in nobroadcast mode does not cause redirects to be ignored, nor does the use of EGP and BGP. Redirects must be manually configured off in these cases.

Note that in accordance with the latest IETF Router Requirements document, GateD insures that all ICMP net redirects are processed as host redirects. When an ICMP net redirect is accepted, GateD issues the requests to the kernel to make sure that the kernel forwarding table is updated to reflect a host redirect instead of a net redirect.

The redirect statement does not prevent the system from sending redirects, only from listening to them.


The Redirect Statement

redirect yes | no | on | off
[ {
    preference preference ;
    interface interface_list 
        [ noredirects ] | [redirects ] ;
    trustedgateways gateway_list ;
    traceoptions trace_options ;
} ] ;

preference
Sets the preference for a route learned from a redirect. The default is 30.
interface interface_list
The interface statement allows the enabling and disabling of redirects on an interface-by-interface basis. See the section on inteface list specification for the description of the interface_list. The possible parameters are:
noredirects
Specifies that redirects received via the specified interface will be ignored. The default is to accept redirects on all interfaces.
redirects
This is the default. This argument may be necessary when noredirects is used on a wildcard interface descriptor.
trustedgateways gateway_list
Defines the list of gateways from which redirects will be accepted. The gateway_list is simply a list of host names or addresses. By default, all routers on the shared network(s) are trusted to supply redirects. But if the trustedgateways clause is specified only redirects from the gateways in the list are accepted.
traceoptions trace_options
There are no redirect-specific tracing options. All non-error messages are traced under the normal class.

Tracing options

There are no Redirect-specific tracing options. All non-error messages are traced under the normal class.
Last updated 1995/06/06 15:10:10.

gated@gated.cornell.edu