gated(1M)

Requires Optional ARPA Services Software

NAME

gated − gateway routing daemon

SYNOPSIS

/etc/gated [−t [ierpuRH]] [logfile]

DESCRIPTION

gated is a routing daemon that handles multiple routing protocols. gated currently handles the RIP, EGP, and HELLO routing protocols. The gated process can be configured to perform all routing protocols or any combination of the three. gated configuration is stored in the file /etc/gated.conf.

Command Line Tracing Options

gated can be invoked with a number of tracing flags and/or a log file. Tracing flags can also be specified in the configuration file with the traceflags clause. Note that to use any of the tracing flag options on the command line, the −t is required and the rest of the options (if used) should immediately follow the −t. gated forks and detaches itself from the controlling terminal unless tracing flags are specified without specifying a log file. If a log file is not specified, tracing output is sent to the controlling terminal. The valid tracing flags are as follows:

−t If used alone, −t causes gated to log all error messages, route changes and EGP packets sent and received. Using this flag alone turns on the i, e, r, and p trace 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, the −t flag must immediately precede them.

i Log all internal errors and interior routing errors.

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

r Log all routing changes.

p Trace all EGP packets sent and received.

u Display the entire contents of routing packets sent and received (when used with p, R, H, or N).

R Trace all RIP packets received.

H Trace all HELLO packets received.

The gated process always logs fatal errors. If no log file is specified and no tracing flags are set, all messages are sent to /dev/null. Also, most trace messages, as well as other messages, are sent to syslog.

Signal Processing

gated catches a number of signals to perform specific actions. Currently gated does special processing with the SIGHUP, SIGINT and SIGUSR1 signals.

When a SIGHUP is sent to the gated process and gated is invoked with trace flags and a log file, tracing is toggled off and the log file is closed. At this point the log file can be moved or removed. The next SIGHUP to gated toggles tracing on. gated reads the configuration file and sets the tracing flags to those specified with the traceflags clause. If no traceflags clause is specified, tracing is resumed using the trace flags in use before tracing was toggled off. The log file specified in the command line is created if necessary and the trace output is sent to that file. If the logfile already exists, tracing output is appended to it. SIGHUP is useful for rotating log files like those of the syslog daemon.

Sending gated a SIGINT schedules a dump of gated’s routing tables to occur within the next sixty seconds. The dump is written to the /usr/tmp/gated_dump file. gated processes pending routing updates before performing the dump. The dump contains a snapshot of the current gated status, including the interface configurations, EGP neighbor status and the routing tables. If the file /usr/tmp/gated_dump already exists, the memory dump is appended to the existing file.

On receipt of a SIGUSR1, gated rereads selected information from the configuration file. This information currently includes the announcetoAS, noannouncetoAS and validAS. If no errors are detected, the new configuration information is put into effect. If errors are detected, the configuration information is not changed. gated also checks the status of the interfaces on receipt of a SIGUSR1.

Configuration File Options For Controlling Tracing Output

traceflags traceflag [traceflag] [traceflag] ...

This clause tells the gated process what level of tracing output is desired. This option is read during gated initialization and whenever gated receives a SIGHUP. This option is overridden at initialization time if tracing flags are specified on the command line. Valid trace flags are as follows:

internal Log all internal errors and interior routing errors.

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

route Log all routing changes.

egp Trace all EGP packets sent and received.

update Log all routing updates sent.

rip Trace all RIP packets received.

hello Trace all HELLO packets received.

icmp Trace all ICMP redirect packets received.

stamp Print a timestamp to the log file every 10 minutes.

general A combination of internal, external, route and egp.

all Enable all of the above tracing flags.

If more than one traceflags clause is used, the tracing flags accumulate.

Default Configuration

gated normally reads configuration information from the configuration file /etc/gated.conf. If this file does not exist, gated assumes a default configuration file of:

RIP yes
HELLO no
EGP no

If the configuration file does not exist, there is only one network interface, and a default route is installed in the kernel, gated assumes that a simple default route is adequate.

Configuration File Options For Handling Routing Protocols

