unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



ogated.conf(4)						       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 speci-
  fied to the ogated daemon on the command line.

  The traceflags stanza	is in the following format; it tells the ogated	dae-
  mon 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), exte-
      rior 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 sup-
      plying 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 informa-
      tion is sent directly to the gateways listed in the sourceripgateways
      stanza.

  quiet
      Processes	all incoming RIP packets, but does not supply any RIP infor-
      mation 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 speci-
      fied in a	value that represents a	RIP hop	count.

  With this option set,	all other default routes coming	from other RIP gate-
  ways 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 differ-
  ences.

  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 gate-
      ways 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 /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 defini-
  tions:

  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 speci-
      fied 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 mul-
      tiplied by 100.

  egpmetricout EGPMetric
      Sets the EGP distance used for all networks advertised to	this neigh-
      bor. 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 Auto-
      nomousSystem 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 net-
      work and National	Science	Foundation (NSF) networks, and is not nor-
      mally 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	argu-
      ment 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 speci-
      fied, 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 speci-
      fied 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	key-
      word 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	sub-
      net) 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 informa-
  tion 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 inter-
  face,	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. Inter-
  faces	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 dae-
  mon:

       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 speci-
  fied by the Metric variable. Metric reconstitution should be used care-
  fully, 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 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 vari-
  able,	which should be	in dotted-decimal notation, followed by	the intf key-
  word.	 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 inter-
  faces	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 inter-
  face 128.84.253.200 will be ignored.	One stanza is required for each	net-
  work 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 speci-
  fied 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	nota-
  tion,	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 net-
  work 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 announ-
  cehost 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 noan-
  nouncehost stanza. These stanzas provide a choice of announcing only what
  is on	the announce list or everything, except	those networks on the noan-
  nounce 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	dae-
  mon 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 proto-
  cols.	 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 pro-
  pagated.  Specifically, network 128.84.0.0 is	not announced on any inter-
  face 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 inter-
  face.

  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 infor-
  mation 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 overrid-
  den 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 vari-
  able.	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 announce-
  ment 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 net-
  works, 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	pro-
  tocols, RIP and HELLO, are tagged with the autonomous	system number speci-
  fied 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 auto-
  nomous 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 key-
  word 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 indepen-
  dent 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 auto-
  nomous system	AS0.  If the ogated daemon's own autonomous system, as speci-
  fied 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 tar-
  get 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	per-
  form 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 res-
  trictions, 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

RELATED	INFORMATION

  Daemons: ogated(8)