*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> gated.conf (4)              



NAME    [Toc]    [Back]

       gated.conf  -  Gate  daemon  configuration  file  (general

DESCRIPTION    [Toc]    [Back]

       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 information,
 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 combination  of  blanks,  tabs,
       and newlines.  This structure simplifies identification of
       the parts of the configuration associated with each  other
       and  with specific protocols. Comments can be specified by
       either of the following: A number sign (#) The C-style  /*
       and */ characters.

   Syntax description conventions    [Toc]    [Back]
       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 parameters.  Parentheses (()) group keywords  and
       parameters, when necessary.  For example: backbone | (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    [Toc]    [Back]
       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 configuration 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    [Toc]    [Back]
       The  following  table  lists each gated.conf configuration
       statement by name,  identifies  the  statement  type,  and
       gives a synopsis of the statement's function:

       Name               Type         Synopsis
       %directory         directive    Sets  the  directory  for  include
       %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
       rip                protocol     Enables the RIP protocol.
       isis               protocol     Enables the ISIS protocol.
       kernel             protocol     Configures    kernel     interface
       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
       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.


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

       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
       protocol 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 systems.

   Selecting a Route    [Toc]    [Back]
       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 preferred.  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
       path.  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    [Toc]    [Back]
       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

       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

       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    [Toc]    [Back]
       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 statements 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 consider metrics when calculating a next hop
       (the default action is to ignore MEDs).

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

       group type external peeras 31337 metricout 5 {
               peer; };

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

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

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

       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    [Toc]    [Back]
       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

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


       Trace  options  statements  control  tracing options.  The
       gated daemon's tracing 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.

   Syntax    [Toc]    [Back]
       traceoptions [trace_file [replace]  [size  size[k|m] files
       files]]    [control_options]     trace_options     [except

       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 existing file.  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.  Enables a broad
       class of tracing and then disables more specific  options.
       See  the  Global Tracing Options section for more information.
  Specifies that all tracing should be turned off for
       this protocol or peer.

   Global Tracing Options    [Toc]    [Back]
       There  are  two types of global options: those with global
       significance and those with protocol significance.

   Global Significance    [Toc]    [Back]
       The following trace flags have global significance: Traces
       the  lexical  analyzer  and  parser.  Used mainly by gated
       developers for debugging.  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
       configuration 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    [Toc]    [Back]
       The following options flags have potential significance to
       protocols: 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  peer.   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 peer.   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  explicitly  specified  are  inherited  from  the
       global  options  in effect at the end of the configuration

   Packet tracing    [Toc]    [Back]
       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 modifiers: 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


       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  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: 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.  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 complicates routing configurations.


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

   Syntax    [Toc]    [Back]
            [gendefault  [preference  preference]  [gateway gateway]]

            [syslog [upto] log_level]
            [mark time]

       The options list can contain one or more of the  following
       options:  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 disabled 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 preferred 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 participating 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 information to  send  DNS  queries,
              gated deadlocks during startup.  This option can be
              used to prevent these calls; symbolic names  result
              in  configuration file errors.  Controls the amount
              of data gated logs via syslog on systems where setlogmask()
 is supported.  The available logging levels
 and other terminology are as defined in setlogmask(3).   The default is equivalent to syslog upto
              info.  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.


       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.

   Syntax    [Toc]    [Back]
       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 interfaces: 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.  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.
       Specifies which address gated will install as the next hop
       for interface 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 parameter
       that can be overridden for interfaces using the  interface
       option.   Sets  interface  options on the specified interfaces.
  An interface list is all or a  list  of  interface
       names  (see  the "Interface Lists" section), domain names,
       or numeric addresses.  Options available on this statement
       are: Sets the preference for routes to this interface when
       it is up and appears  to  be  functioning  properly.   The
       default  preference  is 0.  Sets the preference for routes
       to this interface when gated does not  believe  it  to  be
       functioning  properly, but the kernel does not indicate 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  protocol.  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.  Specifies the AS that will be used
       to create an AS path associated  with  the  route  created
       from the definition of this interface.  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:
  Defines  the  interface  as broadcast capable (for
       example, Ethernet or Token Ring) and specifies the  broadcast
  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 interface.

              An  interface  that  is not defined as broadcast or
              point-to-point is assumed to be nonbroadcast multiaccess
  (NBMA), such as an X.25 network.  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    [Toc]    [Back]
       An interface list is a list of references to interfaces or
       groups  of  interfaces.   The following four methods, from
       most general to most specific, are available for referring
       to interfaces: Refers to all available interfaces.  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.  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.  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 interfaces, 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    [Toc]    [Back]
       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 interface, 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 associated 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-topoint
 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 technique.

              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.   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 interface 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-topoint
  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 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,
       autonomoussystem,  routerid,  and  martians  must   appear
       before  any  other  type  of  configuration  statement  in
       gated.conf file.

   Autonomous System Syntax    [Toc]    [Back]
       autonomoussystem autonomous_systemloops 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    [Toc]    [Back]
       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-topoint
  interface  is preferred over the local address of a
       point-to-point interface and  an  address  on  a  loopback
       interface  that is not the loopback address ( is
       most preferred.

   Martian Syntax    [Toc]    [Back]
       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 disallowed.  (See the section
       on "Route Filtering" in gated.control(4) for more information
 on specifying ranges.)

   Sample Definition Statements    [Toc]    [Back]
       The following is an example of definition statements for a

       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 accepted.

EXAMPLES    [Toc]    [Back]

   Sample Host Configurations
       The gated.conf file for end  systems  is  simple,  usually
       containing only two configuration statements.  The following
 sample configuration file emulates routed,  runs  RIP,
       and only sends updates if there is more than one interface
       up and IP forwarding is enabled in the kernel:

              # rip yes ; #

              Note that RIP will not run  if  UDP  checksums  are
              disabled  in  the  kernel.   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  ;  }  ;  #  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
 identifies a router with a guest  host  on  an

              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

              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    [Toc]    [Back]
       Gateway  configurations are more complicated than a simple
       host configuration 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)    [Toc]    [Back]

       The following sample gated.conf file connects two networks
       within  an autonomous 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

       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    [Toc]    [Back]

       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    [Toc]    [Back]

       If a gateway has interfaces on several networks, the  following
   configuration   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    [Toc]    [Back]

       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    [Toc]    [Back]

       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 {
          host; }

       Exporting Routes    [Toc]    [Back]

       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;
          all; }

       CIDR    [Toc]    [Back]

       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 broadcasted
       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    [Toc]    [Back]

       Sometimes you do not want a RIP speaker  to  broadcast  or
       Multicast  (in  the  case  of  RIP  version  2)  its route
       announcements.  The following configuration 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 {
          trustedgateways; };

       OSPF Using NBMA Mode    [Toc]    [Back]

       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    [Toc]    [Back]

       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  version
       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  interfaces
       (the only kind of interfaces in this configuration).

   Sample Exterior Gateway (Inter-Domain) Configurations    [Toc]    [Back]
       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 parameters:
 the packetsize parameter, defining the initial  size
       of  update  packets  accepted;  the  group clause, setting
       parameters for all of the EGP neighbors in the gro

 Similar pages
Name OS Title
gated.proto Tru64 Gate daemon configuration file (protocol statements)
gated.control Tru64 Gate daemon configuration file (control statements)
gated_intro Tru64 Information about the gate daemon and its implementation
ogated.conf Tru64 Contains configuration information for the ogated daemon
evmdaemon.conf Tru64 EVM daemon configuration file
sshd2_config Tru64 Configuration file for the sshd2 daemon
sshd_config OpenBSD OpenSSH SSH daemon configuration file
sshd_config FreeBSD OpenSSH SSH daemon configuration file
rtradvd.conf HP-UX configuration file for router advertisement daemon
rrenumd.conf FreeBSD configuration file for router renumbering daemon
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service