The numerous configuration options are explained in this section. 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 number}

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. A list of the arguments to the RIP clause follows:

yes Perform the RIP protocol; process all incoming RIP packets and supply RIP information every thirty seconds only if there are two or more network interfaces.

no Do not perform the RIP protocol.

supplier Perform the RIP protocol; process all incoming RIP packets and force the supplying of RIP information every thirty 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 thirty seconds, no matter how many network interfaces are present. When this argument is specified, RIP information is not sent out in a broadcast packet. Instead, the RIP information is sent directly to the gateways listed in the sourceripgateways option described below.

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

gateway number
Process all incoming RIP packets, supply RIP information every thirty seconds, and announce the default route (0.0.0.0) with a metric of number. The metric should be specified in a value that represents a RIP hopcount (that is, 0-16). With this option set, all other default routes coming from other RIP gateways will be ignored. The default route is only announced when actively peering with at least one EGP neighbor. Therefore, the gateway number option should only be used when EGP is used.

If no RIP clause is specified, RIP is not performed.

HELLO {yes | no | supplier | pointopoint | quiet | gateway number}

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 following arguments HELLO clause arguments are recognized:

yes Perform the HELLO protocol; process all incoming HELLO packets and supply HELLO information every fifteen seconds only if there are two or more network interfaces.

no Do not perform the HELLO protocol.

supplier Perform the HELLO protocol; process all incoming HELLO packets and force the supplying of HELLO information every fifteen 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 fifteen seconds no matter how many network interfaces are present. When this argument is specified, HELLO information is not sent out in a broadcast packet. The HELLO information is sent directly to the gateways listed in the sourcehellogateways option described below.

quiet Process all incoming HELLO packets, but do not supply any HELLO information regardless of how many network interfaces are present.

gateway number
Process all incoming HELLO packets, supply HELLO information every fifteen seconds, and announce the default route with a time delay of number. The time delay should be specified in milliseconds (that is, 0-30000). The default route is only announced when actively peering with at least one EGP neighbor. Therefore the gateway number option should only be used when EGP is used.

If no HELLO clause is specified, HELLO is not performed.

EGP {yes | no}

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

no Do not perform any EGP processing.

yes Perform all EGP operations.

autonomoussystem number

If performing the EGP protocol, this clause must be used to specify the autonomous system number as number. If EGP yes is specified in a clause, then the autonomoussystem clause must also be specified; if not specified, gated will exit and give a fatal error message.

egpmaxacquire number

If performing the EGP protocol, this clause specifies the number of EGP peers with whom gated will be performing EGP. This number must be greater than zero and less than or equal to the number of EGP neighbors specified, or gated will exit. If this clause is omitted, all EGP neighbors will be acquired.

