ogated.conf(4) Kernel Interfaces Manual ogated.conf(4)
NAME
ogated.conf - Contains configuration information for the ogated daemon
SYNOPSIS
/etc/ogated.conf
DESCRIPTION
The /etc/ogated.conf file contains configuration information that is read by the ogated daemon at initialization time. This file contains
stanzas that control tracing options, select routing protocols, manage routing information, and manage independent system routing.
Stanzas can appear in any order in the ogated.conf file. The following sections describe the format of each stanza.
Controlling Trace Output
The option that controls trace output is read during the initialization of the ogated daemon and whenever the ogated daemon receives a
SIGHUP signal. This option is overridden at initialization time if trace flags are specified to the ogated daemon on the command line.
The traceflags stanza is in the following format; it tells the ogated daemon what level of trace output you want. traceflags Flag [Flag
Flag ...]
The valid flags for tracing are as follows: Logs all internal errors and interior routing errors Logs all external errors due to Exterior
Gateway Protocol (EGP), exterior routing errors, and EGP state changes Logs all routing changes Traces all EGP packets sent and received
Logs all routing updates sent Traces all Routing Information Protocol (RIP) packets received Traces all HELLO packets received Prints a
timestamp to the log file every 10 minutes Combines the internal, external, route, and egp flags Enables all of the listed trace flags
If more than one traceflags stanza is used, the trace flags specified in all stanzas are enabled.
Selecting Routing Protocols
This section explains the configuration options for routing protocols. These options provide the ogated daemon with instructions on how to
manage routing for each protocol.
All references to point-to-point interfaces in the ogated configuration file must use the address specified by the Destination parameter.
Using the ogated Daemon with the RIP Protocol
The following stanza tells the ogated daemon how to perform the RIP routing protocol. RIP Argument Only one of the following RIP Arguments
is allowed after the RIP keyword. Since only the first argument is recognized if more than one is specified, choose the argument that
describes the type of RIP routing you need. A list of the arguments to the RIP stanza follows: Performs the RIP protocol, processing all
incoming RIP packets and supplying RIP information every 30 seconds only if there are two or more network interfaces. Specifies that the
RIP protocol not be performed. Performs the RIP protocol, processing all incoming RIP packets and forcing the supply of RIP information
every 30 seconds no matter how many network interfaces are present. Performs the RIP protocol, processing all incoming RIP packets and
forcing the supply of RIP information every 30 seconds no matter how many network interfaces are present. When this argument is specified,
RIP information is not sent out in a broadcast packet. The RIP information is sent directly to the gateways listed in the sourceripgateways
stanza. Processes all incoming RIP packets, but does not supply any RIP information no matter how many network interfaces are present.
Processes all incoming RIP packets, supplying RIP information every 30 seconds and announcing the default route (network 0.0.0.0) with a
metric specified by the HopCount variable. The metric should be specified in a value that represents a RIP hop count.
With this option set, all other default routes coming from other RIP gateways are ignored. The default route is only announced when
actively peering with at least one EGP neighbor and therefore should only be used when EGP is used.
If no RIP stanza is specified, RIP routing is not performed.
Using the ogated Daemon with the HELLO Protocol
The following stanza configures the Defense Communications Network Local Network Protocol (HELLO) routing protocol for the ogated daemon:
HELLO Argument The Argument variable parallels the RIP arguments, with some minor differences.
As with RIP, only one of the following HELLO Arguments is allowed after the HELLO keyword. Since only the first argument is recognized if
more than one is specified, choose the argument that describes the type of RIP routing you need.
A list of the arguments to the HELLO stanza follows: Performs the HELLO protocol, processing all incoming HELLO packets and supplying HELLO
information every 15 seconds only if there are two or more network interfaces. Specifies that this gateway does not perform the HELLO pro-
tocol. Performs the HELLO protocol, processing all incoming HELLO packets and forcing a supply of HELLO information every 15 seconds no
matter how many network interfaces are present. Performs the HELLO protocol, processing all incoming HELLO packets and forcing a supply of
HELLO information every 15 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 stanza. Processes all incoming HELLO packets, but does not supply any HELLO informa-
tion regardless of the number of network interfaces present. Processes all incoming HELLO packets, supplying HELLO information
every 15 seconds and announcing the default route (network 0.0.0.0) with a time delay specified by the MilliSeconds variable. The
time delay should be a numeric value specified in milliseconds.
The default route is only announced when actively peering with at least one EGP neighbor. Therefore, this stanza should only be used when
running EGP.
If no HELLO stanza is specified, HELLO routing is not performed.
Using the ogated Daemon with the EGP Protocol
The following stanzas specify the information necessary for the ogated daemon to use EGP. This stanza allows the processing of EGP by the
ogated daemon to be turned on or off. The arguments are interpreted as follows: Performs all EGP operations. Specifies that no EGP pro-
cessing should be performed.
Note that EGP processing takes place by default. If no EGP stanza is specified, all EGP operations take place. When the ogated
daemon performs the EGP protocol, this stanza must be used to specify the independent (autonomous) system number. If this number is
not specified, the ogated daemon exits immediately with an error message. When the ogated daemon performs the EGP protocol, this
stanza specifies the number of EGP peers with whom the ogated daemon performs EGP. The Number variable must be a value greater than
zero and less than or equal to the number of EGP neighbors specified, or the ogated daemon exits immediately. If this stanza is
omitted, all EGP neighbors are acquired.
When the ogated daemon performs the EGP protocol, this stanza specifies with whom the ogated daemon is to perform EGP. The gateway speci-
fied by the Gateway variable can be either a host address in Internet dotted-decimal notation or a symbolic name from the /etc/hosts file.
Each EGP neighbor should have its own egpneighbor stanza and is acquired in the order listed in the ogated.conf file.
The arguments to the egpmaxacquireNumber stanza have the following definitions: Specifies the internal time delay to be used as a metric
for all of the routes learned from this neighbor. The Delay variable should be specified as a time delay from 0 to 30,000. If this keyword
and the validate keyword are not used, the internal metric used is the EGP distance multiplied by 100. Sets the EGP distance used for all
networks advertised to this neighbor. The EGPMetric variable should be specified as an EGP distance in the range of 0 to 255. If this key-
word is not specified, the internal time delay for each route is converted to an EGP distance divided by 100, with distances greater than
255 being set to 255. Verifies the autonomous system number of this neighbor. If the AutonomousSystem number specified in neighbor acqui-
sition packets does not verify, an error message is generated refusing the connection. If this keyword is not specified, no verification of
autonomous system numbers is done. Specifies the autonomous system number in EGP packets sent to this neighbor. If an ASout stanza is not
specified, the AutonomousSystem number specified in the autonomoussystem stanza is used. This stanza is reserved for a special situation
that occurs between the ARPANET network and National Science Foundation (NSF) networks, and is not normally used. Specifies that this
neighbor should not be considered for the internal generation of a default when the RIP gateway or the HELLO gateway argument is used. If
not specified, the internal default is generated when actively peering with this neighbor. Indicates that the default route (network
0.0.0.0) should be considered valid when received from this neighbor. If this keyword is not specified, on reception of the default route,
the ogated daemon displays a warning message and ignores the route. Specifies that the internally generated default may 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 is not propagated to an EGP neighbor.
Without this keyword, no default route is passed through EGP. The acceptdefault keyword should not be specified when the defaultout
keyword is used. The EGP metric specified in the egpmetricout keyword does not apply when the defaultout keyword is used. The
default route always uses the metric specified by the defaultout keyword. Specifies that all networks received from this EGP neigh-
bor must be defined in a validAS stanza that also specifies the autonomous system of this neighbor. Networks without a validAS
stanza are ignored after a warning message is printed. Defines the interface used to send EGP packets to this neighbor. This key-
word is only used when there is no common net or subnet with this EGP neighbor. This keyword is present for testing purposes and
does not imply correct operation when peering with an EGP neighbor that does not share a common net or subnet. Specifies the source
network to be used in EGP poll packets sent to this neighbor. If this keyword is not specified, the network (not subnet) of the
interface used to communicate with this neighbor is used. This keyword is present for testing purposes and does not imply correct
operation when used.
Managing Routing Information
The following configuration file stanzas determine how the ogated daemon handles both incoming and outgoing routing information.
Specifying RIP or HELLO Gateways to Which the ogated Daemon Listens
When the following stanzas are specified, the ogated daemon only listens to RIP or HELLO information, respectively, from these RIP or HELLO
gateways: trustedripgateways Gateway [Gateway Gateway ...] trustedhellogateways Gateway [Gateway Gateway ...]
The Gateway variable may be either an Internet address in dotted-decimal notation, which avoids confusion, or a symbolic name from the
/etc/hosts file. Note that the propagation of routing information is not restricted by this stanza.
Specifying Gateways for the ogated Daemon to Send RIP or HELLO Information
With the following stanzas, the ogated daemon sends RIP or HELLO information directly to the gateways specified: sourceripgateways Gateway
[Gateway Gateway ...] sourcehellogateways Gateway [Gateway Gateway ...]
If the pointopoint argument is specified in the RIP or HELLO stanzas defined earlier, the ogated daemon sends only RIP or HELLO information
to the specified gateways and does not send out any information using the broadcast address.
If the pointopoint argument is not specified in those stanzas and the ogated daemon is supplying RIP or HELLO information, the ogated dae-
mon sends information to the specified gateways and also broadcasts information using a broadcast address.
Turning Routing Protocols On and Off by Interface
The following stanzas turn routing protocols on and off by interface: noripoutinterface InterfaceAddress
[InterfaceAddressInterfaceAddress ...] nohellooutinterface InterfaceAddress
[InterfaceAddressInterfaceAddress ...] noripfrominterface InterfaceAddress
[InterfaceAddressInterfaceAddress ...] nohellofrominterface InterfaceAddress
[InterfaceAddressInterfaceAddress ...]
A noripfrominterface or nohellofrominterface stanza means that no RIP or HELLO information is accepted coming into the listed interfaces
from another gateway.
A noripoutinterface or nohellooutinterface stanza means that no RIP or HELLO knowledge is sent out of the listed interfaces. The Inter-
faceAddress variable should be an Internet address in dotted-decimal notation.
Stopping the ogated Daemon from Timing Out Interfaces
The following stanza stops the ogated daemon from timing out the interfaces whose addresses are listed in Internet dotted-decimal notation
by the InterfaceAddress arguments. These interfaces are always considered up and working. passiveinterfaces InterfaceAddress
[InterfaceAddressInterfaceAddress... ]
This stanza is used because the ogated daemon times out an interface when no RIP, HELLO, or EGP packets are being received on that particu-
lar interface, in order to dynamically determine if an interface is functioning properly.
Packet Switch Node (PSN) interfaces send a RIP or HELLO packet to themselves to determine if the interface is properly functioning, since
the delay between EGP packets may be longer than the interface time-out. Interfaces that have timed out automatically have their routes
reinstalled when routing information is again received over the interface.
If the ogated daemon is not a RIP or HELLO supplier, no interfaces are aged and the passiveinterfaces stanza automatically applies to all
interfaces.
Specifying an Interface Metric
The following stanza allows the specification of an interface metric for the listed interface: interfacemetric InterfaceAddress Metric
On systems that support interface metrics, this stanza overrides the kernel's metric. On systems that do not support an interface metric,
this feature allows one to be specified.
The interface metric is added to the true metric of each route that comes in with routing information from the listed interface. The
interface metric is also added to the true metric of any information sent out through the listed interface. The metric of directly attached
interfaces is also set to the interface metric, and routing information broadcast about directly attached networks is based on the inter-
face metric specified.
The interfacemetric stanza is required for each interface on which an interface metric is desired.
Providing Hooks for Fallback Routing
The following stanza provides hooks for fallback routing in the ogated daemon: reconstmetric InterfaceAddress Metric
If this stanza is used, the metrics of the routes contained in any RIP information coming into the listed interface are set to the metric
specified by the Metric variable. Metric reconstitution should be used carefully, since it could be a major contributor in the formation of
routing loops. Any route that has a metric of infinity is not reconstituted and is left as infinity.
Note that the reconstmetric stanza should be used with extreme caution.
The following stanza also provides hooks for fallback routing for the ogated daemon: fixedmetric InterfaceAddress Protocol rip | hello Met-
ric
If this stanza is used, all routing information sent out by the specified interface has a metric specified by the Metric variable. For
RIP, specify the metric as a RIP hop count from 0 to infinity. For HELLO, specify the metric as a HELLO delay in milliseconds from 0 to
infinity. Any route that has a metric of infinity is left as infinity.
Note that fixed metrics should be used with extreme caution.
Specifying Information to Be Ignored
The following stanza indicates that any information regarding the Network variable that comes in by means of the specified protocols and
from the specified interfaces is ignored: donotlisten Network intf Address [Address... ] proto rip | hello donotlistenhost Host intf
Address [Address... ] proto rip | hello
The donotlisten stanza contains the following information: the keyword donotlisten, followed by a network number specified by the Network
variable, which should be in dotted-decimal notation, followed by the intf keyword. Next is a list of interfaces in dotted-decimal nota-
tion, then the proto keyword, followed by the rip or hello keyword.
The all keyword can be used after the intf keyword to specify all interfaces on the system. For example: donotlisten 10.0.0.0 intf
128.84.253.200 proto rip
means that any RIP information about network 10.0.0.0 coming in by interface 128.84.253.200 will be ignored. One stanza is required for
each network on which this restriction is desired. In addition: donotlisten 26.0.0.0 intf all proto rip hello
means that any RIP and HELLO information about network 26.0.0.0 coming in through any interface is ignored.
The donotlistenhost stanza is defined in the same way, except that a host address is provided instead of a network address. Restrictions
on routing updates are applied to the specified host route learned through the specified routing or protocols.
Specifying Network or Host Information to Which the ogated Daemon Listens
The following stanzas indicate that the ogated daemon should listen to specified protocols and gateways: listen Network gateway Address
[Address... ] proto rip | hello listenhost Host gateway Address [Address... ] proto rip | hello
The listen and listenhost stanzas specify to listen only to information about a network or host on the specified protocol or protocols and
from the listed gateways.
These stanzas read as follows: the listen or listenhost keyword is followed by a network or host address, respectively, in dotted-decimal
notation. Next is the gateway keyword with a list of gateways in dotted-decimal notation, and then the proto keyword followed by the rip
or hello keyword. For example: listen 128.84.0.0 gateway 128.84.253.3 proto hello
indicates that any HELLO information about network 128.84 that comes in through gateway 128.84.253.3 is accepted. Any other information
about network 128.84 from any other gateway is rejected. One stanza is needed for each net to be restricted.
Also, the stanza: listenhost 26.0.0.15 gateway 128.84.253.3 proto rip
means that any information about host 26.0.0.15 must come through RIP from gateway 128.84.253.3. All other information regarding this host
is ignored.
Restricting Announcements of Networks and Hosts
The following stanzas allow restriction of the networks and hosts that are announced and the protocols that announce them: announce Network
InterfaceAddress [Address... ]
Protocol Type [EGPMetric] announcehost Host InterfaceAddress Protocol
Type [EGPMetric] noannounce Network InterfaceAddress [Address . . . ]
Protocol Type [EGPMetric] noannouncehost Host InterfaceAddress Protocol
Type [EGPMetric]
The announce{host} and noannounce{host} stanzas cannot be used together on the same interface. With the announce{host} stanza, the ogated
daemon only announces the networks or hosts that have an associated announce or announcehost stanza with the appropriate protocol.
With the noannounce{host} stanza, the ogated daemon announces everything, except those networks or hosts that have an associated noannounce
or noannouncehost stanza. These stanzas provide a choice of announcing only what is on the announce list or everything, except those net-
works on the noannounce list on an individual basis.
The arguments are the same as in the donotlisten stanza, except that egp may be specified in the Proto field. The Type can be rip, hello,
egp, or any combination of the three. When egp is specified in the Proto field, an EGP metric must be specified. This is the metric at
which the ogated daemon announces the listed network through EGP.
Note that these are not static route entries. These restrictions only apply if the network or host is learned through one of the routing
protocols. If a restricted network suddenly becomes unreachable and goes away, announcement of this network stops until it is learned
again.
Only one announce{host} or noannounce{host} stanza may be specified for each network or host. A network or host cannot, for instance, be
announced through HELLO for one interface and through RIP for another.
Some sample announce stanzas might include: 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 stanzas in the configuration file, the ogated process only announces these four networks. Network .84.0.0 is
announced through RIP and HELLO to all interfaces and through EGP with a metric of 0 (zero). Network .0.0.0 is announced through RIP to
all interfaces.
Network 0.0.0.0 (default) is announced by RIP through interface 128.84.253.200 only. Network 35.0.0.0 is announced through RIP to all
interfaces and announced through EGP with a metric of 3. These are the only networks that are broadcast by this gateway.
Once the first announce stanza is specified, only the networks with announce stanzas are broadcast, including local subnetworks. Once an
announce{host} or noannounce{host} stanza has an all keyword specified after an intf keyword, that stanza is applied globally and the
option of having individual interface restrictions is lost.
If no routing announcement restrictions are desired, announce stanzas should not be used. All information learned is then propagated out.
That announcement has no affect on the information to which the ogated daemon listens.
Any network that does not have an announce stanza is still added to the kernel routing tables, but it is not announced through any of the
routing protocols. To stop networks from being added to the kernel, the donotlisten stanza may be used.
As another example: announce 128.84 intf 128.59.2.1 proto rip noannounce 128.84 intf 128.59.1.1 proto rip
indicates that on interface 128.59.2.1, only information about network 128.84.0.0 is announced through RIP, but on interface 128.59.1.1,
all information is announced, except 128.84.0.0 through RIP.
The stanzas: noannounce 128.84 intf all proto rip hello egp egpmetric 0 noannounce 10.0.0.0 intf all proto hello
mean that except for the two specified networks, all networks are propagated. Specifically, network 128.84.0.0 is not announced on any
interface through any protocols. Knowledge of network 128.84.0.0 is not sent anywhere. Network 10.0.0.0 is not announced through HELLO to
any interface.
The second stanza also implies that network 10.0.0.0 is announced to every interface through RIP. This network is also broadcast through
EGP with the metric specified in the defaultegpmetric stanza.
Defining a Default EGP Metric
The following stanza defines a default EGP metric to use when there are no routing restrictions: defaultegpmetric Number Without routing
restrictions, the ogated daemon announces all networks learned through HELLO or RIP through EGP with this specified default EGP metric. If
this stanza is not used, the default EGP metric is set to 255, which causes any EGP advertised route of this nature to be ignored.
When there are no routing restrictions, any network with a direct interface is announced through EGP with a metric of 0 (zero). Note that
this does not include subnetworks, but only the nonsubnetworked network.
Defining a Default Gateway
The following stanza defines a default gateway, which is installed in the kernel routing tables during initialization and reinstalled when-
ever information about the default route is lost:
defaultgateway Gateway [Metric] Protocol
[active | passive]
This route is installed with a time delay equivalent to a RIP metric of 15, unless another metric is specified with the Metric variable.
If the RIP gateway or HELLO gateway is in use, this default route is deleted.
An active default route is overridden by any other default route learned through another routing protocol. A passive default route is only
overridden by a default route with a lower metric. In addition, an active default route is not propagated in routing updates, while a pas-
sive default route is propagated.
The gateway specified by the Gateway variable should be an address in Internet dotted-decimal notation. The Metric variable is optional
and should be a time delay from 0 to 30,000. If a Metric is not specified, a time delay equivalent to a RIP metric of 15 is used.
The Protocol variable should be either rip, egp, or hello. The Protocol variable initializes the protocol by which the route was learned.
In this case the Protocol variable is unused but remains for consistency.
Installing a Static Route
The following stanzas install static routes: net NetworkAddress gateway Address metric HopCount rip | egp | hello host HostAddress gateway
Address metricHopCount rip | egp | hello
The net and host stanzas install a static route to the network specified by the NetworkAddress variable or the host specified by the
HostAddress variable. The route is through a gateway specified by the Address variable at a metric specified by the HopCount variable
learned through RIP, HELLO, or EGP. Again, dotted-decimal notation should be used for the addresses. These routes are installed in the
kernel's routing table and are never affected by any other gateway's RIP or HELLO announcements. The protocol by which they were learned
is important if the route is to be announced through EGP.
If the protocol is RIP or HELLO and there are no routing restrictions, then this route is announced by EGP with a metric of defaultegpmet-
ric. If the protocol keyword is egp and there are no routing restrictions, then this route is announced by EGP with a metric specified by
the HopCount variable.
Restricting EGP Announcements
The following stanza provides a soft restriction to the ogated daemon: egpnetsreachable Network [Network Network . . . ]
It cannot be used when the announce or noannounce stanzas are used. With no restrictions, the ogated daemon announces all routes learned
from RIP and HELLO through EGP. The egpnetsreachable stanza restricts EGP announcement to those networks listed in the stanza.
The metric used for routes learned through HELLO and RIP is the value given in the defaultegpmetric stanza. If this stanza does not spec-
ify a value, the value is set to 255. With the egpnetsreachable stanza, unique EGP metrics cannot be set for each network. The default-
egpmetric is used for all networks, except those that are directly connected, which use a metric of 0 (zero).
Specifying Invalid Networks
The following stanza appends to the ogated daemon's list of martian networks, which are those that are known to be invalid and should be
ignored: martiannets Network [Network Network . . . ]
When the ogated daemon receives information about one of these networks through any means, it immediately ignores it. If external tracing
is enabled, a message is printed to the trace log. Multiple occurrences of the martiannets stanza accumulate.
The initial list of martian networks provided by the ogated daemon contains the following networks: 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.
Managing Autonomous System Routing
In the internal routing tables, the ogated daemon maintains the autonomous system number from which each route was learned. Independent
(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 through the interior
routing protocols, RIP and HELLO, are tagged with the autonomous system number specified in the autonomoussystem stanza of the ogated.conf
file.
The ogated server does not normally propagate routes learned from exterior routing protocols to interior routing protocols, since some
gateways do not have adequate validation of routing information they receive. Some of the following stanzas allow exterior routes to be
propagated through interior protocols. Therefore, it is imperative that utmost care be taken when allowing the propagation of exterior
routes.
The following stanzas provide limited control over routing based on autonomous system numbers.
Validating Networks from an Independent (Autonomous) System
The following stanza is used for validation of networks from a certain independent system: validAS Network AS System metric Number
When an EGP update is received from a neighbor that has the validate keyword specified in the associated egpneighbor stanza, a search is
made for a validAS stanza that defines the network and the autonomous system number of the EGP neighbor.
If the appropriate validAS stanza is located, the network is considered for addition to the routing table with the specified metric. If a
validAS stanza is not located, a warning message is printed and the network is ignored.
A network may be specified in several validAS stanzas as being associated with several different autonomous systems.
Controlling Exchange of Routing Information Between Autonomous Systems
The following stanzas control routing information exchange: announcetoAS AutonomousSystem1 ASlist AutonomousSystem2
[AutonomousSystem3... ] noannouncetoAS AutonomousSystem1 ASlist AutonomousSystem2
[AutonomousSystem3... ]
The announcetoAS and noannouncetoAS stanzas control the exchange of routing information between different autonomous (independent) systems.
Normally, the ogated daemon does not propagate routing information between independent systems.
The exception to this is that routes learned from the ogated daemon's own independent system through RIP and HELLO are propagated through
EGP. These stanzas allow information learned through EGP from one autonomous system to be propagated through EGP to another autonomous sys-
tem or through RIP and HELLO to the ogated daemon's own autonomous system.
If the announcetoAS stanza is specified, information learned through EGP from autonomous systems AS1, AS2, AS3, and so on, is propagated to
autonomous system AS0. If the ogated daemon's own autonomous system, as specified in the autonomoussystem stanza, is specified as AS0,
this information is propagated through RIP and HELLO. Routing information from autonomous systems not specified in the ASlist are not
propagated to autonomous system AS0.
If the noannouncetoAS stanza is specified, information learned through EGP from all autonomous systems, except AS1, AS2, AS3, and so on, is
propagated to autonomous system AS0. If the ogated daemon's own autonomous system is specified as AS0, this information is not propagated
through RIP and HELLO.
Only one announcetoAS or noannounceAS stanza may be specified for each target autonomous system.
EXAMPLES
An example ogated.conf file for a ogated server that performs only EGP routing might contain the following entries. The following three
lines specify which protocol will be running. RIP and HELLO do not run. EGP does run. RIP no HELLO no EGP yes #
The traceflags stanza tells what level of trace output is desired: Logs all internal error and interior routing errors. Logs all external
errors due to EGP, exterior routing errors, and EGP state changes. Logs all routing changes. Traces all EGP packets sent and received.
Logs all routing updates.
The autonomous system stanza specifies the autonomous system number. This must be specified if running EGP. traceflags internal
external route egp update autonomoussystem 178
The following egpneighbor stanza specifies with whom you are going to perform EGP. This line says that your EGP neighbor is the host
192.100.9.1. The defaultegpmetric stanza specifies that when there are no routing restrictions, the default EGP metric is 132. egpneigh-
bor 192.100.9.1 defaultegpmetric 132 #
The next line indicates that for network 192.200.9 the gateway is 192.101.9.3 with a hop count of 50 when using RIP protocol. This is a
static route.
The egpnetsreachable stanza restricts EGP announcements to those networks listed: net 192.200.9 gateway 192.101.9.3 metric 50 rip egpnet-
sreachable 192.200.9 192.101.9
The following lists the static routes, showing the host address, gateway address, hop count, and protocol used: # Static routes host
129.140.46.1 gateway 192.100.9.1 metric 5 rip host 192.102.9.2 gateway 192.100.9.1 metric 5 rip host 192.104.9.2
gateway 192.100.9.1 metric 5 rip host 149.140.3.12 gateway 192.100.9.1 metric 5 rip host 129.140.3.12 gateway 192.100.9.1
metric 5 rip host 129.140.3.13 gateway 192.100.9.1 metric 5 rip host 129.140.3.14 gateway 192.100.9.1 metric 5 rip host
192.3.3.54 gateway 192.101.9.3 metric 5 rip
RELATED INFORMATION
Daemons: ogated(8) delim off
ogated.conf(4)