gated(1M) —

NAME

gated - gateway routing daemon

SYNOPSIS

gated [ −t[i][e][r][p][u][R][H] ] [ logfile

DESCRIPTION

gated is a routing daemon that handles multiple routing protocols and is meant to be a replacement for routed(1M), egpup(1M), or any routing daemon that speaks the HELLO routing protocol. gated currently handles the RIP, EGP, and HELLO routing protocols. The gated process can be configured to perform all three routing protocols or any combination of the three. The configuration for gated is by default stored in the file /etc/gated.conf, but can be changed at compile time.

gated can be invoked with a number of debug flags and/or a log file. When debug flags are used, the process does not fork and detach itself from the controlling terminal. If there is no log file specified, all debug output is sent to the controlling terminal; otherwise, the debugging output is sent to the log file specified. The valid debugging flags are as follows:

−tIf used alone, log all error messages, route changes and packets sent and received. Using this flag alone turns on the i, e, r, and p debug flags automatically. When used with another flag, the −t has no effect and only the accompanying flags are recognized. Note that when using other flags, you must use the −t with them.

iLog all internal errors and interior routing errors.

eLog all external errors due to EGP, exterior routing errors, and EGP state changes.

rLog all routing changes.

pTrace all EGP packets sent and received.

uLog all routing updates sent.

RTrace all RIP packets received.

HTrace all HELLO packets received.

The gated process always logs fatal errors. If no log file is specified and no debugging flags are set, all messages are sent to /dev/null.

Signal Processing

gated catches a number of signals and performs specific actions when caught. Currently gated does special processing with the SIGHUP and SIGINT signals. When a SIGHUP is sent to the gated process and gated was invoked with debug flags and a log file, debugging is toggled off and the log file is closed. At this point, the log file may be moved or removed. The next SIGHUP to gated will toggle the debugging on using the same debug flags in the command line. The log file specified in the command line is created, if necessary, and the debug output is sent to that file. The debug output is appended to an already existing log file. This is useful for having rotating log files much like the syslog daemon.

Sending gated a SIGINT will cause a memory dump to be scheduled within the next 60 seconds. The memory dump will be written to the file /usr/tmp/gated_dump. gated will finish processing any routing updates currently being worked on before performing the memory dump. The memory dump contains all relevant routing information and interface information. If the file /usr/tmp/gated_dump already exists, the memory dump will be appended to the existing file.

Configuration File Options for Routing Protocols

In this section, the numerous configuration options are explained. Each time the gated process is started, it reads the file /etc/gated.conf to obtain its instructions on how routing will be managed with respect to each protocol. The configuration options are as follows:

RIP {yes │ no │ supplier │ pointopoint │ quiet │ gateway #}

This tells the gated process how to perform the RIP routing protocol. Only one of the above RIP arguments is allowed after the keyword “RIP”. If more than one is specified, only the first one is recognized. The arguments are:

yesPerform the RIP protocol. Process all incoming RIP packets and supply RIP information every 30 seconds only if there are two or more network interfaces.

noDo not perform the RIP protocol. Do no RIP processing.

supplierPerform the RIP protocol. Process all incoming RIP packets and force the supplying of RIP information every 30 seconds, no matter how many network interfaces are present.

pointopoint
Perform the RIP protocol. Process all incoming RIP packets and force the supplying of RIP information every 30 seconds, no matter how many network interfaces are present. When this argument is specified, RIP information will not be sent out in a broadcast packet. The RIP information will be sent directly to the gateways listed in the “sourceripgateways” option described below.

quietProcess all incoming RIP packets, but do not supply any RIP information no matter how many network interfaces are present.

gateway #
Process all incoming RIP packets, supply RIP information every 30 seconds, and announce the default route (0.0.0.0) with a metric of #. The metric should be specified in a value that represents a RIP hopcount. With this option set, all other default routes coming from other RIP gateways will be ignored.

If no “RIP” clause is specified, RIP will not be performed.

HELLO {yes │ no │ supplier │ pointopoint │ quiet │ gateway #}

This tells the gated process how to perform the HELLO routing protocol. The arguments parallel the RIP arguments, but do have some minor differences. Only one of the above HELLO arguments is allowed
after the keyword “HELLO”. If more than one is specified, only the first one is recognized. The arguments:

yesPerform the HELLO protocol. Process all incoming HELLO packets and supply HELLO information every 15 seconds only if there are two or more network interfaces.

noDo not perform the HELLO protocol. Don’t do HELLO processing.

supplierPerform the HELLO protocol. Process all incoming HELLO packets and force the supplying of HELLO information every 15 seconds, no matter how many network interfaces are present.

pointopoint
Perform the HELLO protocol. Process all incoming HELLO packets and force the supplying of HELLO information every 15 seconds no matter how many network interfaces are present. When this argument is specified, HELLO information will not be sent out in a broadcast packet. The HELLO information will be sent directly to the gateways listed in the “sourcehellogateways” option described below.

quietProcess all incoming HELLO packets, but do not supply any HELLO information no matter how many network interfaces are present.

gateway #
Process all incoming HELLO packets, supply HELLO information every 15 seconds, and announce the default route (10.0.0.0) with a time delay of #. The time delay should be specified in milliseconds. Net 10 is used as a default because the NSFnet backbone gateways use net 10 as default (not 0.0.0.0). This can create complex routing situations in a UNIX System environment, so when you are running as a default HELLO gateway, you will still be able to listen and act on other net 10 information from RIP or HELLO. However, you will still announce via HELLO, net 10 with time delay #. If you are not a HELLO gateway, you will not HELLO announce net 10. If you are not connected to the ARPAnet, you should not be using this option.

If no “HELLO” clause is specified, HELLO will not be performed.

EGP {yes │ no}

This clause allows the processing of EGP by gated to be turned on or off.

noDo not perform any EGP processing.

yesPerform all EGP operations.

Please note that, by default, EGP processing will take place. Therefore, if no “EGP”clause is specified, all EGP operations will take place.

autonomoussystem #

If performing the EGP protocol, you must use this clause to specify your autonomous system number (#). If not specified, gated will exit and give a fatal error message.

egpmaxacquire #

If performing the EGP protocol, this clause specifies the number of EGP peers you will be performing EGP with. This cannot be 0− gated will exit on such a condition.

egpneighbor gateway

If performing the EGP protocol, this clause specifies who you will be performing EGP with. “Gateway” can be either a symbolic name in /etc/hosts or it can be in dot (a.b.c.d) notation. Dot notation is recommended. Each EGP neighbor will be acquired in the order listed in the configuration file.

Configuration File Options for Routing Information

The following configuration file options deal with how routing knowledge is dealt with. This includes incoming knowledge as well as the knowledge we will give out.

trustedripgateways gateway [gateway] [gateway] .....
trustedhellogateways gateway [gateway] [gateway] .....

With these clauses specified, you will only listen to RIP or HELLO information respectively, from these RIP or HELLO gateways respectively. “gateway” can be either a symbolic name from /etc/hosts or it can be in dot format (a.b.c.d). Again, dot format is recommended to eliminate confusion. Please note that the propagation of your knowledge is not restricted in any way by this clause.

sourceripgateways gateway [gateway] [gateway] .....
sourcehellogateways gateway [gateway] [gateway] .....

You will send RIP or HELLO information directly to the gateways specified. If “pointopoint” is specified in the “RIP” or “HELLO” clauses mentioned above, you will only send RIP or HELLO information to the specified gateways. You will not send out any information using the broadcast address. If “pointopoint” is not specified in those clauses and you are a supplier of RIP or HELLO information, you will send information to the specified gateways as well as broadcasting it using a broadcast address.

noripoutinterface intfaddr [intfaddr] [intfaddr] .....
nohellooutinterface intfaddr [intfaddr] [intfaddr] .....
noripfrominterface intfaddr [intfaddr] [intfaddr] .....
nohellofrominterface intfaddr [intfaddr] [intfaddr] .....

Turning on and off protocols on a per-interface basis is accomplished with the above clauses. “no{rip│hello}frominterface” means that no RIP or HELLO information will be accepted coming into the listed interfaces from another gateway. “no{rip│hello}outinterface” means that no RIP or HELLO knowledge will be sent out of the listed interfaces. “intfaddr” should be in dot notation (a.b.c.d).

passiveinterfaces intfaddr [intfaddr] [intfaddr] .....

In order to dynamically determine if an interface is properly functioning, gated will time out an interface when no RIP or HELLO packets are being received on that particular interface. IMP interfaces send a RIP or HELLO packet to themselves to determine if the interface is properly functioning. Interfaces that have timed out automatically have their routes re-installed when routing information is again received over the interface. The above clause stops gated from timing out the listed interfaces. The interfaces listed will always be considered up and working. If you are not a RIP or HELLO supplier, all interfaces will not be aged and the “passiveinterfaces” automatically applies to all interfaces.

interfacemetric intfaddr metric#

This feature allows you to specify an interface metric for the listed interface. On systems that support interface metrics, this clause will override the kernel’s metric. On systems that do not have support for an interface metric, this feature allows you to use an interface metric. The interface metric is added to the true metric of each route that comes in via routing information from the listed interface. The interface metric is also added to the true metric of any information sent out via the listed interface. You will need one clause for each interface that you want to specify an interface metric for.

reconstmetric intfaddr metric#

This is a first attempt to throw hooks for fallback routing into gated. If the above clause is used, any RIP information coming into the listed interface will have the metrics of the routes contained in the RIP information set to the specified “metric#”. Metric Reconstitution should not be used lightly as it could be a major contributor in the formation of routing loops. USE THIS WITH EXTREME CAUTION. Any route that has a metric of infinity will not be reconstituted and left as infinity.

donotlisten net intf addr [addr] ... proto {rip│hello}
donotlistenhost host intf addr [addr] ... proto {rip│hello}

This clause reads as follows: keyword “donotlisten” followed by a network number which should be in dot format followed by keyword “intf”. Then there should be a list of interfaces in dot format followed by the keyword “proto” followed by “rip” or “hello”.

This means that any information regarding “net” coming in via the specified protocols AND from the specified interfaces will be ignored. You can also put the keyword “all” after the keyword “intf” to specify all interfaces on the machine. For example:

donotlisten 10.0.0.0 intf 128.84.253.200 proto rip

means that any RIP information about net 10 coming in via interface 128.84.253.200 will be ignored. You must have one clause for each net that you want to put this restriction on.

donotlisten 26.0.0.0 intf all proto rip hello

means that any RIP and HELLO information about net 26 coming in via any interface will be ignored.

“donotlistenhost” can be described the same way as above except that you provide a host address instead of a network address. Restrictions of the nature described above are applied to the specified host route learned of by the specified routing protocol.

listen net gateway addr [addr] ... proto {rip│hello}
listenhost host gateway addr [addr] ... proto {rip│hello}

This clause reads as follows: keyword “listen” followed by a network number which should be in dot format followed by keyword “gateway”. Then there should be a list of gateways in dot format followed by the keyword “proto” followed by “rip” or “hello”.

This means to only listen to information about network “net” by the specified protocol(s) only from the listed “gateways”. Ignore all other information from any other gateway regarding this network. For example:

listen 128.84.0.0 gateway 128.84.253.3 proto hello

means that any HELLO information about net 128.84 coming in via gateway 128.84.253.3 will be accepted. Any other information about 128.84 from any other gateway will be rejected. You must have one clause for each net that you want to put this restriction on.

listenhost 26.0.0.15 gateway 128.84.253.3 proto rip

means that any information about host 26.0.0.15 must come via RIP and from gateway 128.84.253.3. All other information regarding this host will be ignored.

announce net intf addr [addr] ... proto type [egpmetric #]
announcehost host intf addr ... proto type [egpmetric #]
noannounce net intf addr [addr] ... proto type [egpmetric #]
noannouncehost host intf addr ... proto type [egpmetric #]

These clauses allow you to place restrictions on the networks and hosts you announce and by what protocol they are announced. The “announce{host}” and “noannounce{host}” clauses may not be used together on the same interface. You can only have one or the other per interface. With the “announce{host}” clause, you will only announce the nets or hosts that have an associated “announce{host}” clause with the appropriate protocol. With the “noannounce{host}” clause, you will announce everything, EXCEPT those nets or hosts that have an associated “noannounce{host}” clause. Therefore, you have a choice of announcing only what is on your announce list or everything except those nets on your noannounce list on a per-interface basis.

The arguments are the same as in the “donotlisten” clause except you can specify “egp” in the “proto” field. “type” can either be rip, hello, egp, or any combination of the three. When egp is specified in the “proto” field, you must specify an egp metric. This is the metric at which you will announce, via EGP, the listed net.

Note that these are not static route entries. These restrictions only apply if the net or host is learned of via one of the routing protocols. If a restricted network suddenly becomes unreachable and goes away, announcement of this net will of course stop until it is learned of again. Some examples:

announce 128.84 intf all proto rip hello egp egpmetric 0
announce 10.0.0.0 intf all proto rip
announce 0.0.0.0 intf 128.84.253.200 proto rip
announce 35.0.0.0 intf all proto rip egp egpmetric 3

With only these four “announce” clauses in the configuration file, this gated process will only announce these four nets. It will announce 128.84 via RIP and HELLO to all interfaces and announce it via EGP with a metric of 0. Net 10 will be announced via RIP to all interfaces. Net 0 (default) will be announced by RIP out interface 128.84.253.200 only. Net 35 will be announced via RIP to all interfaces and announced via EGP with a metric of 3. These are the only nets that will be broadcast by this gateway. Once you have one “announce” clause, only the nets with “announce” clauses will be broadcast; this includes local subnets. Once an “announce{host}” or “noannounce{host}” has an “all” specified after an “intf”, that clause is applied globally and you lose the option of having per-interface restrictions. If no routing announcement restrictions are desired, do not include any “announce” clauses in your configuration file. All information gained will then be propagated out. Please note that this does not affect what information is being listened to. Any net that does not have an “announce” clause is still added to the kernel routing tables, but it is not announced anywhere else by your gateway. To stop nets from being added to the kernel see the “donotlisten” clause discussed earlier.

announce 128.84 intf 128.59.2.1 proto rip
noannounce 128.84 intf 128.59.1.1 proto rip

The above clauses mean that on interface 128.59.2.1 only information about 128.84 will be announced via RIP, but on interface 128.59.1.1, all information except 128.84 via RIP will be announced.

noannounce 128.84 intf all proto rip hello egp egpmetric 0
noannounce 10.0.0.0 intf all proto hello

These clauses mean that all nets except these two that are restricted will be propagated. Specifically, net 128.84 will not be announced out any interface with any protocols. Knowledge of 128.84 is not sent anywhere. Net 10 will not be announced via HELLO to any interface. This also means that net 10 will be announced to every interface via RIP. This net will also be broadcast via EGP with a metric specified in the “defaultegpmetric” clause.

defaultegpmetric #

This is a default EGP metric to use when you have no routing restrictions. Normally, with no routing restrictions, gated announces all networks learned via HELLO or RIP via EGP with this specified default EGP metric. If this clause is not used, the default EGP metric is set to 255, which would make any EGP advertised route of this nature be ignored. When there are no routing restrictions, any network that you have a direct interface to is announced via EGP with a metric of 0.
Note that this does not include subnets, but only the non-subnetted network.

defaultgateway gateway proto {active│passive}

This is the initial default gateway that is installed in your kernel during startup and initialization. If you are running EGP, as soon as you receive an update from your EGP neighbor, this route is deleted. If you are not running EGP, but running RIP and “active” is specified, this default route will be deleted and overwritten by any other default it hears from any other RIP gateway. If no default routes are being propagated throughout your local network, this default route will stay in your kernel’s routing table. If “passive” is specified, the default route will be added to the kernel and will not be overwritten by any other default route broadcast. You will also not propagate the default route with the “passive” option set.

“gateway” should be an address in dot notation. “proto” should be either rip, egp, or hello. The “proto” field just initializes what protocol the route was learned by. In this case it is unused, but the field retained for consistency.

net netaddr gateway addr metric hopcnt {rip│egp│hello} host hostaddr gateway addr metric hopcnt {rip│egp│hello}

The following clauses install a static route to net “netaddr” or host “hostaddr” through gateway “addr” at a metric of “hopcnt” and learned via either RIP, HELLO, or EGP. As usual, dot notation is recommended for the addresses. This route will be installed in the kernel’s routing table and will never be affected by any other gateway’s RIP or HELLO announcements. The protocol by which it was learned is important when it comes to announcing via EGP. If the protocol is rip or hello and there are no routing restrictions, then this route will be announced by EGP with a metric of “defaultegpmetric”. If the protocol is egp and there are no routing restrictions, then this route will be announced by EGP with a metric of “hopcnt”.

egpnetsreachable net [net] [net] .....

This option was left in as a “soft restriction”. It cannot be used when the “announce” or “noannounce” clauses are used. Normally, with no restrictions, gated announces all routes learned from RIP and HELLO via EGP. The “egpnetsreachable” clause restricts EGP announcement to those nets listed in the clause. The metric used for the HELLO and RIP learned routes is the value given in the “defaultegpmetric” clause. If this clause does not specify a value, the value is set to 255. With the “egpnetsreachable” clause, you cannot set individual unique EGP metrics for each net. The “defaultegpmetric” is used straight across the board except, of course, for any direct interface. In this case, a metric of 0 is used.

Notes on Configuration Options

gated stores its Process ID in the file /etc/gated.pid. If running EGP, supplying the default route (RIP gateway), and you lose all of your EGP neighbors, you will stop broadcasting the default route until your EGP neighbors regain contact. If routing restrictions are used, gated logs all invalid networks using syslog at log level LOG_WARNING and facility LOG_DAEMON.

With the complexity of the current network topology and with many back door paths to networks, the use of routing restrictions is recommended. With the current routing strategies, it is easy for illegal or invalid networks to penetrate into the ARPAnet Core or the NSFnet backbone. Using routing restrictions does take a little more maintenance time and routing restrictions are not the long-term answer, but for now, in order to be good internet players, we must use them.

Notes on Implementation Specifics

gated stores all metrics internally in milliseconds. The RIP metric is mapped to a millisecond-based metric and processed. This is so that we keep the granularity of the HELLO protocol time delay intact.

In the gated.conf file, all references to POINT-TO-POINT interfaces must use the DESTINATION address. This is the exact opposite of the old versions, which used the source address of the PTP link. This is the only change made to the gated.conf syntax. Otherwise, all old gated.conf files should be compatible.

A 2-minute hold down is in effect for all of the protocols.

Changes can be made to the interfaces and gated will notice them without having to restart the process. If you change an address, netmask, subnetmask, broadcast address, or interface metric, you must first ifconfig the interface down and then back up again. You may have to wait about 30 seconds before gated realizes the interface is down. gated checks the interfaces every 30 seconds. You need not bring the interface up or down for flag changes.

RIP does propagate and listen to host routes. This was done to handle PTP links more consistently. The RIP_TRACE commands are also supported in this version.

Subnet interfaces are supported. This means that subnets will not get propagated where they shouldn’t be. For example, if a gateway is gatewaying two class B networks, the subnet routes for each respective class B net are not propagated into the opposite class B net. Only the class B network number is propagated to the appropriate place.

gated listens to host and network REDIRECTs and tries to take an action on the REDIRECT for its own internal tables that parallels the kernel’s action. In this way, the redirect routine in gated parallels the Berkeley kernel redirect routine as closely as possible. Unlike the Berkeley kernel, gated times out routes learned of via a REDIRECT after 6 minutes. The route is then deleted from the kernel routing tables. This helps keep the routing tables on your gateway more consistent and clean. Any route that was learned of via a REDIRECT is not announced by any routing protocol.

FILES

/etc/gated.confconfiguration file

/etc/gated.pidwhere the process ID is stored

/usr/tmp/gated_dump
memory dump file

/etc/gatedthe gated process

Museum

Related Articles