ogated.conf(4)ogated.conf(4)NAMEogated.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 key‐
word. 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. Per‐
forms the RIP protocol, processing all incoming RIP packets and forcing
the supply of RIP information every 30 seconds no matter how many net‐
work 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 inter‐
faces 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 dif‐
ferences.
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
protocol. 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 inter‐
faces 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 sup‐
ply any HELLO information regardless of the number of network
interfaces present. Processes all incoming HELLO packets, sup‐
plying 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 run‐
ning 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 processing
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 immedi‐
ately 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 specified
by the Gateway variable can be either a host address in Internet dot‐
ted-decimal notation or a symbolic name from the<filename>
/etc/hosts</filename> 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 def‐
initions: 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 dis‐
tance 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 keyword 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 acquisition 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) net‐
works, 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 speci‐
fied, 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 neighbor 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 keyword 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 peer‐
ing 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 dae‐
mon 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 lis‐
tens to RIP or HELLO information, respectively, from these RIP or HELLO
gateways: trustedripgateways Gateway [Gateway Gateway ...] trustedhel‐
logateways Gateway [Gateway Gateway ...]
The Gateway variable may be either an Internet address in dotted-deci‐
mal 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 Informa‐
tion
With the following stanzas, the ogated daemon sends RIP or HELLO infor‐
mation 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 daemon
sends information to the specified gateways and also broadcasts infor‐
mation 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 ...] nohel‐
looutinterface 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 InterfaceAd‐
dress variable should be an Internet address in dotted-decimal nota‐
tion.
Stopping the ogated Daemon from Timing Out Interfaces
The following stanza stops the ogated daemon from timing out the inter‐
faces 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 them‐
selves 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 rein‐
stalled 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 inter‐
face 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 interface
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 reconsti‐
tuted 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 Metric
If this stanza is used, all routing information sent out by the speci‐
fied 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 Net‐
work variable that comes in by means of the specified protocolsand 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 notation,
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 Lis‐
tens
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 fol‐
lowed by a network or host address, respectively, in dotted-decimal
notation. Next is the gateway keyword with a list of gateways in dot‐
ted-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 Inter‐
faceAddress [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 dae‐
mon 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 every‐
thing, except those networks or hosts that have an associated noan‐
nounce or noannouncehost stanza. These stanzas provide a choice of
announcing only what is on the announce list or everything, except
those networks 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 pro‐
tocols. 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 is
announced through RIP and HELLO to all interfaces and through EGP with
a metric of 0 (zero). Network is announced through RIP to all inter‐
faces.
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} ornoannounce{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 rout‐
ing 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 noan‐
nounce 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 prop‐
agated. 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 Gate‐
way [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 Proto‐
col variable initializes the protocol by which the route was learned.
In this case the Protocol variable is unused but remains for consis‐
tency.
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 speci‐
fied 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 impor‐
tant 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 defaultegpmetric.
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 Hop‐
Count 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 specify
a value, the value is set to 255. With the egpnetsreachable stanza,
unique EGP metrics cannot be set for each network. The defaultegpmetric
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 con‐
tains 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 autono‐
mous system number from which each route was learned. Independent (au‐
tonomous) 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 exte‐
rior routing protocols to interior routing protocols, since some gate‐
ways 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 au‐
tonomous 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 val‐
idAS stanza is not located, a warning message is printed and the net‐
work is ignored.
A network may be specified in several validAS stanzas as being associ‐
ated with several different autonomous systems.
Controlling Exchange of Routing Information Between Autonomous Systems
The following stanzas control routing information exchange: announce‐
toAS AutonomousSystem1 ASlist AutonomousSystem2
[AutonomousSystem3... ] noan‐
nouncetoAS 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 au‐
tonomous system to be propagated through EGP to another autonomous sys‐
tem or through RIP and HELLO to the ogated daemon's own autonomous sys‐
tem.
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 autono‐
mous 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 exter‐
nal 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.
egpneighbor 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 net‐
works listed:
net 192.200.9 gateway 192.101.9.3 metric 50 rip egpnetsreachable
192.200.9 192.101.9
The following lists the static routes, showing the host address, gate‐
way 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
SEE ALSO
Daemons: ogated(8)ogated.conf(4)
