Switch to SpeakEasy.net DSL

The Modular Manual Browser

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

gated.conf(4)							gated.conf(4)


  gated.conf - Gate daemon configuration file (general information)


  The gated.conf file contains configuration information that is read by the
  gated	daemon at initialization time.	This file contains statements that
  control tracing options, select routing protocols, manage routing informa-
  tion,	and manage independent system routing.

  The /etc/gated.conf file is defined as a Context-Dependent Symbolic Link
  (CDSL), and must be maintained as such.  See the System Administration
  manual for more information.

  The gated.conf file consists of a sequence of	statements terminated by a
  semi-colon (;).  Statements are composed of tokens separated by any combi-
  nation of blanks, tabs, and newlines.	 This structure	simplifies identifi-
  cation of the	parts of the configuration associated with each	other and
  with specific	protocols.  Comments can be specified by either	of the fol-

    +  A number	sign (#)

    +  The C-style /* and */ characters.

  Syntax description conventions

  Keywords and special characters that the parser expects are displayed	using
  the HTML strong style.  Parameters are specified in the HTML variable
  definition style.  Parameters	shown in brackets ([]) show optional keywords
  and parameters.  The vertical	bar (|)	indicates a choice of optional param-
  eters.  Parentheses (()) group keywords and parameters, when necessary.
  For example:

  [backbone | (area area)]

  In this example, the brackets	indicate that either parameter is optional.
  The keywords are backbone and	area.  The vertical bar	indicates that either
  backbone or area area	can be specified.  Because area	is in the variable
  definition0 style, it	is a parameter that needs to be	provided.

  Statement Grouping

  The configuration statements and the order in	which they must	appear in the
  gated.conf file are as follows:

    +  options statements

    +  interface statements

    +  definition statements

    +  protocol	statements

    +  static statements

    +  control statements

    +  aggregate statements

  Entering a statement out of order causes an error when parsing the confi-
  guration file.

  Two other types of statements	do not fit in these categories:	%directive
  statements and %trace	statements.  These statements provide instructions to
  the parser and control tracing from the configuration	file.  They do not
  relate to the	configuration of any protocol and may occur anywhere in	the
  gated.conf file.

  Configuration	Statement Summary

  The following	table lists each gated.conf configuration statement by name,
  identifies the statement type, and gives a synopsis of the statement's

  Name		     Type	  Synopsis
  %directory	     directive	  Sets the directory for include files.
  %include	     directive	  Includes a file into gated.conf.
  traceoptions	     trace	  Specifies which events are traced.
  options	     definition	  Defines gated	options.
  interfaces	     definition	  Defines gated	interfaces.
  autonomoussystem   definition	  Defines the AS number.
  routerid	     definition	  Defines the originating router (BGP, OSPF).
  martians	     definition	  Defines invalid destination addresses.
  rip		     protocol	  Enables the RIP protocol.
  isis		     protocol	  Enables the ISIS protocol.
  kernel	     protocol	  Configures kernel interface options.
  ospf		     protocol	  Enables the OSPF protocol.
  egp		     protocol	  Enables the EGP protocol.
  bgp		     protocol	  Enables the BGP protocol.
  redirect	     protocol	  Configures the processing of ICMP redirects.
  icmp		     protocol	  Configures the processing of general ICMP packets.
  snmp		     protocol	  Enables reporting to SNMP.
  pim		     protocol	  Enables PIM protocol.
  dvrmp		     protocol	  Enables DVRMP	protocol.
  msdp		     protocol	  Enables MSDP protocol.
  static	     static	  Defines static routes.
  import	     control	  Defines which	routes to import.
  export	     control	  Defines which	routes to export.
  aggregate	     control	  Defines which	routes to aggregate.
  generate	     control	  Defines which	routes to generate.

Routing	and Preferences

  The gated.conf files can define routes from one protocol or peer to
  another, assigning each route	a value	called a preference.

  The preference value determines the order of routes to the same destination
  in a single routing database.	 The active route is chosen by the lowest
  preference value.

  Some protocols implement a second preference (preference2), sometimes
  referred to as a tie breaker.

  Use the following guidelines when setting preferences:

	    It can be set in several different configuration statements	in
	    gated.conf,	although the last or most specific value set for a
	    route is the one used. (See	gated_intro(7).)

	    It can be specify one network interface over another, one proto-
	    col	over another, or one remote gateway over another.

	    It cannot be used to control the selection of routes within	an
	    interior gateway protocol (IGP).  That function is accomplished
	    automatically by the protocol based	on metric.

	    It can be used to select routes from the same exterior gateway
	    protocol (EGP) learned from	different peers	or autonomous sys-

  Selecting a Route

  The gated daemon uses	the following criteria to select a route:

    +  The route with the best (numerically smallest) preference, as defined
       in the gated.conf file, is preferred.

    +  If the two routes have the same preference, the route with the best
       (numerically smallest) preference2 (also	known as a tie breaker)	is

    +  If autonomous system (AS) path information is available it is used to
       help determine the most preferred route as follows:

	 -- A route with an AS path is preferred over one without and AS

	 -- If the AS paths and	origins	are identical, the route with the
	    lower metric is preferred.

	 -- A route with an AS path origin of IGP is preferred over a route
	    with an AS path origin of EGP.  The	least preferred	is an AS path
	    with an unknown origin.

	 -- A route with a shorter AS path is preferred.

    +  A route with the	lowest Multi-Exit Discriminator	(MED)is	preferred.
       MEDs are	only compared between routes that were received	from the same
       neighbor	AS. (This test is only applied if the local AS has two or
       more connections	to a given neighbor AS.)

    +  A route learned from an IGP is preferred	to a route learned from	an
       EGP.  The least preferred is a route learned indirectly by an IGP from
       an EGP.

    +  The route with the lowest numeric next-hop address is used.

    +  If both routes are from the same	protocol and AS, the one with the
       lowest metric is	preferred.

  Assigning Preferences

  A default preference is assigned to each source from which gated receives
  routes.  Preference values range from	0 to 255, with the lowest number
  indicating the most preferred	route.

  The following	table lists each type of route,	the statement (or clause
  within statements) that sets preference for the route, and the default
  preference for each type of route.

  Note that a statement	that is	narrow in scope	has a higher precedence	given
  to its preference value, but affects a smaller set of	routes.

  Preference of			       Defined by Statement   Default
  Direct connected networks	       interface	      0
  OSPF routes			       ospf		      10
  IS-IS	level 1	routes		       isis level 1	      15
  IS-IS	level 2	routes		       isis level 2	      18
  Internally generated default	       gendefault	      20
  Redirects			       redirect		      30
  Routes learned via route socket      kernel		      40
  Static routes	from config	       static		      60
  ANS SPF (SLSP) routes		       slsp		      70
  RIP routes			       rip		      100
  Point-to-point interface				      110
  Routes to interfaces that are	down   interfaces	      120
  Aggregate/generate routes	       aggregate/generate     130
  OSPF AS external routes	       ospf		      150
  BGP routes			       bgp		      170
  EGP				       egp		      200

  Multi-Exit Discriminator

  The Multi Exit Discriminator,	or MED,	allows the administrator of a routing
  domain to choose between various exits from a	neighboring AS.	 The gated
  daemon uses this attribute to	choose the best	route to the neighboring AS.
  If all the other factors for a path to a given AS are	equal, the path	with
  the lower MED	value takes preference over other paths.

  This attribute is not	propagated to other neighboring	ASs.  This attribute
  can be propagated, however, to other BGP speakers within the same AS.

  The MED attribute, for BGP version 4,	is a four-octet	unsigned integer.

  You originate	a MED by using the metricout option of group or	peer state-
  ments	or the metric option of	the export statement.  You import a MED	by
  using	the med	keyword	on the BGP group statement.

  You must specify the med keyword on the group	statement for gated to con-
  sider	metrics	when calculating a next	hop (the default action	is to ignore

  The following	example	shows the metricout option when	specified on the
  group	statement:

       group type external peeras 31337	metricout 5 {

  The following	example	shows the metricout option when	specified on the peer

       group type external peeras 31337	{
	       peer metricout 2;
	       peer metricout 3;

  The following	example	shows the metric keyword when specified	on the export

       export proto bgp	as 31337 metric	5 {
	       proto static {

  The following	example	shows another case of specifying the metric keyword
  on the export	statement:

       export proto bgp	as 31337 {
	       proto bgp as 64000 metric 1 {
	       proto static metric 3 {
	       proto direct metric 7 {

  Sample Preference Specifications

  In the following statements, the preference applicable to routes learned
  via RIP from gateway is 75.  The last preference applicable to
  routes learned via RIP from gateway is defined in	the accept
  statement.  The preference applicable	to other RIP routes is found in	the
  rip statement.  The preference set on	the interface statement	applies	only
  to the route to that interface.

       interfaces {
	       interface preference	10 ;
       } ;
       rip yes {
	   preference 90 ;
       } ;
       import proto rip	gateway preference 75 ;

Trace Options Statement

  Trace	options	statements control tracing options.  The gated daemon's	trac-
  ing options may be configured	at many	levels.	 Tracing options include the
  file specifications, control options,	and global and protocol-specific
  tracing options.  Unless overridden, tracing options from the	next higher
  level	are inherited by lower levels.	For example, Border Gateway Protocol
  (BGP)	peer tracing options are inherited from	BGP group tracing options,
  which	are inherited from global BGP tracing options, which are inherited
  from global gated tracing options.  At each level, tracing specifications
  override the inherited options.


  traceoptions [trace_file [replace] [size size[k|m]
	files files]] [control_options]	trace_options
	[except	trace_options] ;

  traceoptions none ;

      Specifies	the file to receive tracing information.  If this file name
      does not begin with a slash (/), the directory in	which gated was
      started is prepended to the name.

      Replaces an existing trace file.	The default is to append to an exist-
      ing file.

  size size[k|m] files files
      Limits the maximum size of the trace file	to the specified size
      (minimum 10 kilobytes).  When the	trace file reaches the specified
      size, it is renamed to file.0, then file.1, file.2, up to	the maximum
      number of	files (minimum specification is	2).

      Specifies	options	that control the appearance of tracing.	 The only
      valid value is nostamp, which specifies that a time stamp	should not be
      prepended	to all trace lines.

      See the "Global Tracing Options" section for more	information.

  except trace_options
      Enables a	broad class of tracing and then	disables more specific
      options.	See the	"Global	Tracing	Options" section for more informa-

      Specifies	that all tracing should	be turned off for this protocol	or

  Global Tracing Options

  There	are two	types of global	options: those with global significance	and
  those	with protocol significance.

  Global Significance

  The following	trace flags have global	significance:

      Traces the lexical analyzer and parser.  Used mainly by gated develop-
      ers for debugging.

  adv Traces the allocation of and freeing of policy blocks.  Used mainly by
      the gated	developers for debugging.

      Traces symbols read from the kernel at startup.  The principal means to
      specify this level of tracing is by the -t option	on the command line,
      because the symbols are read from	the kernel before parsing the confi-
      guration file.

      Traces the reading of the	kernel interface list.	Specify	this with the
      -t option	on the command line because the	first interface	scan is	done
      before reading the configuration file.

  Protocol Significance

  The following	options	flags have potential significance to protocols:

  all Turns on all of the options flags.

      A	shorthand notation for specifying both normal and route.

      Traces normal protocols occurrences.  Abnormal protocol occurrences are
      always traced.

      Traces routing table changes for routes installed	by this	protocol or

      Traces state machine transitions in the protocols.

      Traces application of protocol and user-specified	policy to routes
      being imported and exported.

      Traces system interface and processing associated	with this protocol or

      Traces timer usage by this protocol or peer.

       Not all of these	options	apply to all of	the protocols.	In some
       cases, their use	does not make sense (for instance, RIP does not	have
       a state machine)	and in some instances the requested tracing has	not
       been implemented	(such as RIP support of	the policy option).

       It is not possible to specify packet tracing from the command line
       because a global	option for packet tracing would	potentially create
       too much	output.

  When protocols inherit their tracing options from the	global tracing
  options, tracing levels that do not make sense (such as parse, adv, and
  packet tracing options) are masked out.

  Global tracing statements have an immediate effect, especially parsing
  options that affect the parsing of the configuration file.  Tracing values
  inherited by protocols specified in the configuration	file are initially
  inherited from the global options in effect as they are parsed, unless they
  are overridden by more specific options.

  After	the configuration file is read,	tracing	options	that were not expli-
  citly	specified are inherited	from the global	options	in effect at the end
  of the configuration file.

  Packet tracing

  The tracing of packets is flexible.  Every protocol has one or more options
  for tracing packets.	All protocols allow the	packets	keyword	to be used
  for tracing all packets sent and received by the protocol.  Most protocols
  have other options for limiting tracing to a useful subset of	packet types.
  These	tracing	options	can be further controlled with the following modif-

      Specifies	a more verbose format to provide more information about	the
      contents of the packet.  The detail option must be specified before
      send or recv.  By	default, packets are traced in a terse form of one or
      two lines.

      Limit the	tracing	to packets sent.  If neither send nor recv option is
      specified, both sent and received	packets	are traced.

      Limit the	tracing	to packets received.  If neither send nor recv option
      is specified, both sent and received packets are traced.

       If a protocol allows for	several	different types	of packet tracing,
       modifiers can be	applied	to each	individual type.  Be aware, however,
       that within one tracing specification the trace flags are summed	up,
       so specifying detail packets turns on full tracing for all packets.

Directive Statements

  Directive statements provide direction to the	gated configuration language
  parser about included	files and the directories in which these files
  reside.  Directive statements	are immediately	acted upon by the parser.
  Other	statements terminate with a semi-colon (;), but	directive statements
  terminate with a newline.  The two directive statements are as follows:

  %directory directory
      Defines the directory in which the include files are stored.  When it
      is used, gated searches the directory identified by pathname for any
      included files that do not have a	fully qualified	file name (do not
      begin with "/").	This statement does not	change the current directory;
      it only specifies	the prefix applied to included file names.

  %include filename
      Identifies an include file.  The contents	of the file are	included in
      the gated.conf file at the point where the %include directive is
      located.	If the file name is not	fully qualified	(does not begin	with
      "/"), it is considered to	be relative to the directory defined in	the
      %directory directive.  The %include directive statement causes the
      specified	file to	be parsed completely before resuming with this file.
      Nesting up to ten	levels is supported.  The maximum nesting level	can
      be increased by changing the definition of FI_MAX	in the parse.h file.

  In a complex environment, segmenting a large configuration into smaller
  more easily understood segments might	be helpful, but	one of the advantages
  of gated is that it combines the configuration of several different routing
  protocols into a single file.	 Segmenting a small file unnecessarily com-
  plicates routing configurations.

Options	Statements

  The options statement	allows specification of	some global options.  If
  used,	the options statement must appear before any other type	of configura-
  tion statement in the	gated.conf file.


      [gendefault [preference preference] [gateway gateway]]
      [syslog [upto] log_level]
      [mark time]

  The options list can contain one or more of the following options:

  gendefault [preference preference] [gateway gateway]
      When gendefault is enabled and a BGP or EGP neighbor is up, a default
      route with the special protocol default is created.  This	can be dis-
      abled per	BGP/EGP	group with the nogendefault option.  By	default, this
      route has	a preference of	20.  This route	is normally not	installed in
      the kernel forwarding table; it is only present so it can	be announced
      to other protocols.

      If a gateway is specified, the default route is installed	in the kernel
      forwarding table with a next hop of the listed gateway.

      Note that	the use	of the more general generate default option is pre-
      ferred to	the use	of the gendefault option.  The gendefault option may
      be removed in the	future.	 See the section on "Route Aggregation"	in
      gated.control(4) for more	information on the generate statement.

      Do not send any packets.	This option makes it possible to run gated on
      a	live network to	test protocol interactions without actually partici-
      pating in	the routing protocols.	The packet traces in the gated log
      can be examined to verify	that gated is functioning properly.  This is
      useful for RIP and possibly the SMUX SNMP	interface.  This option	does
      not apply	to BGP and is not useful with EGP and OSPF.

      By default, gated	tries to resolve symbolic names	into IP	addresses by
      using the	gethostbyname()	and getnetbyname() library calls.  These
      calls usually use	the Domain Name	System (DNS) instead of	the host's
      local host and network tables.  If there is insufficient routing infor-
      mation to	send DNS queries, gated	deadlocks during startup.  This
      option can be used to prevent these calls; symbolic names	result in
      configuration file errors.

  syslog [upto]	log_level
      Controls the amount of data gated	logs via syslog	on systems where set-
      logmask()	is supported.  The available logging levels and	other termi-
      nology are as defined in setlogmask(3).  The default is equivalent to
      syslog upto info.

  mark time
      Specifying this option causes gated to output a message to the trace
      log at the specified interval.  This can be used to determine if gated
      is still running.

Interfaces Statement

  An interface is the connection between a router and one of its attached
  networks.  A physical	interface can be specified by interface	name, by IP
  address, or by domain	name (unless the network is an unnumbered point-to-
  point	network).  Multiple levels of reference	in the configuration language
  allow	identification of interfaces using a wild card or interface type
  name.	 Be careful with the use of interface names because future versions
  might	allow more than	one address per	interface.  The	interface_list is a
  list of one or more interface	names including	wildcard names (names without
  a number) and	names that may specify more than one interface or address, or
  the token all	for all	interfaces.


  interfaces {
	  [scaninterval	time]
	  [aliases-nexthop ( primary | lowestip	| keepall )]
      interface	interface_list
	  [preference preference]
	  [down	preference preference]
	  [AS autonomoussystem]
      define address
	  [broadcast address | pointtopoint address]
	  [netmask mask]
  } ;

      Allows configuration of the following global options related to inter-

	Indicates that it is a fatal error to reference	an interface in	the
	configuration file that	is not present when gated is started and not
	listed in a define statement.  Without this option, a warning message
	is issued but gated continues.

      scaninterval time
	Specifies how often gated scans	the kernel interface list for
	changes.  The default is every 15 seconds on most systems, and 60
	seconds	on systems that	pass interface status changes through the
	routing	socket (for example, BSD 4.4).	Note that gated	also scans
	the interface list on receipt of a SIGUSR2.

      aliases-nexthop (primary | lowestip | keepall)
	Specifies which	address	gated will install as the next hop for inter-
	face routes.  If primary is used, the primary interface	address
	(default) will be installed.  If lowestip is used, the address with
	the lowest IP address will be installed.  If keepall is	used, all
	interface routes are kept in the kernel	up to a	maximum	of
	RT_N_MULTIPATH routes. The aliases-nexthop option is a global parame-
	ter that can be	overridden for interfaces using	the interface option.

  interface interface_list
      Sets interface options on	the specified interfaces.  An interface	list
      is all or	a list of interface names (see the "Interface Lists" sec-
      tion), domain names, or numeric addresses.  Options available on this
      statement	are:

      preference preference
	Sets the preference for	routes to this interface when it is up and
	appears	to be functioning properly.  The default preference is 0.

      down preference preference
	Sets the preference for	routes to this interface when gated does not
	believe	it to be functioning properly, but the kernel does not indi-
	cate it	is down.  The default value is 120.

	Prevents gated from changing the preference of the route to this
	interface if it	is not believed	to be functioning properly due to
	lack of	received routing information.  The gated daemon	only performs
	this check if the interface is actively	participating in a routing

	Defines	an interface as	unable to hear its own broadcast packets.
	Some systems define an interface as simplex with the IFF_SIMPLEX
	flag; others require it	to be specified	in the configuration file.
	On simplex interfaces, a sender's own packets are assumed to have
	been looped back in software and are not used as an indication that
	the interface is functioning properly.

	Specifies that the address of the interface matching these criteria
	is used	as the local address when installing reject routes in the
	kernel.	 Use this only with systems based on BSD 4.3 Tahoe or earlier
	that have installed a reject/blackhole pseudointerface.

	Specifies that the address of the interface matching these criteria
	is used	as the local address when installing reject routes in the
	kernel.	 Use this only with systems based on BSD 4.3 Tahoe or earlier
	that have installed a reject/blackhole pseudo interface.

      AS autonomoussystem
	Specifies the AS that will be used to create an	AS path	associated
	with the route created from the	definition of this interface.

  define address
      Defines interfaces that might not	be present when	gated is started so
      they may be referenced in	the configuration file when strictinterfaces
      is defined.  The following are valid define keywords:

      broadcast	address
	Defines	the interface as broadcast capable (for	example, Ethernet or
	Token Ring) and	specifies the broadcast	address.

      pointopoint address
	Defines	the interface as a point-to-point interface (for example,
	SLIP or	PPP) and specifies the address on the local side.  The first
	address	on the define statement	references the address of the host on
	the remote end of the interface, the address specified after this
	pointopoint keyword defines the	address	on the local side of the

	An interface that is not defined as broadcast or point-to-point	is
	assumed	to be nonbroadcast multiaccess (NBMA), such as an X.25 net-

      netmask mask
	Specifies the subnet mask to be	used on	this interface.	 This is
	ignored	on point-to-point interfaces.

	Specifies that the interface is	multicast capable.

  Interface Lists

  An interface list is a list of references to interfaces or groups of inter-
  faces.  The following	four methods, from most	general	to most	specific, are
  available for	referring to interfaces:

  all Refers to	all available interfaces.

  Interface name wildcard
      Refers to	all the	interfaces of the same type.  Tru64 UNIX interfaces
      consist of the device driver name	and a unit number; for example,	le0.
      References to the	name contain only alphabetic characters	and match any
      interfaces that have the same alphabetic part.

      For example, le refers to	all Lance Ethernet interfaces, but le does
      not match	lel0.

  Interface name
      Refers to	a specific interface, usually one physical interface.  These
      are specified as an alphabetic part followed by a	numeric	part.  This
      will match one specific interface.  But be aware that on many systems,
      there can	be more	than one protocol (for example,	IP) address on a
      given physical interface.	 For example, ee1 matches an interface named
      ee1, but not an interface	named ee10.

  Interface address
      Matches one specific interface.  The reference can be by protocol
      address (for example, or by symbolic host name	(for example,
      nic.ddn.mil).  Note that a symbolic host name reference is only valid
      when it resolves to only one address.  Use of symbolic host names	is
      not recommended.

  If many interface lists are present in the gated.conf	file with more than
  one parameter, these parameters are collected	at run time to create the
  specific parameter list for a	given interface.  If the same parameter	is
  specified on more than one list, the parameters with the most	specific
  interface are	used.

  For example, the following interface list is for a system with three inter-
  faces, le0, le1, and du0:

       rip yes {
	   interface all noripin noripout ;
	   interface le	ripin ;
	   interface le1 ripout	;
       } ;

  In this example, RIP packets are accepted from interfaces le0	and le1, but
  not from du0.	 RIP packets are sent only on interface	le1.

  IP Interface Addresses and Routes

  The BSD 4.3 and later	networking implementations allow the following four
  types	of interfaces.	Some implementations allow multiple protocol
  addresses per	physical interface, but	these are mostly based on BSD 4.3
  Reno or later.

      This interface must have the address of  Packets sent to
      this interface are sent back to the originator.  This interface is also
      used as an interface for implementing other features, such as reject
      and blackhole routes.  Although a	netmask	is reported on this inter-
      face, it is ignored.  It is useful to assign an additional address to
      this interface that is the same as the OSPF or BGP router	ID; this
      allows routing to	a system based on the router ID	that will work if
      some interfaces are down.

      This is a	multiaccess interface capable of a physical level broadcast,
      such as Ethernet,	Token Ring, and	FDDI.  This interface has an associ-
      ated subnet mask and broadcast address.  The interface route to a
      broadcast	network	is a route to the complete subnet.

      This is a	tunnel to another host,	usually	on some	sort of	serial link.
      This interface has a local address and a remote address.	Although it
      may be possible to specify multiple addresses for	a point-to-point
      interface, there is no useful reason for doing so.

      The remote address must be unique	among all the interface	addresses on
      a	given router.  The local address may be	shared among many point-to-
      point interfaces and up to one non-point-to-point	interface.  This is
      technically a form of the	router ID method for addressless links.	 This
      technique	conserves subnets, because none	are required when using	this

      If a subnet mask is specified on a point-to-point	interface, it is only
      used by RIP version 1 to determine which subnets may be propagated to
      the router on the	other side of this interface.

  non-broadcast	multi-access or	nbma
      This type	of interface is	multiaccess, but not capable of	broadcast;
      for example frame	relay and X.25.	 This type of interface	has a local
      address and a subnet mask.

  The gated daemon ensures that	there is a route available to each IP inter-
  face that is configured and up.  Typically this this done by the ifconfig
  command that configures the interface; gated does it to ensure consistency.

  For point-to-point interfaces, gated installs	some special routes.  If the
  local	address	on one or more point-to-point interfaces is not	shared with a
  non-point-to-point interface,	gated installs a route to the local address
  pointing at the loopback interface with a preference of 110.	This ensures
  that packets originating on this host	destined for this local	address	are
  handled locally.

  OSPF prefers to route	packets	for the	local interface	across the point-to-
  point	link where they	will be	returned by the	router on the remote end.
  This is used to verify operation of the link.	 Because OSPF installs routes
  with a preference of 10, these routes	override the route installed with a
  preference of	110.

  If the local address of one or more point-to-point interfaces	is shared
  with a non-point-to-point interface, gated installs a	route to the local
  with a preference of 0 that is not installed in the forwarding table.	 This
  prevents protocols like OSPF from routing packets to this address across a
  serial interface when	this system could be functioning as a host.

  When the status of an	interface changes, gated notifies all the protocols,
  which	take the appropriate action. The gated daemon assumes that interfaces
  that are not marked UP do not	exist.

  The gated daemon ignores any interfaces that have invalid data for the
  local, remote, or broadcast addresses	or the subnet mask.  Invalid data
  includes zeros in any	field.	The gated daemon also ignores any point-to-
  point	interface that has the same local and remote addresses;	it assumes it
  is in	some sort of loopback test mode.

Definition Statements

  Definition statements	are general configuration statements that relate to
  all of gated,	or at least to more than one protocol.	The three definition
  statements are autonomoussystem, routerid, and martians.  If used, auto-
  nomoussystem,	routerid, and martians must appear before any other type of
  configuration	statement in gated.conf	file.

  Autonomous System Syntax

  autonomoussystem autonomous_system [loops number] ;

  Sets the autonomous system number of this router to be autonomous_system.
  This option is required if BGP or EGP	are in use.  The AS number is
  assigned by the Network Information Center (NIC).

  The loops parameter is only for protocols supporting AS paths, such as BGP.
  It controls the number of times this autonomous system may appear in an AS
  path and defaults to 1 (one).

  Router ID Syntax

  routerid host	;

  Sets the router identifier for use by	the BGP	and OSPF protocols.  The
  default is the address of the	first interface	encountered by gated.  The
  address of a non-point-to-point interface is preferred over the local
  address of a point-to-point interface	and an address on a loopback inter-
  face that is not the loopback	address	( is most preferred.

  Martian Syntax

  Sometimes a misconfigured system sends out invalid destination addresses.
  These	invalid	addresses, called martians, are	rejected by the	routing
  software.  A martian configuration defines a list of martian addresses from
  which	all routing information	is ignored.  A martian configuration is
  structured as	follows:

  martians {
      host host	[allow]	;
      network [allow] ;
      network mask mask	[allow]	;
      network masklen number [allow] ;
      default [allow] ;
  } ;

  Adds martian addresses to the	list of	martian	addresses.  You	can specify
  the allow parameter to explicitly allow a subset of a	range that was disal-
  lowed.  (See the section on "Route Filtering"	in gated.control(4) for	more
  information on specifying ranges.)

  Sample Definition Statements

  The following	is an example of definition statements for a system:

       options gendefault ;
       autonomoussystem	249 ;
       interface passive ;
       martians	{

  A description	of each	statement in this example follows:

    +  The options statement tells the system to generate a default route
       when it peers with an EGP or BGP	neighbor.

    +  The autonomoussystem statement tells gated to use AS number 249 for
       EGP and BGP.

    +  The interface statement tells gated not to mark interface
       as down even if it sees no traffic.

    +  The martians statement prevents routes to from ever being


  Sample Host Configurations

  The gated.conf file for end systems is simple, usually containing only two
  configuration	statements.

   1.  The following sample configuration file emulates	routed,	runs RIP, and
       only sends updates if there is more than	one interface up and IP	for-
       warding is enabled in the kernel:
	    rip	yes ;

       Note that RIP will not run if UDP checksums are disabled	in the ker-

   2.  The following sample gated.conf file runs RIP in	quiet mode; it only
       listens to packets, no matter how many interfaces are configured:
	    rip	yes ;
	       nobroadcast ;
	    } ;

   3.  The following sample gated.conf file is suitable	for any	system that
       runs RIP	and has	only one network interface:
	    # do not time-out the network interface
	    interface passive ;
	    # enable rip
	    rip	yes ;

       The passive keyword prevents gated from changing	the preference of the
       route to	this interface if it is	believed to be down due	to lack	of
       received	routing	information.  The interface passive statement identi-
       fies a router with a guest host on an Ethernet.

       In the previous example,	the route is through the directly attached
       network interface.  Normally when gated thinks an interface is down,
       it removes it from the routing database to prevent a gateway from
       announcing that it can route data through a nonoperational interface.

       If the host has only one	interface, it should not be removed from the
       routing database	even if	the interface is down (the interface passive statement in	the example.   RIP is enabled with
       the rip yes statement.  This statement is not required as it is the
       default,	but the	explicit statement in the gated.conf file serves to
       document	the configuration to prevent future confusion.

  Sample Interior Gateway (Intra-Domain) Configurations

  Gateway configurations are more complicated than a simple host configura-
  tion as gateways have	multiple interfaces and	may run	multiple protocols.
  This section contains	sample gated.conf files	for the	following interior
  gateway configurations:

    +  RIP only	(subnet	to backbone)

    +  RIP with	default	announcement

    +  Direct routes

    +  Static routes

    +  Importing routes

    +  Exporting routes

    +  CIDR

    +  Source and trusted gateways

    +  OSPF Using NBMA Mode

    +  RIP and OSPF

  RIP only (subnet to backbone)

  The following	sample gated.conf file connects	two networks within an auto-
  nomous system.  You can use this configuration file for any gateway that
  uses only RIP	and that connects a single subnet to a larger network.

       # enable	rip
       rip yes ;
       #  using	 rip,  announce	subnet 3 via  interface
       export proto rip	interface
	 proto direct
	    announce	metric 0 ;
	 } ;
       } ;
       #  using	 rip, announce all routes learned from interface
       export proto rip	interface
	 proto rip interface
	    announce all ;
	 } ;
       } ;

  In this example, the first export statement tells gated to announce, via
  the RIP protocol and interface, a direct route to subnet  The second export statement announces to	subnet 3 all routes
  learned from the interface, including subnet routes and any
  routes to the	rest of	the world, as well as default routes.

  The first export statement is	not required because by	default	gated
  announces every network that is directly connected to	the gateway.  The
  export statement was explicitly entered for two reasons: to document the
  intended structure and to avoid relying on defaults that might be changed
  in future releases.

  In any export	statement, the main proto clause and the main interface
  clause may define the	protocol and interface through which the routes	are
  advertised.  Subsidiary proto	and interface clauses define the protocols
  and the interfaces from which	the routes must	be learned.

  RIP with default announcement

  In the following sample gated.conf file, the gateway announces a default
  route	to the backbone	and announces all of the individual subnet routes to
  the outside world.

       # enable	rip
       rip yes ;
       #  using	 rip, announce all local subnets via
       export proto rip	interface metric 3
	  proto	rip interface
	    announce all ;
	  } ;
       #  using	 rip,  announce	default	 to  the  local	backbone via
       export proto rip	interface
	  proto	rip interface
	    announce ;
	  } ;
       } ;

  The first export statement statement explicitly directs gated	to announce
  all of the routes it learns from interface	out through interface	The explicit announce all is not required.  The	metric value
  is specified in the main statement and applies to every route	announced via
  this protocol	and interface.	When the metric	is specified in	the export
  clause, it only applies to the routes	specified in that clause.  In the
  previous example, metric 3 applies to	every route announced over interface via RIP.

  Direct Routes

  If a gateway has interfaces on several networks, the following configura-
  tion provides	for announcing routes learned via the RIP protocol and routes
  to the directly connected networks.

       # enable	rip
       rip yes;

       # using rip announce all	directly connected networks with a metric of 0
       # and all routes	learned	via the	rip protocol
       export proto rip	{
	  proto	direct {
	     all metric	0;
	  proto	rip {

  Static Routes

  The following	configuration shows how	to statically configure	certain
  routes to point to a particular gateway.  Only routes	learned	via the	RIP
  protocol and the statically configured routes	are announced.

       # enable	rip
       rip yes;

       # these networks	and host are reachable via gateway
       static {
	  host gateway; mask gateway; masklen 24 gateway;

       # export	via RIP	all the	statically configured routes and
       # all routes learned via	RIP
       # the metric only applies to the	static routes
       export proto rip	metric 1 {
	  proto	static {
	  proto	rip {

  Importing Routes

  The following	configuration imports routes from the specified	gateways.
  You might want to do this when you only want to import routes	if they	meet
  certain requirements supplied	by a route filter.

       # enable	rip
       rip yes;

       # import	via RIP	routes only from these hosts (gateways)
       import proto rip	{

  Exporting Routes

  The following	configuration demonstrates how to filter out certain routes
  from being announced:

       # enable	rip
       rip yes;

       # use the export	statement to block out the 14, 15, and 16
       # networks and announce all others
       export proto rip	{ masklen 24 restrict; masklen 24 restrict; masklen 24 restrict;


  Because RIP version 1	does not carry netmask information in its packets,
  CIDR is difficult, if	not impossible,	to convey in RIP version 1 packets.
  The following	configuration RIP version 2 is used to Multicast its routes.
  RIP version 2	in RIP version 1 compatibility mode is not enough. While the
  netmask information is provided in RIP version 1 compatible packets, routes
  that might be	improperly interpreted by RIP version 1	will not be broad-
  casted by RIP	version	2.

       # enable	rip
       # turn on broadcast (RIPv2 will not multicast or	broadcast without this)
       # turn on version 2 multicast on	each interface
       rip yes {
	 interface	version	2 multicast;
	 interface	version	2 multicast;

  Source and Trusted Gateways

  Sometimes you	do not want a RIP speaker to broadcast or Multicast (in	the
  case of RIP version 2) its route announcements.  The following configura-
  tion shows how to use	the sourcegateways option to unicast the packets.  It
  also shows how to use	the trustedgateways option.

       # enable	rip
       # Send to 10.1, 11.1, and 12.1 but only accept from 10.1	and 11.1
       rip yes {

  OSPF Using NBMA Mode

  In the following sample gated.conf file, a server is configured as both the
  area border router and the backbone router.  This example has	two areas
  ( and	besides	the OSPF backbone area.	In area, one
  other	router (interface at	is eligible across the NMBA network
  to be	polled every 30	seconds. In area 0.0.02, two other routers are listed
  ( and, only one other router can engage in OSPF packets
  with this router (

  In the backbone area,	all routers are	polled by default at interval 30.

       traceoptions parse ;
       routerid ;
       RIP no ;
       OSPF yes	{
	  defaults {
	     preference	10 ;
	     cost 5 ;
	     type 1 ;
	  } ;
	  area {
	     networks { ;
	     } ;
	     interface nonbroadcast {
		routers	{ eligible ; eligible ;
		} ;
		priority 15 ;
		enable ;
		hellointerval 30 ;
		routerdeadinterval 30 ;
		pollinterval 30	;
	     } ;
	  } ;
	  area {
	     networks { ; ;
	     } ;
	     interface nonbroadcast {
		routers	{ eligible ; eligible ; ;
		} ;
		priority 15 ;
		enable ;
		hellointerval 30 ;
		routerdeadinterval 30 ;
		retransmitinterval 30 ;
		pollinterval 30	;
	     } ;
	  } ;
	  backbone {
	     interface nonbroadcast {
		enable ;
		transitdelay 20	;
		priority 10 ;
		hellointerval 30 ;
		routerdeadinterval 30 ;
		retransmitinterval 30 ;
		pollinterval 30	;
	     } ;
	  } ;
       } ;

  RIP and OSPF

  The following	sample gated.conf file for AS 283 enables both RIP and OSPF
  protocols and	can be used for	testing	RIP and	OSPF.

       #options	noinstall ;
       interfaces {
	 interface le0 passive ;
       } ;
       autonomoussystem	283 ;
       snmp yes	;
       rip yes {
	 broadcast ;
	 defaultmetric 5 ;
	 interface le version 2	multicast ;
       } ;
       ospf yes	{
	 traceoptions lsabuild protocol	;
	 monauthkey "ZZZZZZZZ" ;
	 backbone {
	    interface all {
	       priority	2 ;
	    } ;
	    interface le {
	       auth simple "YYYYYYYY" ;
	    } ;
	 } ;
       } ;
       static {
	  default  gateway  preference 140 retain ;

  In the RIP version 2 case, multicast packets are generated on	all Ethernet
  interfaces (for example, le0,	le1, and so on).  This is a safe way to	test
  RIP because the production gateways on this network do not support RIP ver-
  sion 2.  In the OSPF case, all interfaces are	configured to be Priority 2,
  so the Proteon routers (Priority 0) become designated	routers.  A simple
  password is specified	"YYYYYYYY" for authentication of all Ethernet inter-
  faces	(the only kind of interfaces in	this configuration).

  Sample Exterior Gateway (Inter-Domain) Configurations

  This section contains	sample gated.conf files	for the	following exterior
  gateway configurations:

    +  RIP and EGP

    +  BGP and OSPF

  RIP and EGP Configuration

  The following	sample gated.conf file enables both an interior	(RIP) and an
  exterior (EGP) protocol and sets certain protocol-specific parameters:

       #  generate a default route if an EGP neighbor is acquired
       options gendefault ;
       # define	the autonomous system number for EGP
       autonomoussystem	303 ;
       # enable	RIP
       rip yes ;
       # enable	EGP with hello interval	1 1/2 minute, poll
       #  interval 10 minutes, neighbors and
       egp yes {
	  packetsize 24488 ;
	  group	minhello 1:30 minpoll 10:00 {
	      neighbor ;
	      neighbor ;
	  } ;
       } ;
       # announce 136.66 to AS 183
       export proto egp	as 183 {
	  proto	direct {
	  136.66 metric	0 ;
	  } ;
       } ;
       # announce default via RIP with a metric	of 3
       export proto rip	interface {
	  proto	default	{
	      announce metric 3	;
	  } ;
       } ;

  The AS number	303 is defined early because it	is a definition	statement and
  must occur before the	first protocol statement.  EGP is enabled by the yes
  keyword in the EGP statement,	which also defines the following EGP parame-
  ters:	the packetsize parameter, defining the initial size of update packets
  accepted; the	group clause, setting parameters for all of the	EGP neighbors
  in the group;	and minhello and minpoll, setting the protocol timers.

  The first export statement directs gated to use EGP to advertise the net-
  work ( to the Internet.  This is the address of the network, not
  of a gateway.	 The second export statement is	used to	announce the default
  route	to subnet with a metric of 3.

  BGP and OSPF Configuration

  The following	sample gated.conf file implements the transformation of	dis-
  tance	metrics	between	the internal (OSPF) and	external (BGP) protocols.
  Autonomous system 1019, of which gated is a member, contains network  The gated machine has several interfaces into this	autonomous
  system.  The gated daemon is using BGP to peer with AS 2021, neighbor

       # # # # # # # # # # # # # # # # # # #
       interfaces {options all passive;	};
       autonomoussystem	1019;
       rip no;
       hello no;
       egp no;
       bgp yes {
	 preference 50 ;
	 group type
	 External peeras 2021

	 } ;
	 group type
	 IGP peeras 1019

	 } ;
       } ;
       ospf yes	{
	 area {
	   authtype none;
	   networks { mask ;
	   } ;
	   cost	1 {
	      retransmitinterval 5;
	      transitdelay 1;
	      priority 1;
	      hello interval 10;
	      routerdeadinterval 40;
	   } ;
	   cost	1 {
	      retransmitinterval 5;
	      transitdelay 1;
	      priority 1;
	      hellointerval 60;
	      routerdeadinterval 180;
	   } ;
	 } ;
	 backbone {
	   authtype none;
	   cost	1 {
	      retransmitinterval 5;
	      transitdelay 1;
	      priority 1;
	      hellointerval 60;
	      routerdeadinterval 180;
	   } ;
	 } ;
       } ;
       export proto ospfase type 1 {
	 proto bgp as 2021 {
	   metric 1; };
	 proto direct {
	   metric 1;  };
       } ;
       export proto bgp	as 2021	{
	 proto direct {
	   metric 1; } ;
	 proto ospfase {
	   metric 1; } ;
       } ;

  In this example, two autonomous systems (one internal, one external) are
  directly connected through a router that is attached to a backbone speaking
  OSPF.	 The AS	number 1019 is defined early as	it is a	definition statement
  that occurs again in the first protocol statement, which enables BGP.	 The
  first	export statement directs gated to advertise routes from	the internal
  group	AS 1019	running	OSPF as	the IGP	gathering routing information to the
  external group AS 2021 using BGP.

  Routes to two	local Ethernets	in AS 1019, identified as and ( mask, are advertised along	with the OSPF
  backbone (	 The parameters	for AS path, path origin, and transi-
  tive optional	attributes, including transmission intervals, are defined.
  The second export statement announces	the default route to AS	2021 with a
  metric of 1.


  Daemons: gated(8).

  Files: gated.control(4), gated.proto(4).

  Networking: gated_intro(7).

  RFC 827, Exterior Gateway Protocol EGP, E. Rosen.

  RFC 891, DCN local-network protocols,	D. Mills.

  RFC 904, Exterior Gateway Protocol Formal Specification, D. Mills.

  RFC 1058, Routing Information	Protocol, C. Hedrick.

  RFC 1105, Border Gateway Protocol BGP, K. Lougheed, Y. Rekhter.

  RFC 1163, A Border Gateway Protocol (BGP), K.	Lougheed, Y. Rekhter.

  RFC 1164, Application	of the Border Gateway Protocol in the Internet,	J.
  Honig, D. Katz, M. Mathis, Y.	Rekhter, J. Yu.

  RFC 1227, SNMP MUX Protocol and MIB, M. Rose.

  RFC 1245, OSPF Protocol Analysis, J. Moy.

  RFC 1246, Experience with the	OSPF Protocol, J. Moy.

  RFC 1253, OSPF Version 2 Management Information Base,	F. Baker, R. Coltun.

  RFC 1256, ICMP Router	Discovery Messages, S. Deering.

  RFC 1265, BGP	Protocol Analysis, Y. Rekhter.

  RFC 1266, Experience with the	BGP Protocol, Y. Rekhter.

  RFC 1267, A Border Gateway Protocol 3	(BGP-3), K. Lougheed, Y. Rekhter.

  RFC 1268, Application	of the Border Gateway Protocol in the Internet,	P.
  Gross, Y. Rekhter.

  RFC 1269, Definitions	of Managed Objects for the Border Gateway Protocol
  (Version 3), J. Burruss, S. Willis.

  RFC 1321, The	MD5 Message-Digest Algorithm, R. Rivest.

  RFC 1370, Internet Architecture Board	Applicability Statement	for OSPF

  RFC 1388, RIP	Version	2 Carrying Additional Information, G. Malkin.

  RFC 1397, Default Route Advertisement	In BGP2	And BGP3 Versions Of The
  Border Gateway Protocol, D. Haskin.

  RFC 1403, BGP	OSPF Interaction, K. Varadhan.

  RFC 1583, OSPF Version 2, J. Moy.