egpneighbor gateway
        [ metricin metric ]
        [ egpmetricout egpmetric ]
        [ ASin asinnumber ]
        [ ASout asoutnumber ]
        [ AS asn ]
        [ nogendefault
        [ acceptdefault ]
        [ defaultout egpmetric ]
        [ validate ]
        [ intf interface ]
        [ sourcenet net ]
        [ gateway gatwayaddr ]

If performing the EGP protocol, this clause specifies with whom gated will be performing EGP. The gateway address can be either a symbolic name as understood by gethostbyname(3N) or an IP address in Internet dot notation (a.b.c.d). Dot notation is recommended to avoid ambiguity. Each EGP neighbor will be acquired in the order listed in the configuration file.

metricin specifies the internal time delay to be used as a metric for all of the routes learned from this neighbor. It should be specified as a time delay from zero to 30000. If this option and the validate option are not used, the internal metric used is the EGP distance multiplied by 100.

egpmetricout specifies the EGP distance used for all nets advertised to this neighbor. It should be specified as an EGP distance in the range of 0 to 255. If this option is not specified, the internal time delay for each route will be converted to an EGP distance for distances greater than 255 by dividing the internal time delay by 100. Distances greater than 255 are set to 255.

ASin causes gated to verify the autonomous system number of all EGP messages received from the specified neighbor. If the autonomous system number specified in a neighbor acquisition packet does not correspond to asinnumber, an error message is generated refusing the connection. If this option is not specified, no verification of autonomous system numbers is done.

ASout specifies the autonomous system number in EGP packets sent to this neighbor. If not specified, the autonomous system specified in the autonomoussystem clause is used. This clause should not normally be used; it is reserved for a special situation interfacing between the ARPANET and NSFNet.

AS specifies the autonomous system number that will be assigned to routes learned from this neighbor. If not specified, the autonomous system number received in the EGP packets from this neighbor will be used. This clause should not normally be used; it is reserved for a special situation interfacing between the ARPANET and NSFNet.

nogendefault specifies that this machine should not be considered for the internal generation of a default gateway route when RIP gateway number or HELLO gateway number is used. If not specified, the internal default gateway route will be generated when actively peering with this neighbor.

acceptdefault specifies that the default route should be considered valid when received from this neighbor. If this option is not specified, the reception of the default route causes a warning message to be printed and the route is ignored.

defaultout specifies that the internally generated default can be passed to this EGP neighbor at the specified distance. The distance should be specified as an EGP distance from 0 to 255. A default route learned from another gateway will not be propagated to an EGP neighbor. Normally, no default route will be passed via EGP. The acceptdefault option should not be specified when the defaultout option is used. If defaultout is specified, the egpmetric specified in the egpmetricout option does not apply to the default route. The default route will always use the metric specified by the defaultout option.

validate specifies that all networks received from this EGP neighbor must be specified in the validAS clause that also specifies the autonomous system of this neighbor. Networks not having a validAS clause are ignored after a warning message is printed.

intf specifies the interface for sending EGP packets to this neighbor. This option is only required when there is no common net/subnet with this egpneighbor. This option is currently only present for testing purposes, and does not imply correct operation when peering with an egpneighbor that does not share a common net/subnet.

sourcenet specifies the source network to be specified in EGP poll packets sent to this neighbor. If this option is not specified, the network (not subnet) of the interface used to communicate with this neighbor is used. This option is currently only present for testing purposes and does not imply correct operation when used.

gateway specifies the gateway for installing routes learned from an EGP neighbor on a different network. These routes are normally ignored. This option currently exists for testing purposes only, and correct operation cannot be assured when it is used.

Configuration File Options For Handling Routing Information

The following configuration file options tell gated how to deal with both incoming and outgoing routing information.

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

When these clauses are specified, gated will only listen to RIP or HELLO information respectively from these RIP or HELLO gateways. The gateway can be either a symbolic name as understood by gethostbyname(3N) or an IP address in Internet dot notation (a.b.c.d). Again, dot notation is recommended to eliminate ambiguity. Note that the propagation of routing information is not restricted by this clause.

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

gated sends RIP or HELLO information directly to the gateways specified. If pointopoint is specified in the RIP or HELLO clauses mentioned above, gated will only send RIP or HELLO information to the specified gateways. gated will NOT send out any information using the broadcast address. If pointopoint is not specified in those clauses and gated is supplying RIP or HELLO information, gated will send information to the specified gateways as well as broadcasting it using a broadcast address.

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

The above clauses turn protocols on and off on a per interface basis. The noripfrominterface and nohellofrominterface clauses mean that no RIP or HELLO information will be accepted coming into the listed interfaces from another gateway. The above noripoutinterface and nohellooutinterface clauses mean that no RIP or HELLO information will be sent out of the listed interfaces. The option intfaddr should be in dot notation (a.b.c.d).

passiveinterfaces intfaddr [ intfaddr ] ...

To dynamically determine if an interface is properly functioning, gated will time out an interface when no RIP, HELLO or EGP packets are being received on that particular interface. PSN interfaces send a RIP or HELLO packet to themselves to determine if the interface is properly functioning because the delay between EGP packets can be longer than the interface timeout. 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 gated is not a RIP or HELLO supplier, no interfaces will time out. Thus, passiveinterfaces automatically applies to all interfaces. HP-UX machines do not send the RIP and HELLO packets to themselves, so it is recommended that this clause be used for all interfaces.

interfacemetric intfaddr mnumber

This feature allows the specification of an interface metric for the listed interface. Since HP-UX does not support an interface metric, this feature allows the specification of one. The interface metric mnumber 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. The metric of directly attached interfaces is also set to the interface metric. Routing information broadcast about directly attached nets will be based on the specified interface metric. This clause is required for each interface on which an interface metric is desired.

reconstmetric intfaddr mnumber

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

fixedmetric intfaddr proto { rip| hello} mnumber

This is another attempt to throw hooks for fallback routing into gated. If the above clause is used, all routing information sent out the specified interface will have a metric of mnumber. For RIP, specify the metric as a RIP hopcount from 0 to infinity(16). For HELLO, specify the metric as a HELLO delay in milliseconds from 0 to infinity(30001). Any route that has a metric of infinity will be left as infinity. Fixed metrics should also be USED WITH EXTREME CAUTION!

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

These mean that any information regarding net or host coming in via the specified protocols and from the specified interfaces will be ignored. The keyword all is used 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.0.0.0 coming in via interface 128.84.253.200 will be ignored. One clause is required for each net on which this restriction is desired.

donotlisten 26.0.0.0 intf all proto rip hello

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

The donotlistenhost clause can be described the same way as above except that a host address is provided instead of a network address. The same type of restrictions apply.

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

These mean only listen to information about network net and host by the specified protocol(s) only from the listed gateway addrs. 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. One clause is necessary for each net to be restricted.

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 { rip| hello| egp} [ egpmetric mnumber]
announcehost host intf addr [addr] ... proto { rip| hello| egp} [ egpmetric mnumber]
noannounce net intf addr [addr] ... proto { rip| hello| egp} [ egpmetric mnumber]
noannouncehost host intf addr [addr] ... proto { rip| hello| egp} [ egpmetric mnumber]

These clauses allow restriction of the networks and hosts announced by protocol and interface. The announce and noannounce clauses cannot be used together on the same interface. Likewise for announcehost and noannouncehost. With the announce and announcehost clauses, gated will only announce the nets or hosts that have an associated announce or announcehost clause with the appropriate protocol. With the noannounce and noannouncehost clauses, gated will announce everything except those nets or hosts that have an associated noannounce or noannouncehost clause. This allows a choice of announcing only what is on the announce list or everything except those nets on the noannounce list on a per interface basis.

The arguments are the same as in the donotlisten clause except egp can be specified after proto. When egp is specified, an egp metric must be specified. This is the metric at which gated will announce the listed net via EGP.

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

Only one announce, announcehost, noannounce or noannouncehost can be specified per network or host. It is not possible to announce a network or host via HELLO out one interface and via RIP out another.

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.0.0 via RIP and HELLO to all interfaces and announce it via EGP with a metric of 0. Net 10.0.0.0 will be announced via RIP to all interfaces. Net 0.0.0.0 (default) will be announced by RIP out interface 128.84.253.200 only. Net 35.0.0.0 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 the first announce clause is specified, only the nets with announce clauses will be broadcast; this includes local subnets. Once an announce, announcehost, noannounce or noannouncehost has an all specified after the intf keyword, that clause is applied globally and the option of having per interface restrictions is lost. If no routing announcement restrictions are desired, announce clauses should not be used. All information learned will then be propagated out. Please note that this has no affect on the information to which gated listens. Any net that does not have an announce clause is still added to the kernel routing tables, but it is not announced via any of the routing protocols. The donotlisten clause can be used to stop nets from being added to the kernel.

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.0.0 will be announced via RIP, but on interface 128.59.1.1, all information will be announced, except 128.84.0.0 via RIP.

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

These clauses mean that except for the two specified nets, all nets will be propagated. Specifically, net 128.84.0.0 will not be announced on any interface via any protocols. Knowledge of 128.84.0.0 is not sent anywhere. Net 10.0.0.0 will not be announced via HELLO to any interface. This also implies that net 10.0.0.0 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 mnumber

This is a default EGP metric to use when there are 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 cause any EGP advertised route of this nature to be ignored. When there are no routing restrictions, any network with a direct interface is announced via EGP with a metric of 0. Note that this does not include subnets, but only the non-subnetted network.

defaultgateway gateway { rip| hello| egp} [ metric mnumber] { active| passive}

This default gateway gateway is installed in the kernel routing tables during initialization and reinstalled whenever information about the default route is lost. This route is installed with the time delay equivalent of a RIP metric of 15 unless another metric is specified with the metric option.

If either RIP gateway number or HELLO gateway number is specified, this default route is deleted when successfully peering with an EGP neighbor not specified for nogendefault.

Any other default route learned via another routing protocol will override an active default route. A default route learned via another routing protocol with a lower metric will override a passive default route.

An active default route will not be propagated in routing updates; a passive default route will be propagated.

The gateway should be an address in dot notation. The number mnumber following metric should be a time delay from zero to 30000. If the metric option is not specified, the equivalent time delay to a RIP metric of 15 is used.

The field rip, hello or egp must be specified, although it is only included for consistency of syntax.

net netaddr gateway addr metric hopcount { rip| egp| hello}
host hostaddr gateway addr metric hopcount { rip| egp| hello}

The above clauses install a static route to net netaddr or host hostaddr through gateway addr at a metric of hopcount 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 if the route is to be announced 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 given in the defaultegpmetric clause. If the protocol is egp and there are no routing restrictions, then this route will be announced by EGP with a metric of hopcount.

egpnetsreachable 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, individual unique EGP metrics cannot be set for each net. The defaultegpmetric is used for all networks except those that are directly connected, which use a metric of 0.

martiannets net [ net ] ...

This clause appends to gated´s list of martiannets networks. The martiannets networks are those known to be invalid and should be ignored. When gated hears about one of these networks through any means, it will immediately ignore it. If external tracing is enabled, a message will be printed to the trace log. Multiple occurrences of the martiannets clause accumulate.

An initial list of martian networks is coded into gated. This list contains 127.0.0.0, 128.0.0.0, 191.253.0.0, 192.0.0.0, 223.255.255.0, and 224.0.0.0.

Configuration File Options For Autonomous System Routing

In the internal routing tables, gated maintains the autonomous system number from which each route was learned. Autonomous systems are used only when an exterior routing protocol is in use -- in this case, EGP. Routes are tagged with the autonomous system number of the EGP peer from which they were learned. Routes learned via the interior routing protocols, RIP and HELLO, are tagged with the autonomous system number specified in the autonomoussystem clause.

gated normally does not propagate routes learned from exterior routing protocols to interior routing protocols. Historically this is because of the ARPANET core EGP speakers, which do not have adequate validation of routing information they receive. Some of the following clauses allow exterior routes to be propagated via interior protocols. Therefore, be extremely careful when allowing the propagation of exterior routes. If you are in doubt about the use of these clauses, DO NOT use them.

The following clauses provide limited control over routing based on autonomous system number.

validAS net AS as metric mnumber

The validAS clause is used for validation of networks from certain AS. When an EGP update is received from a neighbor that has the validate option specified on the associated egpneighbor clause, a validAS clause is searched for specifying that network and the autonomous system number of the EGP neighbor. If the appropriate validAS clause is located, the network is considered for addition to the routing table with the specified metric. If a validAS clause is not located, a warning message is printed and the network is ignored.

A network can be specified in several validAS clauses as being associated with several different autonomous systems.

announcetoAS asn0 { restrict| norestrict} ASlist asn1 [asn2] ...
noannouncetoAS asn0 { restrict| norestrict} ASlist asn1 [asn2] ...

announcetoAS and noannouncetoAS control the exchanging of routing information between different autonomous systems. Normally gated will not propagate routing information between autonomous systems. The exception to this occurs when routes learned from gated´s own autonomous system via RIP and HELLO are propagated via EGP. These clauses allow information learned via EGP from one autonomous system to be propagated via EGP to another autonomous system, or via RIP and HELLO to gated’s own autonomous system.

When the announcetoAS clause is specified, information learned via EGP from autonomous systems asn1, asn2,... is propagated to autonomous system asn0. If gated´s own autonomous system, as specified in the autonomoussystem clause, is specified as asn0, this information will be propagated via RIP and HELLO. Routing information from autonomous systems not specified in the ASlist list will not be propagated to autonomous system asn0.

If the noannouncetoAS clause is specified, information learned via EGP from all autonomous systems except asn1, asn2 ... is propagated to autonomous systems asn0. If gated´s own autonomous system is specified as asn0, this information will not be propagated via RIP and HELLO.

The restrict and norestrict option controls the application of announce and noannounce clauses to the propagation of routes to different autonomous systems. If restrict is specified, normal announcement restrictions apply. If norestrict is specified, announcement restrictions are not considered, and all routes from the source autonomous systems are propagated to the destination autonomous system.

Only one announcetoAS or noannounceAS clause can be specified per target autonomous system.

Notes On Configuration Options

gated stores its process ID in the file /etc/gated.pid.

If EGP is being used when supplying the default route (via RIP gateway or HELLO gateway ), and all EGP neighbors are lost, the default route will not be advertised until at least one EGP neighbor is regained.

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 backdoor 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. While routing restrictions take a little more maintenance time and are not the long term answer, we must use them for now to be good internet players.

Gated Internal Metrics

gated stores all metrics internally as a time delay in milliseconds to preserve the granularity of HELLO time delays. The internal delay ranges from 0 to 30000 milliseconds with 30000 representing infinity. Metrics from other protocols are translated to and from a time delay as they are received and transmitted. EGP distances are not comparable to HELLO and RIP metrics, but are stored as a time delay internally for comparison with other EGP metrics. The conversion factor between EGP distances and time delays is 100. RIP and interface metrics are translated to and from the internal time delays with the use of the following translation tables:

Time Delay			RIP metric	RIP metric	HELLO Delay
0	-	0	0	0	0
1	-	100	1	1	100
101	-	148	2	2	148
149	-	219	3	3	219
220	-	325	4	4	325
326	-	481	5	5	481
482	-	713	6	6	713
714	-	1057	7	7	1057
1058	-	1567	8	8	1567
1568	-	2322	9	9	2322
2323	-	3440	10	10	3440
3441	-	5097	11	11	5097
5098	-	7552	12	12	7552
7553	-	11190	13	13	11190
11191	-	16579	14	14	16579
16580	-	24564	15	15	24564
24565	-	30000	16	16	30000

Notes On Implementation Specifics

All protocols have a two-minute hold down. When a routing update indicates that the route in use is being deleted, gated will not delete the route for two minutes.

Changes can be made to the interfaces and gated will notice them without having to restart the process. If the netmask, subnetmask, broadcast address, or interface metric are changed, the interface should be marked down with ifconfig, then marked up at least thirty seconds later. Flag changes do not require the interface to be brought down and back up.

RIP propagates and listens to host routes. This was done to handle point-to-point links more consistently. This version also supports the RIP_TRACE commands.

Subnet interfaces are supported. Subnet information will only be propagated on interfaces to other subnets of the same network. For example, if there is a gateway between two class B networks, the subnet routes for each respective class B net are not propagated into the other class B net. Just the class B network number is propagated.

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 via a REDIRECT after six minutes. The route is then deleted from the kernel routing tables. This helps keep the routing tables more consistent. Any route that was learned via a REDIRECT is NOT announced by any routing protocol.

FILES

/etc/gated
The gated process itself.

/etc/gated.conf The configuration file.

/etc/gated.pid The process ID is stored here.

/etc/gated.version Gated version, build date, start data and pid.

/usr/tmp/gated_dump The memory dump file.

AUTHORS

Mark Fedor (1986-1987) at NYSERNet
Jeffrey C Honig, Cornell Theory Center

Hewlett-Packard Company — HP-UX Release 8.05: June 1991

Museum

Related Articles