 |
Index for
Section 4 |
|
 |
Alphabetical
listing for O |
|
 |
Bottom of
page |
|
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:
internal
Logs all internal errors and interior routing errors
external
Logs all external errors due to Exterior Gateway Protocol (EGP),
exterior routing errors, and EGP state changes
route
Logs all routing changes
egp Traces all EGP packets sent and received
update
Logs all routing updates sent
rip Traces all Routing Information Protocol (RIP) packets received
hello
Traces all HELLO packets received
timestamp
Prints a timestamp to the log file every 10 minutes
general
Combines the internal, external,route, and egp flags
all 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:
yes 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.
no Specifies that the RIP protocol not be performed.
supplier
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.
pointopoint
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.
quiet
Processes all incoming RIP packets, but does not supply any RIP
information no matter how many network interfaces are present.
gateway HopCount
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:
yes 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.
no Specifies that this gateway does not perform the HELLO protocol.
supplier
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.
pointopoint
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.
quiet
Processes all incoming HELLO packets, but does not supply any HELLO
information regardless of the number of network interfaces present.
gateway MilliSeconds
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.
EGP yes | no
This stanza allows the processing of EGP by the ogated daemon to be
turned on or off. The arguments are interpreted as follows:
yes Performs all EGP operations.
no 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.
autonomous system
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.
egpmaxacquire Number
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 dotted-
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
definitions:
metricin Delay
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.
egpmetricout EGPMetric
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.
ASin AutonomousSystem
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.
ASout AutonomousSystem
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.
nogendefault
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.
acceptdefault
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.
defaultout EGPMetric
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.
validate
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.
intf Interface
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 peering with an EGP neighbor that does not
share a common net or subnet.
sourcenet Network
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 daemon
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 InterfaceAddress
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 particular
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 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 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 Metric
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 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 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 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
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} 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 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 whenever
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 passive 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 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 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 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 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 system 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:
internal
Logs all internal error and interior routing errors.
external
Logs all external errors due to EGP, exterior routing errors, and EGP
state changes.
route
Logs all routing changes.
egp Traces all EGP packets sent and received.
update
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.
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 networks
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, 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
SEE ALSO
Daemons: ogated(8)
|
Index for
Section 4 |
|
|
Alphabetical
listing for O |
|
 |
Top of
page |
|