gated.config man page on HP-UX

Printed from http://www.polarhome.com/service/man/?qf=gated.config&af=0&tf=2&of=HP-UX

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

NAME
       gated.conf - GateDaemon Configuration Guide

SYNOPSIS
DESCRIPTION
   Configuration Overview
	      ·	 Introduction

	      ·	 Statement Summary

	      ·	 Preferences and Route Selection

	      ·	 Trace Statements and Global Options

	      ·	 Directive Statements

	      ·	 Options Statements

	      ·	 Interface Statements and Configuration

	      ·	 Definition Statements

   Protocol Statements
	      ·	 Protocol Overview

	      ·	 Interior gateway protocols (igps)

		 ·  RIP, HELLO, OSPF

	      ·	 Exterior gateway protocols (egps)

		 ·  EGP, BGP

	      ·	 ICMP Statement

	      ·	 Redirect Statement

	      ·	 Router Discovery Statement

	      ·	 Kernel Interface

	      ·	 Static Routes

   Control Statements
	      ·	 Route filtering

	      ·	 Matching AS paths

	      ·	 Route Importation

	      ·	 Route Exportation

	      ·	 Route Aggregation

   Appendices
	      ·	 Glossary of Terms

	      ·	 References

Introduction to Configuring GateD
   Syntax
       The  gated configuration file consists of a sequence of statements ter‐
       minated by a semi-colon (;). Statements are composed  of	 tokens	 sepa‐
       rated  by white space, which can be 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 may be specified in either of two forms. One form begins  with
       a  pound	 sign  (#)  and runs to the end of the line. The other form, C
       style, starts with a /* and continues until it reaches */.

   Syntax description conventions
       Keywords and special characters that the	 parser	 expects  exactly  are
       displayed  using bold type. Parameters are displayed in italic variable
       definition style.  Parameters shown in square brackets ([  and  ])  are
       used to show optional keywords and parameters.  The vertical bar (|) is
       used to indicate between a choice of optional  parameters.  Parentheses
       (( and )) are used to group keywords and parameters when necessary.

       For example, in the syntax description:

	      [ backbone | ( area area ) ]

       The square brackets say that either parameter is optional. The keywords
       are backbone and area.  The vertical bar indicates that	either	"back‐
       bone"  or  "area area" may be specified.	 Since area is in the variable
       definition style, it is a parameter that needs to be provided.

   Statement Grouping
       The configuration statements and the order in  which  these  statements
       appear divide into options statements, interface statements, definition
       statements, protocol statements, static statements, control statements,
       and  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:  %direc‐
       tive   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.

   Statement Summary
       A summary table of the configuration statements (in  the	 configuration
       statement  summary)  lists  each GateD configuration statement by name,
       identifies the statement type, and provides a  short  synopsis  of  the
       command function. More detailed definitions and descriptions of each of
       the eight classes of GateD statements follow in separate sections.

GateD Configuration Statement Summary
       The GateD configuration commands are summarized below. The table	 lists
       each command by name, identifies the statement type, and gives a synop‐
       sis of the statement function:

   Summary of GateD Configuration Statements
	      %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 RIP protocol.

	      hello (protocol)		    enables HELLO protocol.

	      isis (protocol)		    enables ISIS protocol.

	      kernel (protocol)		    configures	   kernel    interface
					    options.

	      ospf (protocol)		    enables OSPF protocol.

	      egp (protocol)		    enables EGP protocol.

	      bgp (protocol)		    enables BGP protocol.

	      redirect (protocol)	    configures the processing of  ICMP
					    redirects.

	      icmp (protocol)		    configures	the processing of gen‐
					    eral ICMP packets.

	      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.

Preference
       Preference is the value GateD uses to order preference of  routes  from
       one  protocol  or peer over another. Preference can be set in the GateD
       configuration files  in	several	 different  configuration  statements.
       Preference can be set based on network interface over another, from one
       protocol over another, or from one remote gateway over another.	 Pref‐
       erence  may  not	 be  used to control the selection of routes within an
       igp, this is accomplished automatically by the protocol based  on  met‐
       ric.  Preference may be used to select routes from the same egp learned
       from different peers or autonomous systems.  Each route	has  only  one
       preference  value associated with it, even though preference can be set
       at many places in the configuration file.  Simply,  the	last  or  most
       specific preference value set for a route is the value used. (See Glos‐
       sary of Terms: Preference.)  The preference  value  is  an  arbitrarily
       assigned value used to determine the order of routes to the same desti‐
       nation 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.

   Selecting a route
	      ·	 The route with the best (numerically smallest) preference  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.

	      ·	 A  route  learned  from a igp is preferred to a route learned
		 from an egp. Least preferred is a route learned indirectly by
		 an igp from an egp.

	      ·	 If  AS	 path  information  is	available,  it is used to help
		 determine the most preferred route.

		 ·  A route with an AS path is preferred over one  without  an
		    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. Least preferred is an
		    AS path with an unknown origin.

		 ·  A route with a shorter AS path is preferred.

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

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

   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 summarizes the default preference values for routes
       learned in various ways. The table lists the statements (some of	 these
       are clauses within statements) that set preference, and shows the types
       of routes to which each statement applies. The default  preference  for
       each type of route is listed, and the table notes preference precedence
       between protocols. The narrower the scope of the statement, the	higher
       precedence  its	preference  value is given, but the smaller the set of
       routes it affects.

       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
       HELLO routes			    hello		      90
       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

   Sample Preference Specifications
       interfaces {
	   interface 138.66.12.2 preference 10 ;
       } ;
       rip yes {
	   preference 90 ;
       } ;
       import proto rip gateway 138.66.12.1 preference 75 ;

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

Trace Statements
       Trace statements control tracing options. The GateD tracing options may
       be configured at many levels. Tracing options include the file specifi‐
       cations,	 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, 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 trac‐
       ing options. At each level tracing specifications override  the	inher‐
       ited options.

   Global tracing options
       There  are  two types of global options, those which only affect global
       operations and those which have potential significance to protocols.

   Global significance only
       The trace flags that only have global significance are:

	      parse	Trace the lexical analyzer and parser. Mostly used  by
			GateD developers for debugging.

	      adv	Trace  the allocation of and freeing of policy blocks.
			Mostly used by the GateD developers for debugging.

	      symbols	Used to trace symbols read from the kernel at startup.
			The  only  useful way to specify this level of tracing
			is via the -t option on the  command  line  since  the
			symbols	 are  read  from the kernel before parsing the
			configuration file.

	      iflist	Used to trace the  reading  of	the  kernel  interface
			list.  It is useful to specify this with the -t option
			on the command line since the first interface scan  is
			done before reading the configuration file.

   Protocol significance
       The options flags that have potential significance to protocols are:

	      all	Turn on all of the following.

	      general	A  shorthand  notation	for specifying both normal and
			route.

	      state	Trace state machine transitions in the protocols.

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

	      policy	Trace  application of protocol and user-specified pol‐
			icy to routes being imported and exported.

	      task	Trace system interface and processing associated  with
			this protocol or peer.

	      timer	Trace timer usage by this protocol or peer.

	      route	Trace  routing	table  changes for routes installed by
			this protocol or peer.

       Not all of the above 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 currently possible to specify packet tracing from the command
       line. This is because a global option for packet tracing	 would	poten‐
       tially 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 effect the parsing of the configuration file. Tracing val‐
       ues inherited by protocols specified in the configuration file are ini‐
       tially inherited from the global options in effect as they are  parsed,
       unless they are overridden by more specific options. After the configu‐
       ration file is read, tracing options that were not explicitly specified
       are  inherited from the global options in effect at the end of the con‐
       figuration file.

   Packet tracing
       Tracing of packets is very flexible. For any given protocol  there  are
       one or more options for tracing packets. all protocols allow use of the
       packets keyword allows 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:

	      detail	detail must be specified before send or recv. Normally
			packets are traced in a	 terse	form  of  one  or  two
			lines. When detail is specified, a more verbose format
			is used to provide further detail on the  contents  of
			the packet.

	      send
	      recv	These  options	limit  the  tracing to packets sent or
			received. Without these options both sent and received
			packets will be traced.

       Detail, if specified, must be before send or recv. If a protocol allows
       for several different types of packet tracing, modifiers may be applied
       to each individual type.	 But be aware that within one tracing specifi‐
       cation the trace flags are summed up, so specifying detail packets will
       turn on full tracing for all packets.

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

       traceoptions none ;

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

	      replace	Tracing should start by replacing  an  existing	 file.
			The default is to append to an existing file.

	      size size[k|m] files files
			Limit the maximum size of the trace file to the speci‐
			fied size (minimum 10k). 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 (min‐
			imum specification is 2).

	      control_options
			Specifies options that control the appearance of trac‐
			ing. Valid values are:

			nostamp
			       Specifies  that	a  timestamp  should  not   be
			       prepended to all trace lines.

	      except trace_options
			Used  to enable a broad class of tracing and then dis‐
			able more specific options.

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

Directive Statements
       Directive  statements provide direction to the GateD configuration lan‐
       guage 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:

	      %directory "directory"
		     Defines the directory where the include files are stored.
		     When it is used, GateD looks in the directory  identified
		     by	 pathname  for	any  included files that do not have a
		     fully qualified filename, such as files that do not begin
		     with  "/".	 This  statement  does not actually change the
		     current the  directory,  it  just	specifies  the	prefix
		     applied to included file names.

	      %include "filename"
		     Identifies	 an  include file. The contents of the file is
		     included in the gated.conf	 file  at  the	point  in  the
		     gated.conf	 file  where the %include directive is encoun‐
		     tered. If the filename 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 nest‐
		     ing level may be increased by changing the definition  of
		     FI_MAX in parse.h.

       In a complex environment, segmenting a large configuration into smaller
       more easily understood segments might be helpful, but one of the	 great
       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.

Options Statements
       Options statements allow specification of some global options. If used,
       options must appear before any other type of configuration statement in
       the gated.conf file.

       The options statement syntax is:

	      options
		  [ nosend ]
		  [ noresolv ]
		  [ 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, when a BGP or EGP neighbor is
		     up it causes the creation of a  default  route  with  the
		     special  protocol	default.  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 will be installed
		     in	 the  kernel  forwarding  table with a next hop of the
		     listed gateway.

		     Note that the use of the more general option is preferred
		     to	 the  use  of  this  gendefault option. The gendefault
		     option may go away in future releases. The the section on
		     Route  Aggregation	 for  more information on the generate
		     statement.

	      nosend 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  most
		     useful  for  RIP  and  HELLO  and	possibly the SMUX SNMP
		     interface. This option does not yet apply to BGP  and  is
		     less than useful with EGP and OSPF.

	      noresolv
		     By	 default GateD will try to resolve symbolic names into
		     IP addresses by using the gethostbyname()	and  getnetby‐
		     name()  library calls. These calls usually use the Domain
		     Name System (DNS) instead of the  hosts  local  host  and
		     network tables. If there is insufficient routing informa‐
		     tion to send DNS  queries,	 GateD	will  deadlock	during
		     startup.  This option can be used to prevent these calls,
		     symbolic names will result in configuration file errors.

	      syslog [ upto ] log_level
		     Controls the amount of data GateD logs via syslog on sys‐
		     tems  where setlogmask() is supported. The available log‐
		     ging levels and other terminology are as defined  in  the
		     setlogmask(3) manpage.  The default is equivalent to sys‐
		     log 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 as one method of determining if gated is still  run‐
		     ning.

Interfaces Statement
   Interface Syntax
       interfaces {
	   options
	       [ strictinterfaces ]
	       [ scaninterval time ]
	       [ aliases-nh ( primary | lowestip | keepall ) ]
	       ;
	   interface interface_list
	       [ preference preference ]
	       [ down preference preference ]
	       [ passive ]
	       [ simplex ]
	       [ reject ]
	       [ blackhole ]
	       [ alias	primary address ]
	       [ aliases-nh ( primary | lowestip | keepall ) ]
	       ;
	   define address
	       [ broadcast address ] | [ pointtopoint address ]
	       [ netmask mask ]
	       [ multicast ]
	       ;
       } ;

       An interface is the connection between a router and one of its attached
       networks. A physical interface may 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 configura‐
       tion language allow identification of interfaces using wildcard, inter‐
       face type name, or delete word address. Be  careful  with  the  use  of
       interface  names	 as  future Unix operating systems may 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 which may specify more than one  interface	 or  address,  or  the
       token all for all interfaces.

	      options
		     Allows  configuration  of	some global options related to
		     interfaces. These are:

		     strictinterfaces
			    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 will be issued but GateD will continue.

		     scaninterval time
			    Specifies how often GateD scans the kernel	inter‐
			    face  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 (BSD 4.4).  Note  that  GateD  will
			    also  scan	the  interface	list  on  receipt of a
			    SIGUSR2.

		     aliases-nh ( primary | lowestip | keepall )
			    Specifies which address GateD will install as  the
			    next   hop	for  interface	routes	when  multiple
			    addresses are assigned to an  interface  like  the
			    Service Guard environment. If is used, the primary
			    interface address (default) will be installed.  If
			    is	used,  the  address with the lowest IP address
			    will be  installed.	 If  is	 used,	all  interface
			    routes  are kept in the  kernel up to a maximum of
			    routes. This is a compile-time constant.  This  is
			    a  global  parameter  that	may  be overridden for
			    interfaces using the interface option.

			    Note: The option is mandatory when gated is	 being
			    used in a Service Guard environment.

	      interface interface_list
		     Sets  interface  options  on the specified interfaces. An
		     interface list is all or a list of interface  names  (see
		     warning  about interface names), 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 prop‐
			    erly. 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 indicate	it  is
			    down. The default value is 120.

		     passive
			    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.  GateD will only perform this
			    check  if  the interface is actively participating
			    in a routing protocol.

		     simplex
			    Defines an interface as unable  to	hear  its  own
			    broadcast  packets.	 Some systems define an inter‐
			    face as simplex with the flag, on others it	 needs
			    to be specified in the configuration file. On sim‐
			    plex interfaces, packets from myself  are  assumed
			    to	have  been looped back in software and are not
			    used as an indication that the interface is	 func‐
			    tioning properly.

		     reject Specifies  that the address of the interface which
			    matches these criteria will be used as  the	 local
			    address  when installing reject routes in the ker‐
			    nel. Should only be used with systems based on BSD
			    4.3	 Tahoe	or  earlier  which  have  installed  a
			    reject/blackhole pseudo interface.

		     blackhole
			    Specifies that the address of the interface	 which
			    matches  these  criteria will be used as the local
			    address when installing reject routes in the  ker‐
			    nel. Should only be used with systems based on BSD
			    4.3	 Tahoe	or  earlier  which  have  installed  a
			    reject/blackhole pseudo interface.

		     alias  primary address
			    Specifies  a  primary  address for this interface.
			    This  option  overrides  the  address  that	 GateD
			    determines to be primary.

		     aliases-nh ( primary | lowestip | keepall )
			    Specifies  which address GateD will install as the
			    next hop for the route associated with this inter‐
			    face  when	multiple  addresses are assigned to an
			    interface like the Service Guard  environment.  If
			    is	used,  the primary interface address (default)
			    will be installed. If is used,  the	 address  with
			    the	 lowest	 IP  address  will be installed. If is
			    used, all interface routes are kept in the	kernel
			    up	to a maximum of routes. This is a compile-time
			    constant.  This  parameter	overrides  the	global
			    option for this interface.

			    Note:  The option is mandatory when gated is being
			    used in a Service Guard environment.

	      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.  Possible	define
		     keywords are:

		     broadcast address
			    Defines the interface as broadcast capable (Ether‐
			    net or Token Ring)	and  specifies	the  broadcast
			    address.

		     pointtopoint address
			    Defines  the  interface as a point-to-point inter‐
			    face (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 spec‐
			    ified after this pointtopoint keyword defines  the
			    address on the local side of the interface.

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

		     netmask mask
			    Specifies the subnetmask to be used on this inter‐
			    face.  This is ignored on pointtopoint interfaces.

		     multicast
			    Specifies that the interface is multicast capable.

   Interface lists
       An interface list is a list of references to interfaces	or  groups  of
       interfaces.  There  are	four methods available for referring to inter‐
       faces. They are listed here from most general to most specific.

	      all    This refers to all available interfaces.

	      Interface name wildcard
		     This refers to all the interfaces of the same type.  Unix
		     interfaces consist of the name of the device driver, like
		     ie, and a unit number, like 0, 5 or 22. Reference to  the
		     name  contain  only  alphabetic  characters and match any
		     interfaces that have the same alphabetic part.

		     For example, ie on a Sun would refer to all Interlan Eth‐
		     ernet  interfaces,	 le  would refer to all Lance Ethernet
		     interfaces. But ie would not match iel0.

	      Interface name
		     This refers to a specific interface, usually one physical
		     interface. These are specified as an alphabetic part fol‐
		     lowed by a numeric part. This  will  match	 one  specific
		     interface.	 But  be aware that on many systems, there can
		     be more than one protocol (IP) address on a given	physi‐
		     cal  interface.  For example, ef1 will match an interface
		     named ef1, but not an interface named ef10.

	      Interface address
		     This matches one specific interface. The reference can be
		     by	 protocol address (10.0.0.51), or by symbolic hostname
		     (nic.ddn.mil). Note that a symbolic hostname reference is
		     only  valid  when it resolves to only one address. Use of
		     symbolic hostnames is not recommended.

       If many interface lists are present in the configuration file with more
       than  one parameter, these parameters are collected at run-time to cre‐
       ate 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 is used.

       For example, consider a system with three interfaces, le0, le1 and du0.

	      rip yes {
		  interface all noripin noripout ;
		  interface le ripin ;
		  interface le1 ripout ;
	      } ;
       RIP packets would only be accepted from interfaces le0 and le1, but not
       from du0. RIP packets would only be sent on interface le1.

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

	      loopback
		     This  interface must have the address of 127.0.0.1. Pack‐
		     ets sent to this interface are sent back to the  origina‐
		     tor. This interface is also used as a catch all 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 addi‐
		     tional  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 which will work if some interfaces
		     are down.

	      broadcast
		     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	broad‐
		     cast address. The interface route to an broadcast network
		     will be a route to the complete subnet.

	      point-to-point
		     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
		     does not seem to be a 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 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	 as  none are required when using this
		     technique.

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

	      nonbroadcast multiaccess or nbma
		     This type of interface is multiaccess, but not capable of
		     broadcast. And example would be  frame  relay  and	 X.25.
		     This  type	 of interface has a local address and a subnet
		     mask.

       GateD insures that there is a route available to each IP interface that
       is  configured  and up. Normally this this done by the ifconfig command
       that configures the interface; GateD does it to insure 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 insures 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. Since OSPF installs routes with a preference  of
       10, these routes will 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 will not be installed in the forward‐
       ing  table. This is to prevent 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 proto‐
       cols, which take the appropriate action. GateD assumes that  interfaces
       which  are not marked UP do not exist. While this might not be the most
       correct action, it is the way things currently work.

       GateD 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.  GateD will also ignore any	point-to-point	inter‐
       face  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 defi‐
       nition 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 configuration
       autonomoussystem autonomous_system [ loops number ] ;

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

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

   Router ID configuration
       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
       interface that is not the loopback address  (127.0.0.1)	is  most  pre‐
       ferred.

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

       Defines a list of martian addresses about which all routing information
       is ignored.  Sometimes  a  misconfigured	 system	 sends	out  obviously
       invalid	destination  addresses.	 These	invalid addresses, called mar‐
       tians, are rejected by the routing software. This command allows	 addi‐
       tions  to  the list of martian addresses. See the section on Route Fil‐
       tering for more information  on	specifying  ranges.  Also,  the	 allow
       parameter may be specified to explicitly allow a subset of a range that
       was disallowed.

   Sample Definition Statements
       options gendefault ;
       autonomoussystem 249 ;
       interface 128.66.12.2 passive ;
       martians {
	   0.0.0.26
	   };

       The statements in the sample perform the following functions:

	      ·	 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 in EGP and BGP.

	      ·	 The interface statement tells GateD  not  to  mark  interface
		 128.66.12.2 as down even if it sees no traffic.

	      ·	 The  martians statement prevents routes to 0.0.0.26 from ever
		 being accepted.

Protocol Overview
       Routing protocols determine the "best" route to	each  destination  and
       distribute  routing information among the systems on a network. Routing
       protocols are divided into two general groups:  interior	 and  exterior
       protocols. GateD software combines management of the interior and exte‐
       rior routing protocols in one software daemon.

   Interior Routing Protocols
       Interior protocols are used to exchange reachability information within
       an autonomous system (AS). They are referred to as a class by the acro‐
       nym igp. There are several interior protocols:

       RIP  The Routing Information Protocol, Version 1 and Version 2, is  the
	    most  commonly  used interior protocol. RIP selects the route with
	    the lowest metric as the best route. The metric  is	 a  hop	 count
	    representing  the  number of gateways through which data must pass
	    to reach its destination. The longest path that RIP accepts is  15
	    hops.  If  the metric is greater than 15, a destination is consid‐
	    ered unreachable and GateD discards the  route.  RIP  assumes  the
	    best  route	 is the one that uses the fewest gateways which is the
	    shortest path, not taking into  account  congestion	 or  delay  on
	    route.

	    The	 RIP  version  1 protocol is described in RFC 1058 and the RIP
	    version 2 protocol is described in RFC 1388.

       HELLO
	    HELLO , another interior protocol, uses delay as the deciding fac‐
	    tor	 in  choosing the best route. Round-trip time is the length of
	    time it takes a datagram to travel from the	 source	 and  destina‐
	    tion. HELLO is historically significant for the Internet as it was
	    the protocol used among the	 original  prototype  NSFNET  backbone
	    fuzzball  gateways.	 Today, like fuzzballs, HELLO is a little-used
	    protocol.

	    An earlier version of the HELLO protocol is described in RFC 891.

       OSPF Open Shortest Path First is a link-state protocol. OSPF is	better
	    suited than RIP for complex networks with many routers.  OSPF pro‐
	    vides equal cost multipath routing.

	    OSPF is described in RFC 1583, the MIB is  defined	in  RFC	 1253.
	    Other related documents are RFC 1245, RFC 1246 and RFC 1370.

   Exterior Routing Protocols
       Exterior protocols are used to exchange routing information between au‐
       tonomous systems. Exterior protocols are only required when an  autono‐
       mous  system  must exchange routing information with another autonomous
       system. Routers within an autonomous system  run	 an  interior  routing
       protocol	 like RIP. Only those gateways that connect an autonomous sys‐
       tem to another autonomous system need to run an exterior routing proto‐
       col.  There are two exterior protocols currently supported by GateD:

       EGP  Exterior Gateway Protocol: Originally EGP reachability information
	    was passed into ARPANET/MILNET  "core"  gateways  where  the  best
	    routes were chosen and passed back out to all connected autonomous
	    systems. As the Internet moved toward a less  hierarchical	archi‐
	    tecture, EGP, an exterior routing protocol which assumes a hierar‐
	    chical structure, became less effective.

	    The EGP protocol is described in RFC 827 and RFC 904.

       BGP  Border Gateway Protocol is replacing EGP as the exterior  protocol
	    of	choice. BGP exchanges reachability information between autono‐
	    mous systems, but provides more capabilities than  EGP.  BGP  uses
	    path attributes to provide more information about each route as an
	    aid in selecting the best route. Path attributes may include,  for
	    example,  administrative preferences based on political, organiza‐
	    tional, or security (policy) considerations in the	routing	 deci‐
	    sion.  BGP	supports nonhierarchical topologies and can be used to
	    implement a network structure of equivalent autonomous systems.

	    BGP version 1 is described in RFC 1105, version  2	in  RFC	 1163,
	    version  3	in  RFC	 1267.	 The version 3 MIB is described in RFC
	    1269.  The two documents, RFC  1164	 and  RFC  1268	 describe  the
	    application	 of  version  2 and three in the internet.  A protocol
	    analysis of and experience with BGP version 3 are available in RFC
	    1265  and  RFC  1266.   RFC 1397 talks about advertising a default
	    route in BGP version 2 and 3.  And finally, RFC 1403 describes BGP
	    - OSPF interaction.

   Other Routing Protocols
       Router Discovery
	      The  Router  Discovery  protocol	is used to inform hosts of the
	      availability of hosts it can send packets to and is used to sup‐
	      plement a statically configured default router. This is the pre‐
	      ferred protocol for hosts to  run,  they	are  discouraged  from
	      wiretapping routing protocols.

	      Router Discovery is described in RFC 1256.

Routing Information Protocol (RIP)
       One  of	the most widely used interior gateway protocols is the Routing
       Information Protocol (RIP). RIP is an implementation of a distance-vec‐
       tor,  or	 Bellman-Ford routing protocol for local networks.  It classi‐
       fies routers as active and passive (silent). Active  routers  advertise
       their routes (reachability information) to others; passive routers lis‐
       ten and update their routes based on advertisements, but do not	adver‐
       tise.  Typically,  routers run RIP in active mode, while hosts use pas‐
       sive mode.

       A router running RIP in active mode broadcasts updates  at  set	inter‐
       vals. Each update contains paired values where each pair consists of an
       IP network address and an integer distance to that network. RIP uses  a
       hop  count  metric to measure the distance to a destination. In the RIP
       metric, a router advertises directly connected networks at a metric  of
       1.  Networks which are reachable through one other gateway are two hops
       etc. Thus, the number of hops or hop count along a path	from  a	 given
       source  to  a given destination refers to the number of gateways that a
       datagram would encounter along that path. Using hop counts to calculate
       shortest	 paths does not always produce optimal results. For example, a
       path with hop count 3 that crosses three Ethernets may be substantially
       faster  that  a	path  with  a  hop count 2 that crosses two slow-speed
       serial lines. To compensate for differences in technology many  routers
       advertise artificially high hop counts for slow links.

       As  delivered with most UNIX systems, RIP is run by the routing daemon,
       routed (pronounced route-"d"). A RIP routing daemon dynamically	builds
       on  information	received  through  RIP	updates.   When started up, it
       issues a REQUEST for routing information and then listens for responses
       to the request. If a system configured to supply RIP hears the request,
       it responds with a RESPONSE packet based on information in its  routing
       database.  The  RESPONSE	 packet contains destination network addresses
       and the routing metric for each destination.

       When a RIP RESPONSE packet is received, the routing  daemon  takes  the
       information  and	 rebuilds  the	routing database adding new routes and
       "better" (lower metric) routes to destinations already  listed  in  the
       database.  RIP also deletes routes from the database if the next router
       to that destination says the route contains more than 15	 hops,	or  if
       the  route  is  deleted. All routes through a gateway are deleted if no
       updates are received from that gateway for a specified time period.  In
       general, routing updates are issued every 30 seconds. In many implemen‐
       tations, if a gateway is not heard from for  180	 seconds,  all	routes
       from  that gateway are deleted from the routing database. This 180 sec‐
       ond interval also applies to deletion of specific routes.

       RIP version 2 (more commonly known as RIP II) add additional  capabili‐
       ties  to	 RIP. Some of these capabilities are compatible with RIP I and
       some are not. To avoid supplying information to RIP I routes that could
       be  misinterpreted, RIP II can only use noncompatible features when its
       packets are multicast. On interfaces that are not capable of IP	multi‐
       cast, RIP I compatible packets are used that do not contain potentially
       confusing information.

       Some of the most notable RIP II enhancements are:

       Next hop
	      The primary ones are the ability to advertise a next hop to  use
	      other  than  the	router	supplying the routing update.  This is
	      quite useful when advertising a static route to  a  dumb	router
	      that  does  not  run  RIP	 as  it avoids having packets destined
	      through the dumb router from having to cross a network twice.

	      RIP I routers will ignore next hop information in RIP  II	 pack‐
	      ets.  This may result in packets crossing a network twice, which
	      is exactly what happens with RIP I. So this information is  pro‐
	      vided in RIP I compatible RIP II packets.

       Network Mask
	      RIP  I  assumes that all subnetworks of a given network have the
	      same network mask. It uses this assumption to calculate the net‐
	      work  masks  for	all  routes received. This assumption prevents
	      subnets with different netmasks from being included in RIP pack‐
	      ets.  RIP	 II adds the ability to explicitly specify the network
	      mask with each network in a packet.

	      While RIP I routers will ignore the network mask in RIP II pack‐
	      ets,  their  calculation of the network mask will quite possibly
	      be wrong. For this reason, RIP I compatible RIP II packets  must
	      not  contain  networks that would be misinterpreted.  These net‐
	      work must only be provided in native RIP	II  packets  that  are
	      multicast.

       Authentication
	      RIP  II packets may also contain one of two types of authentica‐
	      tion string that may be used to verify the validity of the  sup‐
	      plied routing data. Authentication may be used in RIP I compati‐
	      ble RIP II packets, but be aware that RIP I routers will	ignore
	      it.

	      The first method is a simple password in which an authentication
	      key of up to 16 characters is included in the  packet.  If  this
	      does  not	 match what is expected, the packet will be discarded.
	      This method provides very little security as it is  possible  to
	      learn the authentication key by watching RIP packets.

	      The second method is still experimental and may change in incom‐
	      patible ways in future releases. This method uses the MD5	 algo‐
	      rithm to create a crypto-checksum of a RIP packet and an authen‐
	      tication key of up to 16 characters. The transmitted packet does
	      not contain the authentication key itself, instead it contains a
	      crypto-checksum, called the digest. The  receiving  router  will
	      perform  a  calculation using the correct authentication key and
	      discard the packet if the digest does not match. In addition,  a
	      sequence	number	is  maintained	to prevent the replay of older
	      packets. This method provides a  much  stronger  assurance  that
	      routing  data  originated from a router with a valid authentica‐
	      tion key.

	      Two authentication  methods  can	be  specified  per  interface.
	      Packets  are  always sent using the primary method, but received
	      packets are checked with both the primary and secondary  methods
	      before  being  discarded. In addition, a separate authentication
	      key is used for non-router queries.

   RIP-I and network masks
       RIP-I derives the network mask of received networks and hosts from  the
       network	mask  of  the  interface  the  packet via which the packet was
       received. If a received network or host is on the same natural  network
       as the interface over which it was received and that network is subnet‐
       ted (the specified mask is more specific than the natural netmask), the
       subnet mask is applied to the destination. If bits outside the mask are
       set, it is assumed to be a host. Otherwise it is assumed to be  a  sub‐
       net.

       On  point-to-point  interfaces,	the  netmask  is applied to the remote
       address. The netmask on these interfaces is ignored if it  matches  the
       natural network of the remote address or is all ones.

       Unlike  in  previous  releases,	the  zero  subnet mask (a network that
       matches the natural network of the interface, but has a more  specific,
       or  longer, network mask) is ignored. If this is not desirable, a route
       filter may be used to reject it.

   The RIP Statement
       rip yes | no | on | off [ {
	   broadcast ;
	   nobroadcast ;
	   nocheckzero ;
	   preference preference ;
	   defaultmetric metric ;
	   query authentication [none | [[simple|md5] password]] ;
	   interface interface_list
	       [noripin] | [ripin]
	       [noripout] | [ripout]
	       [metricin metric]
	       [metricout metric]
	       [version 1]|[version 2 [multicast|broadcast]]
	       [[secondary] authentication [none | [[simple|md5] password]] ;
	   trustedgateways gateway_list ;
	   sourcegateways gateway_list ;
	   traceoptions trace_options ;
       } ] ;

       The rip statement enables or disables RIP. If the rip statement is  not
       specified,  the	default	 is  rip  on  ;.   If enabled, RIP will assume
       nobroadcast when there is only one interface and broadcast  when	 there
       is more than one.

       The options are as follows:

	      broadcast
		     Specifies	that  RIP packets will be broadcast regardless
		     of the number of interfaces present. This is useful  when
		     propagating  static  routes or routes learned from anther
		     protocol into RIP. In some cases, the  use	 of  broadcast
		     when only one network interface is present can cause data
		     packets to traverse a single network twice.

	      nobroadcast
		     Specifies that RIP	 packets  will	not  be	 broadcast  on
		     attached interfaces, even if there are more than one.  If
		     a sourcegateways clause is present, routes will still  be
		     unicast directly to that gateway.

	      nocheckzero
		     Specifies	that  RIP  should  not make sure that reserved
		     fields in incoming version 1 RIP packets are  zero.  Nor‐
		     mally  RIP	 will reject packets where the reserved fields
		     are zero.

	      preference preference
		     Sets the preference for  routes  learned  from  RIP.  The
		     default  preference  is 100. This preference may be over‐
		     ridden by a preference specified in import policy.

	      defaultmetric metric
		     Defines the metric used when advertising routes  via  RIP
		     that were learned from other protocols. If not specified,
		     the default value is 16  (unreachable).  This  choice  of
		     values  requires  you  to	explicitly specify a metric in
		     order to export routes from  other	 protocols  into  RIP.
		     This  metric  may	be overridden by a metric specified in
		     export policy.

	      query authentication [none | [[simple|md5] password]] ;
		     Specifies the authentication required  of	query  packets
		     that do not originate from routers. The default is none.

	      interface interface_list
		     Controls  various	attributes  of sending RIP on specific
		     interfaces. See the section on interface list  specifica‐
		     tion for the description of the interface_list.

		     Note  that if there are multiple interfaces configured on
		     the same subnet, RIP updates will only be sent from first
		     one  one  which RIP output is configured. This limitation
		     is required because of the way the Unix kernel  operates.
		     It will hopefully be removed in a future release.

		     The possible parameters are:

		     noripin
			    Specifies that RIP packets received via the speci‐
			    fied interface will be ignored. The default is  to
			    listen  to	RIP  packets on all nonloopback inter‐
			    faces.

		     ripin  This is the default. This argument may  be	neces‐
			    sary  when noripin is used on a wildcard interface
			    descriptor.

		     noripout
			    Specifies that no RIP packets will be sent on  the
			    specified  interfaces.  The default is to send RIP
			    on all broadcast and nonbroadcast interfaces  when
			    in broadcast mode. The sending of RIP on point-to-
			    point interfaces must be manually configured.

		     ripout This is the default. This  argument	 is  necessary
			    when  it  is desired to send RIP on point-to-point
			    interfaces and may be necessary  when  noripin  is
			    used on a wildcard interface descriptor.

		     metricin metric
			    Specifies the RIP metric to add to incoming routes
			    before they are installed in  the  routing	table.
			    The	 default is the kernel interface metric plus 1
			    (which is the default  RIP	hop  count).  If  this
			    value  is  specified, it will be used as the abso‐
			    lute value. The kernel metric will not  be	added.
			    This option is used to make this router prefer RIP
			    routes learned via the specified interface(s) less
			    than RIP routes from other interfaces.

		     metricout metric
			    Specifies  the  RIP	 metric	 to be added to routes
			    that are send via the specified interface(s).  The
			    default is zero. This option is used to make other
			    routers prefer other sources of  RIP  routes  over
			    this router.

		     version 1
			    Specifies  that RIP packets send via the specified
			    interface(s) will be version 1  packets.  This  is
			    the default.

		     version 2
			    Specifies  that RIP version 2 packets will be sent
			    on the specified interfaces(s).  If	 IP  multicast
			    support   is  available  on	 this  interface,  the
			    default is to send full version 2 packets.	If  it
			    is	not  available, version 1 compatible version 2
			    packets will be sent.

		     multicast
			    Specifies that RIP version	2  packets  should  be
			    multicast on this interface. This is the default.

		     broadcast
			    Specifies  that RIP version 1 compatible version 2
			    packets should be  broadcast  on  this  interface,
			    even if IP multicast is available.

		     [secondary] authentication [none | [simple|md5] password]
			    This  defines  the	authentication type to use. It
			    applies only to RIP version 2 and is  ignored  for
			    RIP-1  packets. The default authentication type is
			    none. If a password is specified, the  authentica‐
			    tion  type defaults to simple. The password should
			    be a quoted string with between 0 and  16  charac‐
			    ters.

			    If	secondary  is specified, this defines the sec‐
			    ondary authentication.  If	omitted,  the  primary
			    authentication  is	specified. The default is pri‐
			    mary  authentication  of  none  and	 no  secondary
			    authentication.

	      trustedgateways gateway_list
		     Defines  the  list of gateways from which RIP will accept
		     updates. The gateway_list is simply a list of host	 names
		     or	 IP  addresses.	 By default, all routers on the shared
		     network are trusted to supply routing information. But if
		     the trustedgateways clause is specified only updates from
		     the gateways in the list are accepted.

	      sourcegateways gateway_list
		     Defines a list of routers	to  which  RIP	sends  packets
		     directly, not through multicast or broadcast. This can be
		     used to send different routing  information  to  specific
		     gateways.	 Updates  to  gateways	in  this  list are not
		     affected by noripout on the interface.

	      traceoptions trace_options
		     Specifies the tracing options for RIP.  (See Trace State‐
		     ments and the RIP specific tracing options below.)

   Tracing options
       The  policy option logs info whenever a new route is announce, the met‐
       ric being announced changes or a route goes or leaves holddown.

       Packet tracing options (which may be  modified  with  detail,  send  or
       recv):

	      packets	All RIP packets.

	      request	RIP information request packets, such as REQUEST, POLL
			and POLLENTRY

	      response	RIP RESPONSE packets, which is the type of packet that
			actually contains routing information.

	      other	Any  other  type  of  packet.  The only valid ones are
			TRACE_ON and TRACE_OFF both of which are ignored.

The Hello Protocol
       It is really better not to use HELLO unless you have  a	specific  need
       for it. We plan to drop it some time around GateD 4.0.

       The  HELLO  protocol is an interior protocol that uses a routing metric
       based on the length of time it takes a packet to make the trip  between
       the  source and the destination. HELLO packets carry timestamp informa‐
       tion which allows receivers to compute the shortest delay paths to des‐
       tinations.  The "best" route is the route with the shortest time delay.
       The unit of time used in HELLO  is  milliseconds.  If  a	 HELLO	update
       packet  takes less than 100 milliseconds to travel between two routers,
       a minimum value of 100 is used for that hop. Thus on networks built  of
       high-speed  interfaces  HELLO essentially defaults to using hop counts.
       As in any routing algorithm, HELLO cannot change routes too rapidly  or
       it  would be unstable. To avoid instabilities, implementations of HELLO
       build in hysteresis and "hesitate" to change  routes  until  they  have
       confidence that the change will be lasting.

       By default HELLO, like RIP, uses the kernel interface metric set by the
       ifconfig command to influence  metric  added  to	 routes	 as  they  are
       installed  in the routing table (metricin).  Since the kernel interface
       metric is in hops, it must be translated into HELLOs  millisecond  met‐
       ric. In order to do that, the following table is used:

	      Hops    HELLO metric
		 0	     0
		 1	   100
		 2	   148
		 3	   219
		 4	   325
		 5	   481
		 6	   713
		 7	  1057
		 8	  1567
		 9	  2322
		10	  3440
		11	  5097
		12	  7552
		13	 11190
		14	 16579
		15	 24564
		16	 30000

   HELLO and network masks
       HELLO  derives the network mask of received networks and hosts from the
       network mask of the interface the  packet  via  which  the  packet  was
       received.  If a received network or host is on the same natural network
       as the interface over which it was received and that network is subnet‐
       ted (the specified mask is more specific than the natural netmask), the
       subnet mask is applied to the destination. If bits outside the mask are
       set,  it	 is assumed to be a host. Otherwise it is assumed to be a sub‐
       net.

       On point-to-point interfaces, the netmask  is  applied  to  the	remote
       address.	 The  netmask on these interfaces is ignored if it matches the
       natural network of the remote address or is all ones.

       Unlike in previous releases, the	 zero  subnet  mask  (a	 network  that
       matches	the natural network of the interface, but has a more specific,
       or longer, network mask) is ignored. If this is not desirable, a	 route
       filter may be used to reject it.

   The Hello Statement
       hello yes | no | on | off [ {
	   broadcast ;
	   nobroadcast ;
	   preference preference ;
	   defaultmetric metric ;
	   interface interface_list
		   [nohelloin] | [helloin]
		   [nohelloout] | [helloout]
		   [metricin metric]
		   [metricout metric] ;
	   trustedgateways gateway_list ;
	   sourcegateways gateway_list ;
	   traceoptions trace_options ;
       } ] ;

       the  hello  statement enables or disables HELLO. If the hello statement
       is not specified, the default is hello  off.  If	 enabled,  HELLO  will
       assume  nobroadcast when there is only one interface and broadcast when
       there is more than one interface.

	      broadcast
		     Specifies that HELLO packets will be broadcast regardless
		     of	 the number of interfaces present. This is useful when
		     propagating static routes or routes learned  from	anther
		     protocol  into HELLO. In some cases, the use of broadcast
		     when only one network interface is present can cause data
		     packets to traverse a single network twice.

	      nobroadcast
		     Specifies	that  HELLO  packets  will not be broadcast on
		     attached interfaces, even if there are more than one.  If
		     a	sourcegateways clause is present, routes will still be
		     unicast directly to that gateway.

	      preference preference
		     Sets the preference for routes learned  from  HELLO.  The
		     default preference is 90. This preference may be overrid‐
		     den by a preference specified in import policy.

	      defaultmetric metric
		     Defines the metric used when advertising routes via HELLO
		     that were learned from other protocols. If not specified,
		     the default value is 30000 (unreachable). This choice  of
		     values  requires  you  to	explicitly specify a metric in
		     order to export routes from other protocols  into	HELLO.
		     This  metric  may	be overridden by a metric specified in
		     export policy.

	      interface interface_list
		     Controls various attributes of sending HELLO on  specific
		     interfaces.  See the section on interface list specifica‐
		     tion for the description of the interface_list.

		     Note that if there are multiple interfaces configured  on
		     the  same	subnet,	 HELLO	updates will only be sent from
		     first one one which HELLO output is configured. This lim‐
		     itation  is  required  because of the way the Unix kernel
		     operates. It  will	 hopefully  be	removed	 in  a	future
		     release.

		     The possible parameters are:

		     nohelloin
			    Specifies  that  HELLO  packets  received  via the
			    specified interface will be ignored.  The  default
			    is	to  listen  to HELLO on all nonloopback inter‐
			    faces.

		     helloin
			    This is the default. This argument may  be	neces‐
			    sary  when	nohelloin is used on a wildcard inter‐
			    face descriptor.

		     nohelloout
			    Specifies that no HELLO packets will  be  sent  on
			    the	 specified  interfaces. The default is to send
			    HELLO on all broadcast and nonbroadcast interfaces
			    when  in  broadcast	 mode. The sending of HELLO on
			    point-to-point interfaces must be manually config‐
			    ured.

		     helloout
			    This  is  the  default. This argument is necessary
			    when it is desired to send HELLO on point-to-point
			    interfaces	and may be necessary when nohelloin is
			    used on a wildcard interface descriptor.

		     metricin metric
			    Specifies the HELLO	 metric	 to  add  to  incoming
			    routes  before  they  are installed in the routing
			    table. The default is the kernel interface	metric
			    plus  1 (which is the default HELLO hop count). If
			    this value is specified, it will be	 used  as  the
			    absolute  value.  The  kernel  metric  will not be
			    added. This option is used	to  make  this	router
			    prefer  HELLO  routes  learned  via	 the specified
			    interface(s) less than  HELLO  routes  from	 other
			    interfaces.

		     metricout metric
			    Specifies  the  HELLO metric to be added to routes
			    that are send via the specified interface(s).  The
			    default is zero. This option is used to make other
			    routers prefer other sources of HELLO routes  over
			    this router.

	      trustedgateways gateway_list
		     Defines the list of gateways from which HELLO will accept
		     updates. The gateway_list is simply a list of host	 names
		     or	 IP  addresses.	 By default, all routers on the shared
		     network are trusted to supply routing information. But if
		     the trustedgateways clause is specified only updates from
		     the gateways in the list are accepted.

	      sourcegateways gateway_list
		     Defines a list of routers to which	 HELLO	sends  packets
		     directly, not through multicast or broadcast. This can be
		     used to send different routing  information  to  specific
		     gateways.	 Updates  to  gateways	in  this  list are not
		     affected by noripout on the interface.

	      traceoptions trace_options
		     Specifies the tracing  options  for  HELLO.   (See	 Trace
		     Statements and the HELLO specific tracing options below.)

       The default preference is 90. The default metric is 30000.

   Tracing options
       The  policy option logs info whenever a new route is announce, the met‐
       ric being announced changes or a route goes or leaves holddown.

       Packet tracing options (which may be modified with detail, send	and/or
       recv):

	      packets
		     All HELLO packets

The OSPF Protocol
       Open  Shortest  Path  Routing  (OSPF) is a shortest path first (SPF) or
       link-state protocol. OSPF is an interior gateway protocol that distrib‐
       utes routing information between routers in a single autonomous system.
       OSPF chooses the least cost path as the best path. Suitable for complex
       networks	 with a large number of routers, OSPF provides equal cost mul‐
       tipath routing where packets to a single destination can	 be  sent  via
       more  than one interface simultaneously. In a link-state protocol, each
       router maintains a database describing the entire AS topology, which it
       builds  out  of the collected link state advertisements of all routers.
       Each participating router  distributes  its  local  state  (the	usable
       interfaces  and reachable neighbors of the router) throughout the AS by
       flooding. Each multiaccess network  that	 has  at  least	 two  attached
       routers	has  a	designated  router and a backup designated router. The
       designated router floods a link state advertisement for the multiaccess
       network	and has other special responsibilities.	 The designated router
       concept reduces the number of adjacencies  required  on	a  multiaccess
       network.

       OSPF  allows  networks  to  be  grouped into areas. Routing information
       passed between areas is abstracted, potentially allowing a  significant
       reduction in routing traffic. OSPF uses four different types of routes,
       listed in order of preference: intra-area, inter-area, type 1  external
       and type 2 external. Intra-area paths have destinations within the same
       area, inter-area paths have destinations in other OSPF areas and Auton‐
       omous  System External (ASE) routes are routes to destinations external
       to the AS. Routes imported into OSPF as type 1 routes are  supposed  to
       be  from	 igps  whose  external metrics are directly comparable to OSPF
       metrics. When a routing decision is  being  made,  OSPF	will  add  the
       internal	 cost  to  the AS Border router to the external metric. Type 2
       ASEs are used for egps whose metrics are not comparable	to  OSPF  met‐
       rics. In this case, only the internal OSPF cost to the AS Border router
       is used in the routing decision.

       From the topology database, each router constructs a tree of the short‐
       est  paths  with	 itself as the root. This shortest-path tree gives the
       route to each destination in the AS. Externally derived routing	infor‐
       mation appears on the tree as leaves. The link-state advertisement for‐
       mat distinguishes between information acquired  from  external  sources
       and  information acquired from internal routers, so there is no ambigu‐
       ity about the source or	reliability  of	 routes.   Externally  derived
       routing	information  (for  example, routes learned from EGP or BGP) is
       passed transparently through the autonomous system and is kept separate
       from  the OSPF internally derived data. Each external route can also be
       tagged by the advertising router,  enabling  a  passing	of  additional
       information between routers on the borders of the autonomous system.

       OSPF  optionally	 includes  type	 of  service  (TOS) routing and allows
       administrators to install multiple routes to a  given  destination  for
       each  type  of service (low delay or high throughput.) A router running
       OSPF uses the destination address and the type of service to choose the
       best route to the destination.

       OSPF  intra-  and  inter-area routes are always imported into the GateD
       routing database with a preference of 10. It would be  a	 violation  of
       the protocol if an OSPF router did not participate fully in the OSPF of
       the area, so it is not possible to override this. Although it is possi‐
       ble to give other routes lower preference values explicitly, it is ill-
       advised to do so.

       Hardware multicast capabilities are also used where possible to deliver
       link-status  messages.	OSPF areas are connected by the backbone area,
       the area with identifier 0.0.0.0. All areas must be logically  contigu‐
       ous  and	 the  backbone is no exception. To permit maximum flexibility,
       OSPF allows the configuration of virtual links enable the backbone area
       to appear contiguous despite the physical reality.

       All  routers  in	 an area must agree on the parameters of that area.  A
       separate copy of	 the  link-state  algorithm  is	 run  for  each	 area.
       Because	of  this,  most	 configuration parameters are defined on a per
       area basis. All routers belonging to an area must agree on the configu‐
       ration  of  that	 area.	Misconfiguration  will lead to adjacencies not
       forming between neighbors, and routing information might not  flow,  or
       even loop.

   Authentication
       All  OSPF  protocol exchanges are authenticated. Authentication guaran‐
       tees that routing information is only imported from trusted routers, to
       protect the Internet and its users. A variety of authentication schemes
       can be used but a single scheme must be configured for each area.  This
       enables	some  areas  to	 use much stricter authentication than others.
       OSPF protocol exchanges may be authenticated. Authentication guarantees
       that routing information is imported only from trusted routers, to pro‐
       tect the Internet and its users. There are two  authentication  schemes
       available.  The first uses a simple authentication key of up to 8 char‐
       acters and is standardized. The second is still experimental  and  uses
       the MD5 algorithm and an authentication key of up to 16 characters.

       The  simple  password  provides	very little protection because in many
       cases it is possible to easily capture packets  from  the  network  and
       learn  the  authentication key. The experimental MD5 algorithm provides
       much more protection as it does not include the authentication  key  in
       the packet.

       The OSPF specification currently specifies that the authentication type
       be configured per area with the ability to configure separate passwords
       per  interface.	This  has  been extended to allow the configuration of
       different authentication types and keys per interface. In  addition  it
       is  possible  to	 specify both a primary and a secondary authentication
       type and key on	each  interface.  Outgoing  packets  use  the  primary
       authentication  type, but incoming packets may match either the primary
       or secondary authentication type and key.

   The OSPF Statement
       ospf yes | no | on | off [ {
	   defaults {
	       preference preference ;
	       cost cost ;
	       tag [ as ] tag ;
	       type 1 | 2 ;
	   } ;
	   exportlimit routes ;
	   exportinterval time ;
	   traceoptions trace_options ;
	   monitorauthkey authkey ;
	   monitorauth none | ( [ simple | md5 ] authkey ) ;
	   backbone | ( area area ) {
	       authtype 0 | 1 | none | simple ;
	       stub [ cost cost] ;
	       networks {
		   network [ restrict ] ;
		   network mask mask [ restrict ] ;
		   network masklen number [ restrict ] ;
		   host host [ restrict ] ;
	       } ;
	       stubhosts {
		   host cost cost ;
	       } ;
	       interface interface_list; [cost cost ] {
		   interface_parameters
	       } ;
	       interface interface_list nonbroadcast [cost cost ] {
		   pollinterval time ;
		   routers {
		       gateway [ eligible ] ;
		   } ;
		   interface_parameters
	       } ;
	       Backbone only:
	       virtuallink neighborid router_id transitarea area {
		   interface_parameters
	       } ;
	   } ;
       } ] ;

       The following are the interface_parameters referred to above.  The  may
       be  specified  on  any  class  of interface and are described under the
       interface clause.

	      enable | disable ;
	      retransmitinterval time ;
	      transitdelay time ;
	      priority priority ;
	      hellointerval time ;
	      routerdeadinterval time ;
	      authkey auth_key ;

       defaults
	      These parameters specify the defaults used when  importing  OSPF
	      ASE  routes  into	 the  gated routing table and exporting routes
	      from the gated routing table into OSPF ASEs.

		 preference preference
			The preference is used to determine  how  OSPF	routes
			compete	 with routes from other protocols in the gated
			routing table.	The default value is 150.

		 cost cost
			The cost is used when exporting a non-OSPF route  from
			the  GateD  routing  table  into  OSPF	as an ASE. The
			default value is 1. This may be explicitly  overridden
			in export policy.

		 tag [ as ] tag
			OSPF  ASE  routes  have a 32 bit tag field that is not
			used by the OSPF protocol, but may be used  by	export
			policy to filter routes. When OSPF is interacting with
			an egp, the tag field may be used to propagate AS path
			information, in which case the as keyword is specified
			and the tag is limited to 12 bits of  information.  If
			not specified, the tag is set to zero.

		 type 1 | 2
			Routes exported from the GateD routing table into OSPF
			default to becoming type 1 ASEs. This default  may  be
			explicitly  changed here and overridden in export pol‐
			icy.

       ASE export rate
	      Because of the nature of	OSPF,  the  rate  at  which  ASEs  are
	      flooded  must  be	 limited.  These two parameters can be used to
	      adjust those rate limits.

		 exportinterval time
			This specifies how often a batch  of  ASE  link	 state
			advertisements	will  be  generated  and  flooded into
			OSPF.  The default is once per second.

		 exportlimit routes
			This parameter specifies how many ASEs will be	gener‐
			ated and flooded in each batch. The default is 100.

       traceoptions trace_options
	      Specifies	 the  tracing options for OSPF.	 (See Trace Statements
	      and the OSPF specific tracing options below.)

       monitorauthkey authkey
	      OSPF state may be queried using the ospf_monitor (This should be
	      a	 hyperlink) utility. This utility sends nonstandard OSPF pack‐
	      ets which generate a text response from OSPF. By	default	 these
	      requests are not authenticated, if an authentication key is con‐
	      figured, the incoming requests must match the specified  authen‐
	      tication key. No OSPF state may be changed by these packets, but
	      the act of querying OSPF can utilize system resources.

       backbone
       area area
	      Each OSPF router must be configured into at least one OSPF area.
	      If  more	than  one area is configured, at least one must the be
	      backbone. The backbone may only be configured using the backbone
	      keyword,	it may not be specified as area 0. The backbone inter‐
	      face may be a virtuallink.

	      authtype 0 | 1 | none | simple
		     OSPF specifies an authentication scheme  per  area.  Each
		     interface	in  the area must use this same authentication
		     scheme although it may use a different authenticationkey.
		     The  currently valid values are none (0) for no authenti‐
		     cation, or simple (1) for simple password authentication.

	      stub [ cost cost]
		     A stub area is one in which there are no ASE routes. If a
		     cost is specified, this is used to inject a default route
		     into the area with the specified cost.

	      networks
		     The networks list describes the scope of an area.	Intra-
		     area  LSAs	 that fall within the specified ranges are not
		     advertised	 into  other  areas  as	  inter-area   routes.
		     Instead,  the  specified ranges are advertised as summary
		     network LSAs. If restrict is specified, the summary  net‐
		     work LSAs are not advertised. Intra-area LSAs that do not
		     fall into any range are also advertised as	 summary  net‐
		     work  LSAs.  This	option is very useful on well designed
		     networks in reducing the amount  of  routing  information
		     propagated	 between  areas.  The entries in this list are
		     either networks, or a subnetwork/mask pair.  See the sec‐
		     tion  on Route Filtering for more detail about specifying
		     ranges.

	      stubhosts
		     This lists specifies directly attached hosts that	should
		     be advertised as reachable from this router and the costs
		     they should be advertised with. Point-to-point interfaces
		     on which it is not desirable to run OSPF should be speci‐
		     fied here.

		     It is also useful to assign a additional address  to  the
		     loopback  interface  (one	not  on	 the  127 network) and
		     advertise it as a stub hosts. If this address is the same
		     one  used	as  the	 router-id, it enables routing to OSPF
		     routers by router-id, instead of  by  interface  address.
		     This  is more reliable than routing to one of the routers
		     interface addresses which may not always be reachable.

	      interface interface_list [cost cost ]
		     This form of the interface clause is used to configure  a
		     broadcast	(which	requires  IP  multicast	 support) or a
		     point-to-point interface. See the	section	 on  interface
		     list  specification  for  the  description	 of the inter‐
		     face_list.

		     Each interface has a cost. The costs of all interfaces  a
		     packet  must  cross  to reach a destination are summed to
		     get the cost to that destination.	The  default  cost  is
		     one, but another nonzero value may be specified.

		     Interface	parameters  common  to all types of interfaces
		     are:

			retransmitinterval time
			       The number of seconds between link state adver‐
			       tisement	   retransmissions   for   adjacencies
			       belonging to this interface.

			transitdelay time
			       The estimated number  of	 seconds  required  to
			       transmit	 a  link state update over this inter‐
			       face. Transitdelay takes into account transmis‐
			       sion and propagation delays and must be greater
			       than 0.

			priority priority
			       A number between 0 and 255 specifying the  pri‐
			       ority  for  becoming  the  designated router on
			       this interface. When two routers attached to  a
			       network	 both  attempt	to  become  designated
			       router, the one with the highest priority wins.
			       A  router  whose router priority is set to 0 is
			       ineligible to become designated router.

			hellointerval time
			       The length of time, in seconds,	between	 Hello
			       packets that the router sends on the interface.

			routerdeadinterval time
			       The number of seconds not hearing Hello packets
			       of a router before the neighbors of the	router
			       will declare it down.

			authkey auth_key
			       Used  by	 OSPF  authentication  to generate and
			       verify the authentication  field	 in  the  OSPF
			       header.	The  authentication key can be config‐
			       ured on a per interface basis. It is  specified
			       by  one	to  eight  decimal digits separated by
			       periods, a one to eight byte hexadecimal string
			       preceded	 by  0x,  or  a one to eight character
			       string in double quotes.

		     Point-to-point interfaces also  support  this  additional
		     parameter:

			nomulticast
			       By default, OSPF packets to neighbors on point-
			       to-point interfaces are sent via the IP	multi‐
			       cast mechanism.	Although, some implementations
			       of IP multicasting for Unix  have  a  bug  that
			       precludes  the  use of IP multicasting on these
			       interfaces. Gated will  detect  this  condition
			       and  fall  back	to  using sending unicast OSPF
			       packets to this point-to-point neighbor.

			       If the use of IP multicasting  is  not  desired
			       because	the  remote  neighbor does not support
			       it, the nomulticast parameter may be  specified
			       to  force the use of unicast OSPF packets. This
			       option may also be used to  eliminate  warnings
			       when Gated detects the bug mentioned above.

	      interface interface_list nonbroadcast [cost cost ]
		     This  form	 of  the interface clause is used to specify a
		     nonbroadcast  interface  on  a  nonbroadcast  multiaccess
		     (NBMA) media.  Since an OSPF broadcast media must support
		     IP multicasting, a broadcast capable media, such as  Eth‐
		     ernet, that does not support IP multicasting must be con‐
		     figured as a nonbroadcast interface.

		     A nonbroadcast interface supports	any  of	 the  standard
		     interface	clauses	 listed	 above, plus the following two
		     that are specific to nonbroadcast interfaces:

			pollinterval time
			       Before adjacency is established with  a	neigh‐
			       bor,  OSPF packets are sent periodically at the
			       specified pollinterval.

			routers
			       By definition it is not possible to send broad‐
			       cast  packets  to  discover OSPF neighbors on a
			       nonbroadcast, so all neighbors must be  config‐
			       ured.  The  list includes one or more neighbors
			       and  an	indication  of	their  eligibility  to
			       become a designated router.

	      virtuallink neighborid router_id transitarea area
		     Virtual  links  are used to establish or increase connec‐
		     tivity of	the  backbone  area.  The  neighborid  is  the
		     router_id of the other end of the virtual link. The tran‐
		     sit area specified must also configured on	 this  system.
		     All  standard  interface parameters defined by the inter‐
		     face clause above may be specified on a virtual link.

   Tracing options
       In addition to the following OSPF specific trace flags,	OSPF  supports
       the  state  which  traces  interface and neighbor state machine transi‐
       tions.

	      lsabuild
		     Link State Advertisement creation

	      spf    Shortest Path First (SPF) calculations

       Packet tracing options (which may be modified  with  detail,  send  and
       recv):

	      hello  OSPF  HELLO  packets which are used to determine neighbor
		     reachability.

	      dd     OSPF Database Description packets which are used in  syn‐
		     chronizing OSPF databases.

	      request
		     OSPF  Link	 State	Request packets which are used in syn‐
		     chronizing OSPF databases.

	      lsu    OSPF Link State Update packets which are used in synchro‐
		     nizing OSPF databases.

	      ack    OSPF Link State Ack packets which are used in synchroniz‐
		     ing OSPF databases.

The Exterior Gateway Protocol (EGP)
       The Exterior Gateway Protocol (EGP) is  an  exterior  routing  protocol
       used  for exchanging routing information with gateways in other autono‐
       mous systems. Unlike interior protocols, EGP propagates only reachabil‐
       ity  indications, not true metrics. EGP updates contain metrics, called
       distances which range from 0 to 255. GateD will only compare  EGP  dis‐
       tances learned from the same AS.	 them.

       Before EGP sends routing information to a remote router, it must estab‐
       lish an adjacency  with	that  router.	This  is  accomplished	by  an
       exchange	 of Hello (not to be confused with the HELLO protocol, or OSPF
       HELLO messages) and I Heard You	(I-H-U)	 messages  with	 that  router.
       Computers  communicating	 via  EGP  are	called	EGP neighbors, and the
       exchange of HELLO and I-H-U messages is	referred  to  as  acquiring  a
       neighbor.  Once the neighbor is acquired, the system polls the neighbor
       for routing information.	 The neighbor responds by  sending  an	update
       containing routing information.	If the system receives a poll from its
       neighbor, it responds with its  own  update  packet.  When  the	system
       receives an update, it includes routes from the update into its routing
       database. If the neighbor fails to respond to three consecutive	polls,
       GateD  assumes that the neighbor is down and removes the routes of that
       neighbor from its database.

   The EGP Statement
       egp yes | no | on | off
       [ {
	   preference preference ;
	   defaultmetric metric ;
	   packetsize number ;
	   traceoptions trace_options ;
	   group
	       [ peeras autonomous_system ]
	       [ localas autonomous_system ]
	       [ maxup number ]
	   {
	       neighbor host
		   [ metricout metric ]
		   [ preference preference ]
		   [ preference2 preference ]
		   [ ttl ttl ]
		   [ nogendefault ]
		   [ importdefault ]
		   [ exportdefault ]
		   [ gateway gateway ]
		   [ lcladdr local_address ]
		   [ sourcenet network ]
		   [ minhello | p1 time ]
		   [ minpoll | p2 time ]
		   [ traceoptions trace_options ]
		       ;
	  } ;
       } ] ;

	      preference preference
		     Sets the preference for  routes  learned  from  RIP.  The
		     default  preference  is 200. This preference may be over‐
		     ridden by a preference specified on the group or neighbor
		     statements or by import policy.

	      defaultmetric metric ;
		     Defines  the metric used when advertising routes via EGP.
		     If not specified, the default value  is  255  which  some
		     systems  may  consider unreachable. This choice of values
		     requires you to explicitly specify a metric when  export‐
		     ing  routes to EGP neighbors. This metric may be overrid‐
		     den by a metric specified on the neighbor or group state‐
		     ments or in export policy.

	      packetsize maxpacketsize
		     This  defines  the expected maximum size of a packet that
		     EGP expects to receive from this neighbor.	 If  a	packet
		     larger than this value is received, it will be incomplete
		     and have to be discarded. The length of this packet  will
		     be	 noted	and  the expected size will be increased to be
		     able to receive a packet of  this	size.  Specifying  the
		     parameter	here  will prevent the first packet from being
		     dropped. If not  specified,  the  default	size  is  8192
		     bytes.  All  packet sizes are rounded up to a multiple of
		     the system page size.

	      traceoptions trace_options
		     Specifies the tracing options for EGP. By	default	 these
		     are inherited from the global trace options. These values
		     may be overridden on a  group  or	neighbor  basis.  (See
		     Trace  Statements	and  the  EGP specific tracing options
		     below.)

	      group  EGP neighbors must be specified as members of a group.  A
		     group  is	usually used to group all neighbors in one au‐
		     tonomous system. Parameters specified on the group clause
		     apply  to	all of the subsidiary neighbors unless explic‐
		     itly overridden on a neighbor clause. Any number of group
		     clauses may specify any number of neighbor clauses.

		     Any  parameters from the neighbor subclause may be speci‐
		     fied on the group clause  to  provide  defaults  for  the
		     whole  group  (which  may	be  overridden	for individual
		     neighbors). In addition, the group	 clause	 is  the  only
		     place to set the following attributes:

			peeras Identifies   the	  autonomous   system	number
			       expected from peers in the group. If not speci‐
			       fied, it will be learned dynamically.

			localas
			       Identifies the autonomous system which GateD is
			       representing to the group. The default is  that
			       which	has   been   set   globally   in   the
			       autonomoussystem statement. This option is usu‐
			       ally only used when masquerading as another au‐
			       tonomous system and its use is discouraged.

			maxup  Specifies the number of neighbors GateD	should
			       acquire	from  this  group.  The	 default is to
			       acquire all of  the  neighbors  in  the	group.
			       GateD  will  attempt to acquire the first maxup
			       neighbors in the order listed. If  one  of  the
			       first  neighbors	 is  not  available,  it  will
			       acquire one further down	 the  list.  If	 after
			       start-up	 GateD does manage to acquire the more
			       desirable  neighbor,  it	 will  drop  the  less
			       desirable one.

	      neighbor neighbor_address
		     Each neighbor subclause defines one EGP neighbor within a
		     group.  The only part of the subclause that  is  required
		     is	 the  neighbor_address	argument which is the symbolic
		     host name or IP address of the neighbor. All other param‐
		     eters are optional.

			preference preference
			       Specifies   the	 preference  used  for	routes
			       learned from these neighbors. This  can	differ
			       from  the default EGP preference set in the egp
			       statement, so that GateD can prefer routes from
			       one  neighbor,  or  group  of  neighbors,  over
			       another.	 This  preference  may	be  explicitly
			       overridden by import policy.

			preference2 preference
			       In  the	case  of  a preference tie, the second
			       preference, preference2 may be  used  to	 break
			       the tie. The default value is 0.

			metricout metric
			       This defines a metric to be used for all routes
			       sent to this neighbor. The value overrides  the
			       default metric set in the egp statement and any
			       metrics specified by export  policy,  but  only
			       for  this  specific neighbor or group of neigh‐
			       bors.

			nogendefault
			       Prevents GateD from generating a default	 route
			       when  EGP  receives  a  valid  update  from its
			       neighbor. The default route is  only  generated
			       when the gendefault option is enabled.

			importdefault
			       Enables	GateD  to  accept  the	default	 route
			       (0.0.0.0) if it is included in a	 received  EGP
			       update.	If  not	 specified,  the default route
			       contained in an	EGP  update  is	 ignored.  For
			       efficiency, some networks have external routers
			       announce a default route to avoid sending large
			       EGP update packets.

			exportdefault
			       Enables	GateD  to  include  the	 default route
			       (0.0.0.0) in  EGP  updates  sent	 to  this  EGP
			       neighbor.  This	allows the system to advertise
			       the default route via EGP. Normally  a  default
			       route is not included in EGP updates.

			gateway gateway
			       If  a  network  is  not shared with a neighbor,
			       gateway specifies a router on an attached  net‐
			       work  to	 be  used  as  the next hop router for
			       routes received from this neighbor. This option
			       is only rarely used.

			lcladdr local_address
			       Specifies  the  address to be used on the local
			       end of the connection with  the	neighbor.  The
			       local  address must be on an interface which is
			       shared with the neighbor or with the gateway of
			       the  neighbor  when  the	 gateway  parameter is
			       used. A session will only  be  opened  when  an
			       interface  with	the  appropriate local address
			       (through which the neighbor or gateway  address
			       is directly reachable) is operating.

			sourcenet network
			       Specifies  the  network queried in the EGP Poll
			       packets. By default this is the network	shared
			       with  neighbors	address specified. If there is
			       no network shared with the neighbor, one of the
			       network	the  neighbor is attached to should be
			       specified. This parameter can also be  used  to
			       specify	a  network  shared  with  the neighbor
			       other than the one on which the EGP packets are
			       sent. This parameter is normally not needed.

			p1 time
			minhello time
			       Sets  the  minimum  acceptable interval between
			       the transmission	 of  EGP  HELLO	 packets.  The
			       default	hello  interval	 is 30 seconds. If the
			       neighbor fails to respond to three hello	 pack‐
			       ets,  GateD  stops trying to acquire the neigh‐
			       bor. Setting a larger interval gives the neigh‐
			       bor  a better chance to respond. Minhello is an
			       alias for the P1 value defined in the EGP spec‐
			       ification.

			p2 time
			minpoll time
			       Sets  the  time	interval  between polls to the
			       neighbor. The default is 120 seconds. If	 three
			       polls are sent without a response, the neighbor
			       is declared "down" and all routes learned  from
			       that  neighbor  are  removed  from  the routing
			       database. A longer polling interval supports  a
			       more  stable  routing  database	but  is not as
			       responsive to routing changes.  Minpoll	is  an
			       alias for the P2 value defined in the EGP spec‐
			       ification.

			ttl ttl
			       By default, GateD sets the  IP  TTL  for	 local
			       neighbors  to  one  and	the  TTL  for nonlocal
			       neighbors to 255. This option is provided  when
			       attempting to communicate with improperly func‐
			       tioning routers that ignore packets sent with a
			       TTL of one.

			traceoptions trace_options
			       Specifies  the  tracing	options	 for  this EGP
			       neighbor. By default these are  inherited  from
			       group  or  EGP global trace options. (See Trace
			       Statements and the EGP specific tracing options
			       below.)

   Tracing options
       The state and policy options work with EGP.

       Packet  tracing	options	 (which	 may be modified with detail, send and
       recv):

	      packets
		     All EGP packets

	      hello  EGP HELLO/I-HEARD-U packets which are used	 to  determine
		     neighbor reachability.

	      acquire
		     EGP  ACQUIRE/CEASE packets which are used to initiate and
		     terminate EGP sessions.

	      update EGP POLL/UPDATE packets which are	used  to  request  and
		     receive reachability updates.

The BGP Protocol
       The  Border Gateway Protocol (BGP) is an exterior routing protocol used
       for exchanging routing information between autonomous systems.  BGP  is
       used  for  exchange of routing information between multiple transit au‐
       tonomous systems as well as between transit and	stub  autonomous  sys‐
       tems.  BGP is related to EGP but operates with more capability, greater
       flexibility, and less required bandwidth. BGP uses path	attributes  to
       provide	more  information about each route, and in particular maintain
       an AS path, which includes the AS number of each autonomous system  the
       route  has transited, providing information sufficient to prevent rout‐
       ing loops in an arbitrary topology.  Path attributes may also  be  used
       to  distinguish	between	 groups	 of routes to determine administrative
       preferences, allowing greater flexibility in determining route  prefer‐
       ence to achieve a variety of administrative ends.

       BGP  supports  two  basic types of sessions between neighbors, internal
       (sometimes referred to as IBGP) and external. Internal sessions are run
       between	routers in the same autonomous system, while external sessions
       run between routers  in	different  autonomous  systems.	 When  sending
       routes  to  an external peer the local AS number is prepended to the AS
       path, hence routes received from an external  peer  are	guaranteed  to
       have  the  AS  number  of  that	peer  at the start of the path. Routes
       received from an internal neighbor will not in general have  the	 local
       AS  number prepended to the AS path, and hence will in general have the
       same AS path that the route had when the originating internal  neighbor
       received	 the route from an external peer. Routes with no AS numbers in
       the path may be legitimately received from  internal  neighbors;	 these
       indicate	 that the received route should be considered internal to your
       own AS.

       The BGP implementation supports three versions  of  the	BGP  protocol,
       versions 2, 3 and 4. BGP versions 2 and 3 are quite similar in capabil‐
       ity and function. They will only propagate classed network routes,  and
       the AS path is a simple array of AS numbers. BGP 4 will propagate fully
       general address-and-mask routes, and the AS path has some structure  to
       represent the results of aggregating dissimilar routes.

       External BGP sessions may or may not include a single metric, which BGP
       calls the Multi-Exit Discriminator, in the path	attributes.   For  BGP
       versions 2 and 3 this metric is a 16-bit unsigned integer, for BGP ver‐
       sion 4 it is a 32-bit unsigned integer. In either case  smaller	values
       of  the	metric are to be preferred. Currently this metric is only used
       to break ties between routes with equal preference from the same neigh‐
       bor  AS.	 Internal  BGP	sessions carry at least one metric in the path
       attributes, which BGP calls the LocalPref.  The size of the  metric  is
       identical  to  the MED. For BGP versions 2 and 3 this metric is consid‐
       ered better when its value is smaller, for version 4 it is better  when
       it is larger. BGP version 4 sessions may optionally carry a second met‐
       ric on internal sessions, this being an internal version of the	Multi-
       Exit  Discriminator.  The use of these metrics is dependent on the type
       of internal protocol processing which is specified.

       BGP collapses routes with similar path attributes into a single	update
       for  advertisement. Routes that are received in a single update will be
       readvertised in a single update. The churn caused  by  the  loss	 of  a
       neighbor	 will  be  minimized and the initial advertisement sent during
       peer establishment will be maximally  compressed.  BGP  does  not  read
       information  from  the  kernel  message-by-message, but fills the input
       buffer. It processes all complete messages in the buffer before reading
       again.  BGP  also does multiple reads to clear all incoming data queued
       on the socket. This feature may cause other protocols to be blocked for
       prolonged intervals by a busy peer connection.

       All  unreachable	 messages are collected into a single message and sent
       prior to reachable routes during a flash update. For these  unreachable
       announcements,  the next hop is set to the local address on the connec‐
       tion, no metric is sent and the path origin is set  to  incomplete.  On
       external connections the AS path in unreachable announcements is set to
       the local AS, on internal connections  the  AS  path  is	 set  to  zero
       length.

       The  BGP	 implementation expects external peers to be directly attached
       to a shared subnet, and expects those  peers  to	 advertise  next  hops
       which  are host addresses on that subnet (though this constraint can be
       relaxed by configuration for testing). For groups  of  internal	peers,
       however,	 there	are several alternatives which may be selected from by
       specifying the group type. Type internal groups expect all peers to  be
       directly	 attached to a shared subnet so that, like external peers, the
       next hops received in BGP advertisements may be used directly for  for‐
       warding.	 Type routing groups instead will determine the immediate next
       hops for routes by using the next hop received with a route from a peer
       as  a forwarding address. This forwarding address is used to look up an
       immediate next hop in routes of the IGP. Such  groups  support  distant
       peers,  but  need to be informed of the IGP whose routes they are using
       to determine immediate next  hops.  Finally,  type  igp	groups	expect
       routes  from  the  group	 peers	to  not be used for forwarding at all.
       Instead they expect that copies of the BGP routes received will also be
       received	 via  an  IGP,	and  that  the BGP routes will only be used to
       determine the path attributes associated	 with  the  IGP	 routes.  Such
       groups  also support distant peers, and also need to be informed of the
       IGP they are running with.

       For internal BGP group types (and for test groups),  where  possible  a
       single  outgoing message is built for all group peers based on the com‐
       mon policy. A copy of the message is sent to every peer in  the	group,
       with  possible adjustments to the next hop field as appropriate to each
       peer. This minimizes the computational load of running large numbers of
       peers  in  these types of groups. BGP allows unconfigured peers to con‐
       nect if an appropriate group has been configured with an allow clause.

   The BGP Statement
       bgp yes | no | on | off
       [ {
	   preference preference ;
	   defaultmetric metric ;
	   traceoptions trace_options ;
	   group type ( external peeras autonomous_system )
	       | ( internal peeras autonomous_system )
	       | ( igp peeras autonomous_system proto proto )
	       | ( routing peeras autonomous_system proto proto
		       interface interface_list )
	       | ( test peeras autonomous_system )
	   {
	       allow {
		   network
		   network mask mask
		   network masklen number
		   all
		   host host
	       } ;
	       peer host
		   [ metricout metric ]
		   [ localas autonomous_system ]
		   [ nogendefault ]
		   [ gateway gateway ]
		   [ preference preference ]
		   [ preference2 preference ]
		   [ lcladdr local_address ]
		   [ holdtime time ]
		   [ version number ]
		   [ passive ]
		   [ sendbuffer number ]
		   [ recvbuffer number ]
		   [ indelay time ]
		   [ outdelay time ]
		   [ keep [ all | none ] ]
		   [ showwarnings ]
		   [ noauthcheck ]
		   [ noaggregatorid ]
		   [ keepalivesalways ]
		   [ v3asloopokay ]
		   [ nov4asloop ]
		   [ logupdown ]
		   [ ttl ttl ]
		   [ traceoptions trace_options ]
		   ;
	   } ;
       } ] ;

       external | internal | igp | test

       The bgp statement enables or disables BGP. By default BGP is  disabled.
       The  default metric for announcing routes via BGP is not to send a met‐
       ric.

	      preference preference
		     Sets the preference for  routes  learned  from  RIP.  The
		     default  preference  is 170. This preference may be over‐
		     ridden by a preference specified on  the  group  or  peer
		     statements or by import policy.

	      defaultmetric metric
		     Defines  the metric used when advertising routes via BGP.
		     If not specified, no metric is  propagated.  This	metric
		     may  be  overridden by a metric specified on the neighbor
		     or group statements or in export policy.

	      traceoptions trace_options
		     Specifies the tracing options for BGP. By	default	 these
		     are inherited from the global trace options. These values
		     may be overridden on a  group  or	neighbor  basis.  (See
		     Trace  Statements	and  the  BGP specific tracing options
		     below.)

   Groups
       BGP peers are grouped by type and the autonomous system of  the	peers.
       Any number of groups may be specified, but each must have a unique com‐
       bination of type and peer autonomous system. There  are	four  possible
       group types:

	      group type external peeras autonomous_system
		     In	 the  classic external BGP group, full policy checking
		     is applied to all incoming and  outgoing  advertisements.
		     The external neighbors must be directly reachable through
		     one of the local interfaces of the machine .  By  default
		     no metric is included in external advertisements, and the
		     next hop is computed with respect to  the	shared	inter‐
		     face.

	      group type internal peeras autonomous_system
		     An	 internal  group  operating where there is no IP-level
		     IGP, for example an SMDS network or MILNET. All neighbors
		     in this group are required to be directly reachable via a
		     single interface.	All next hop information  is  computed
		     with  respect to this interface. Import and export policy
		     may be applied to group advertisements.  Routes  received
		     from  external  BGP or EGP neighbors are by default read‐
		     vertised with the received metric.

	      group type igp peeras autonomous_system proto proto
		     An internal group that runs in association with an	 inte‐
		     rior  protocol.  The  IGP group examines routes which the
		     IGP is exporting and sends an advertisement only  if  the
		     path  attributes could not be entirely represented in the
		     IGP tag mechanism. Only the AS  path,  path  origin,  and
		     transitive	 optional  attributes are sent with routes. No
		     metric is sent, and the next hop  is  set	to  the	 local
		     address  used  by	the  connection. Received internal BGP
		     routes are not used or readvertised. Instead, the AS path
		     information  is  attached	to the corresponding IGP route
		     and the latter is used for readvertisement. Since	inter‐
		     nal  IGP peers are sent only a subset of the routes which
		     the IGP is exporting, the export policy  of  the  IGP  is
		     used.  There  is  no  need to implement the "don't routes
		     from peers in the same group" constraint since the adver‐
		     tised routes are routes that IGP already exports.

	      group  type  routing peeras autonomous_system proto proto inter‐
	      face interface_list
		     An internal group which uses the routes  of  an  interior
		     protocol  to resolve forwarding addresses. A type routing
		     group propagates external routes  between	routers	 which
		     are  not  directly	 connected.  A type routing group com‐
		     putes immediate next hops for these routes by  using  the
		     BGP next hop which arrived with the route as a forwarding
		     address.  The forwarding address is to  be	 resolved  via
		     the  routing  information	of  an	internal protocol.  In
		     essence, internal	BGP  is	 used  to  carry  AS  external
		     routes, while the IGP is expected to only carry AS inter‐
		     nal routes, and the latter is used to find immediate next
		     hops for the former.

		     The  proto	 names	the  interior  protocol	 to be used to
		     resolve BGP route next hops, and may be the name  of  any
		     IGP in the configuration.	By default the next hop in BGP
		     routes advertised to type routing peers will  be  set  to
		     the  local	 address on the BGP connection to those peers,
		     as it is assumed a route to this address will  be	propa‐
		     gated  via	 the  IGP.   The interface_list can optionally
		     provide a list interfaces whose routes  are  carried  via
		     the  IGP  for  which  third  party	 next hops may be used
		     instead.

	      group type test peeras autonomous_system
		     An extension to external BGP  which  implements  a	 fixed
		     policy  using  test  peers. Fixed policy and special case
		     code make test peers relatively inexpensive to  maintain.
		     Test  peers do not need to be on a directly attached net‐
		     work. If GateD and the peer are  on  the  same  (directly
		     attached)	subnet,	 the  advertised  next hop is computed
		     with respect to that network. Otherwise the next  hop  is
		     the  current  next hop of the local machine.  All routing
		     information advertised by and received from a  test  peer
		     is	 discarded,  and all BGP routes that can be advertised
		     are sent back to the test peer. Metrics from  EGP-derived
		     and  BGP-derived  routes  are forwarded in the advertise‐
		     ment. Otherwise no metric is included.

   Group parameters
       The BGP statement has group clauses and peer subclauses. Any number  of
       peer subclauses may be specified within a group. A group clause usually
       defines default parameters for a group of peers, these parameters apply
       to  all	subsidiary peer subclauses.  Any parameters from the peer sub‐
       clause may be specified on the group clause to provide defaults for the
       whole group (which may be overridden for individual peers).

   Specifying peers
       Within  a  group,  BGP peers may be configured in one of two ways. They
       may be explicitly configured with a peer statement, or implicitly  con‐
       figured with the allow statement. Both are described here:

	      allow  The  allow	 clauses  allows for peer connections from any
		     addresses in the specified	 range	of  network  and  mask
		     pairs.  All parameters for these peers must be configured
		     on the group clause. The  internal	 peer  structures  are
		     created  when  an	incoming  open request is received and
		     destroyed when the connection is broken. For more	detail
		     on	 specifying the network/mask pairs, see the section on
		     Route Filtering.

	      peer host
		     A peer clause configures an individual  peer.  Each  peer
		     inherits all parameters specified on a group as defaults.
		     Those default may be overridden by parameters  explicitly
		     specified on the peer subclause.

       Within  each group clause, individual peers can be specified or a group
       of potential peers can be specified using allow. Allow is used to spec‐
       ify  a set of address masks. If GateD receives a BGP connection request
       from any address in the set specified, it will accept it and set	 up  a
       peer relationship.

   Peer parameters
       The  BGP peer subclause allows the following parameters, which can also
       be specified on the group clause. All are optional.

	      metricout metric
		     If specified, this metric is used as the  primary	metric
		     on	 all routes sent to the specified peer(s). This metric
		     overrides the default metric, a metric specified  on  the
		     group and any metric specified by export policy.

	      localas autonomous_system
		     Identifies	 the  autonomous  system which GateD is repre‐
		     senting to this group of  peers..	The  default  is  that
		     which  has	 been  set  globally  in  the autonomoussystem
		     statement.

	      nogendefault
		     Prevents GateD from generating a default route  when  EGP
		     receives  a  valid	 update from its neighbor. The default
		     route is only generated when  the	gendefault  option  is
		     enabled.

	      gateway gateway
		     If a network is not shared with a peer, gateway specifies
		     a router on an attached network to be used	 as  the  next
		     hop  router  for routes received from this neighbor. This
		     parameter is not needed in most cases.

	      preference preference
		     Specifies the preference used  for	 routes	 learned  from
		     these peers. This can differ from the default BGP prefer‐
		     ence set in the bgp statement, so that GateD  can	prefer
		     routes from one peer, or group of peer, over others. This
		     preference may be explicitly overridden by import policy.

	      preference2 preference
		     In the case of a preference tie, the  second  preference,
		     preference2  may  be  used	 to break the tie. The default
		     value is 0.

	      lcladdr local_address
		     Specifies the address to be used on the local end of  the
		     TCP  connection  with  the	 peer.	For external peers the
		     local address must be on an  interface  which  is	shared
		     with  the	peer  or with the gateway of the peer when the
		     gateway parameter is used. A  session  with  an  external
		     peer  will	 only  be  opened  when	 an interface with the
		     appropriate local address	(through  which	 the  peer  or
		     gateway  address is directly reachable) is operating. For
		     other types of peers, a peer session will	be  maintained
		     when  any	interface  with the specified local address is
		     operating. In either case incoming connections will  only
		     be	 recognized  as matching a configured peer if they are
		     addressed to the configured local address.

	      holdtime time
		     Specifies the BGP holdtime value to use when  negotiating
		     the  connection  with this peer, in seconds. According to
		     BGP, if GateD does not receive a  keepalive,  update,  or
		     notification  message  within the period specified in the
		     Hold Time field of the BGP Open  message,	then  the  BGP
		     connection will be closed. The value must be either 0 (no
		     keepalives will be sent) or at least 3.

	      version version
		     Specifies the version of the BGP  protocol	 to  use  with
		     this  peer.  If not specified, the highest supported ver‐
		     sion is used first and version negotiation is  attempted.
		     If	 it  is	 specified, only the specified version will be
		     offered during negotiation. Currently  supported  version
		     are 2, 3 and 4.

	      passive
		     Specifies	that  active  OPENs to this peer should not be
		     attempted. GateD should wait for the  peer	 to  issue  an
		     open.  By	default	 all  explicitly  configured peers are
		     active, they periodically send OPEN  messages  until  the
		     peer responds.

	      sendbuffer buffer_size
	      recvbuffer buffer_size
		     Control the amount of send and receive buffering asked of
		     the kernel. The maximum supported is 65535 bytes although
		     many  kernels  have a lower limit. By default, GateD con‐
		     figures the maximum supported. These parameters  are  not
		     needed on normally functioning systems.

	      indelay time
	      outdelay time
		     Used  to dampen route fluctuations. Indelay is the amount
		     of time a route learned from a BGP peer  must  be	stable
		     before  it	 is  accepted into the gated routing database.
		     Outdelay is the amount of time a route must be present in
		     the  gated routing database before it is exported to BGP.
		     The default value for each is 0, meaning that these  fea‐
		     tures are disabled.

	      keep all
		     Used  to retain routes learned from a peer even if the AS
		     paths of the routes contain one of our exported  AS  num‐
		     bers.

	      showwarnings
		     Causes  GateD  to	issue  warning messages when receiving
		     questionable BGP updates such as duplicate routes	and/or
		     deletions	of  nonexisting	 routes. Normally these events
		     are silently ignored.

	      noauthcheck
		     Normally GateD verifies that  incoming  packets  have  an
		     authentication field of all ones. This option may be used
		     to allow communication with an implementation  that  uses
		     some other form of authentication.

	      noaggregatorid
		     Causes  GateD  to	specify the routerid in the aggregator
		     attribute as zero (instead of its routerid) in  order  to
		     prevent  different	 routers in an AS from creating aggre‐
		     gate routes with different AS paths.

	      keepalivesalways
		     Causes gated to always  send  keepalives,	even  when  an
		     update  could  have  correctly  substituted for one. This
		     allows interoperability with routers  that	 do  not  com‐
		     pletely obey the protocol specifications on this point.

	      v3asloopokay
		     By	 default gated will not advertise routes whose AS path
		     is looped (with an AS appearing more  than	 once  in  the
		     path)  to	version	 3  external  peers. Setting this flag
		     removes this constraint. Ignored  when  set  on  internal
		     groups or peers.

	      nov4asloop
		     Prevents  routes  with  looped AS paths from being adver‐
		     tised to version 4 external peers. This can be useful  to
		     avoid  advertising such routes to peer which would incor‐
		     rectly forward the routes on to version 3 neighbors.

	      logupdown
		     Causes a message to be logged via	the  syslog  mechanism
		     whenever  a  BGP  peer  enters  or leaves the ESTABLISHED
		     state.

	      ttl ttl
		     By default, GateD sets the IP TTL for local peers to  one
		     and the TTL for nonlocal peers to 255. This option mainly
		     is provided when attempting to communicate	 with  improp‐
		     erly  functioning routers that ignore packets sent with a
		     TTL of one.  Not all kernels allow the TTL to  be	speci‐
		     fied for TCP connections.

	      traceoptions trace_options
		     Specifies	the  tracing options for this BGP neighbor. By
		     default these are inherited  from	group  or  BGP	global
		     trace options. (See Trace Statements and the BGP specific
		     tracing options below.)

   Tracing options
       Note that the state option works with BGP, but does  not	 provide  true
       state transition information.

       Packet  tracing	options	 (which	 may be modified with detail, send and
       recv):

	      packets
		     All BGP packets

	      open   BGP OPEN packets which are used to establish a peer rela‐
		     tionship.

	      update BGP UPDATE packets which are used to pass network reacha‐
		     bility information.

	      keepalive
		     BGP KEEPALIVE packets  which  are	used  to  verify  peer
		     reachability.

The ICMP Statement
       On  systems  without the BSD routing socket, gated listens to ICMP mes‐
       sages received by the system. Currently gated only does	processing  on
       ICMP  redirect  packets,	 but  more  functionality  may be added in the
       future, such as support for the router discovery	 messages.  Processing
       of ICMP redirect messages is handled by the redirect statement.

       Currently  the  only reason to specify the icmp statement is to be able
       to trace the ICMP messages that gated receives.

   The ICMP statement
       icmp {
	   traceoptions trace_options ;
       }

       traceoptions trace_options ;
	      Specifies the tracing options for ICMP.  (See  Trace  Statements
	      and the ICMP specific tracing options below.)

   Tracing options
       Packet tracing options (which may be modified with detail and recv):

	      packets
		     All ICMP packets received.

	      redirect
		     Only ICMP REDIRECT packets received.

	      routerdiscovery
		     Only ICMP ROUTER DISCOVERY packets received.

	      info   Only  ICMP	 informational	packets,  which	 include  mask
		     request/response,	   info	    request/response,	  echo
		     request/response and time stamp request/response.

	      error  Only  ICMP	 error	packets,  which include time exceeded,
		     parameter problem, unreachable and source quench.

Redirect Processing
       The redirect code is passed ICMP or ISO redirects learned by monitoring
       ICMP messages, or via the routing socket on systems that support it. It
       processes the redirect request and decides whether to accept the	 redi‐
       rect.  If  the  redirect is accepted, a route is installed in the gated
       routing table with the protocol redirect. Redirects  are	 deleted  from
       the routing table after 3 minutes.

       If GateD determines that a redirect is not acceptable, it tries to fig‐
       ure out if the kernel forwarding table has been	modified.  On  systems
       where  ICMP  messages  are  monitored this is accomplished by trying to
       second guess what the kernel would have done with the redirect. On sys‐
       tems  with  the	routing	 socket, the kernel provides and indication of
       whether the redirect was accepted; GateD ignores	 redirects  that  were
       not processed.

       If  GateD  has determined that the state of the kernel forwarding table
       has been changed, the necessary requests to  the	 kernel	 are  made  to
       restore the correct state.

       Note  that on currently available systems it is not possible to disable
       the processing of ICMP redirects, even when the system  is  functioning
       as  a  router.  To  ignore the effects of redirects, GateD must process
       each one and actively restore any changes it made to the state  of  the
       kernel.	 Because  of  the  mechanisms  involved, there will be windows
       where the effects of redirects are present in the kernel.

       By default, GateD removes redirects when actively participating	in  an
       interior gateway protocol (RIP, HELLO, OSPF or IS-IS). It is not possi‐
       ble to enable redirects once they  have	been  automatically  disabled.
       Listening  to RIP or HELLO in nobroadcast mode does not cause redirects
       to be ignored, nor does the use of EGP and BGP. Redirects must be manu‐
       ally configured off in these cases.

       Note  that in accordance with the latest IETF Router Requirements docu‐
       ment, GateD insures that all ICMP net redirects are processed  as  host
       redirects.  When	 an  ICMP  net	redirect is accepted, GateD issues the
       requests to the kernel to make sure that the kernel forwarding table is
       updated to reflect a host redirect instead of a net redirect.

       The  redirect  statement does not prevent the system from sending redi‐
       rects, only from listening to them.

   The Redirect Statement
       redirect yes | no | on | off
       [ {
	   preference preference ;
	   interface interface_list
	       [ noredirects ] | [redirects ] ;
	   trustedgateways gateway_list ;
	   traceoptions trace_options ;
       } ] ;

	      preference
		     Sets the preference for a route learned from a  redirect.
		     The default is 30.

	      interface interface_list
		     The interface statement allows the enabling and disabling
		     of redirects on an interface-by-interface basis. See  the
		     section  on interface list specification for the descrip‐
		     tion of the interface_list. The possible parameters are:

			noredirects
			       Specifies that redirects received via the spec‐
			       ified interface will be ignored. The default is
			       to accept redirects on all interfaces.

			redirects
			       This is the default. This argument may be  nec‐
			       essary  when  noredirects is used on a wildcard
			       interface descriptor.

	      trustedgateways gateway_list
		     Defines the list of gateways from which redirects will be
		     accepted. The gateway_list is simply a list of host names
		     or addresses. By default, all routers on the shared  net‐
		     work(s)  are  trusted  to	supply	redirects.  But if the
		     trustedgateways clause is specified only  redirects  from
		     the gateways in the list are accepted.

	      traceoptions trace_options
		     There  are no redirect-specific tracing options. All non-
		     error messages are traced under the normal class.

   Tracing options
       There are no Redirect-specific tracing options. All  nonerror  messages
       are traced under the normal class.

The Router Discovery Protocol
       The  Router  Discovery  Protocol	 is  an IETF standard protocol used to
       inform hosts of the existence of routers. It is	intended  to  be  used
       instead	of  having  hosts wiretap routing protocols such as RIP. It is
       used in place of, or  in	 addition  to  statically  configured  default
       routes in hosts.

       The  protocol  is split into to portions, the server portion which runs
       on routers, and the client portion that runs  on	 hosts.	 GateD	treats
       these  much  like  two  separate	 protocols,  only  one of which may be
       enabled at a time.

   The Router Discovery Server
       The Router Discovery Server runs on routers and announces  their	 exis‐
       tence to hosts. It does this by periodically multicasting or broadcast‐
       ing a Router Advertisement to each interface on which  it  is  enabled.
       These Router Advertisements contain a list of all the routers addresses
       on a given interface and their preference for use as a default router.

       Initially these Router Advertisements occur  every  few	seconds,  then
       fall  back  to every few minutes. In addition, a host may send a Router
       Solicitation to which the router will respond  with  a  unicast	Router
       Advertisement  (unless  a  multicast  or broadcast advertisement is due
       momentarily).

       Each Router Advertisement contains a Advertisement Lifetime field indi‐
       cating  for  how long the advertised addresses are valid. This lifetime
       is configured such that	another	 Router	 Advertisement	will  be  sent
       before the lifetime has expired. A lifetime of zero is used to indicate
       that one or more addresses are no longer valid.

       On systems supporting IP multicasting, the Router Advertisements are by
       default send to the all-hosts multicast address 224.0.0.1. However, the
       use of broadcast may be specified. When Router Advertisements are being
       sent  to the all-hosts multicast address, or an interface is configured
       for the limited-broadcast address  255.255.255.255,  all	 IP  addresses
       configured  on the physical interface are included in the Router Adver‐
       tisement. When the Router advertisements are being sent	to  a  net  or
       subnet  broadcast,  only the address associated with that net or subnet
       is included.

   The Router Discovery Server Statement
       routerdiscovery server yes | no | on | off [ {
	   traceoptions trace_options ;
	   interface interface_list
	       [ minadvinterval time ]
	       [ maxadvinterval time ]
	       [ lifetime time ]
	       ;
	   address interface_list
	       [ advertise ] | [ ignore ]
	       [ broadcast ] | [ multicast ]
	       [ ineligible ] | [ preference preference ]
	       ;
       } ] ;

	      traceoptions trace_options
		     Specifies the  Router  Discovery  tracing	options.  (See
		     Trace  Statements and the Router Discovery specific trac‐
		     ing options below.)

	      interface interface_list
		     Specifies the parameters that apply  to  physical	inter‐
		     faces.  Note  a  slight difference in convention from the
		     rest of GateD, interface specifies just  physical	inter‐
		     faces (such as le0, ef0 and en1), while address specifies
		     protocol (in this case IP) addresses.

		     Interface parameters are:

			maxadvinterval time
			       The maximum time allowed between sending broad‐
			       cast  or	 multicast  Router Advertisements from
			       the interface. Must be no less than  4  and  no
			       more  than  30:00 (30 minutes or 1800 seconds).
			       The default is 10:00 (10 minutes	 or  600  sec‐
			       onds).

			minadvinterval time
			       The  minimum time allowed between sending unso‐
			       licited broadcast or  multicast	Router	Adver‐
			       tisements  from	the interface. Must be no less
			       than 3 seconds and no greater than maxadvinter‐
			       val. The default is 0.75 * maxadvinterval.

			lifetime time
			       The  lifetime  of  addresses in a Router Adver‐
			       tisement. Must be no less  than	maxadvinterval
			       and  no greater than 2:30:00 (two hours, thirty
			       minutes or 9000 seconds). The default  is  3  *
			       maxadvinterval.

	      address interface_list
		     Specifies	the parameters that apply to the specified set
		     of addresses on this physical interfaces. Note  a	slight
		     difference	 in  convention from the rest of GateD, inter‐
		     face specifies just physical interfaces (such as le0, ef0
		     and  en1), while address specifies protocol (in this case
		     IP) addresses.

			advertise
			       Specifies that the specified address(es) should
			       be  included  in Router Advertisements. This is
			       the default.

			ignore Specifies that the specified address(es) should
			       not be included in Router Advertisements.

			broadcast
			       Specifies  that the given address(es) should be
			       included in a  broadcast	 Router	 Advertisement
			       because	this system does not support IP multi‐
			       casting, or some hosts on attached  network  do
			       not  support IP multicasting. It is possible to
			       mix addresses on a physical interface such that
			       some  are included in a broadcast Router Adver‐
			       tisement and some are included in  a  multicast
			       Router  Advertisement.  This  is the default if
			       the router does not support IP multicasting.

			multicast
			       Specifies that  the  given  address(es)	should
			       only  be	 included in a multicast Router Adver‐
			       tisement. If the system	does  not  support  IP
			       multicasting,   the  address(es)	 will  not  be
			       included. If the system supports IP  multicast‐
			       ing,  the default is to include the address(es)
			       in a  multicast	Router	Advertisement  if  the
			       given  interface	 supports IP multicasting.  If
			       the given interface does not support IP	multi‐
			       casting,	 the address(es) will be included in a
			       broadcast Router Advertisement.

			preference preference
			       The  preferability  of  the  address(es)	 as  a
			       default	 router	 address,  relative  to	 other
			       router addresses on the same subnet. A  32-bit,
			       signed,	twos-complement	 integer,  with higher
			       values meaning more preferable. Note  that  hex
			       80000000	 may  only be specified as ineligible.
			       The default is 0.

			ineligible
			       Specifies that the given	 address(es)  will  be
			       assigned	 a  preference of (hex 80000000) which
			       means that it is not eligible to be the default
			       route for any hosts.

			       This  is useful when the address(es) should not
			       be used as a default route, but	are  given  as
			       the  next  hop in an ICMP redirect. This allows
			       the hosts to verify that	 the  given  addresses
			       are up and available.

   The Router Discovery Client
       A  host	listens	 for Router Advertisements via the all-hosts multicast
       address (224.0.0.1) if IP multicasting is available and enabled, or  on
       the  interface  broadcast  address. When starting up, or when reconfig‐
       ured, a host may send a few Router  Solicitations  to  the  all-routers
       multicast address, 224.0.0.2, or the interface broadcast address.

       When a Router Advertisement with nonzero lifetime is received, the host
       installs a default route to each of the advertised  addresses.  If  the
       preference  ineligible, or the address is not on an attached interface,
       the route is marked unusable but retained. If the preference is usable,
       the  metric  is set as a function of the preference such that the route
       with the best preference is used. If more than  one  address  with  the
       same preference is received, the one with the lowest IP address will be
       used. These default routes are not exportable to other protocols.

       When a Router Advertisement with a zero lifetime is received, the  host
       deletes	all  routes  with next-hop addresses learned from that router.
       In addition, any routers learned from ICMP redirects pointing to	 these
       addresses  will	be  deleted. The same will happen when a Router Adver‐
       tisement is not received to refresh these routes	 before	 the  lifetime
       expires.

   The Router Discovery Client Statement
       routerdiscovery client yes | no | on | off [ {
	   traceoptions trace_options ;
	   preference preference ;
	   interface interface_list
	       [ enable ] | [ disable ]
	       [ broadcast ] | [ multicast ]
	       [ quiet ] | [ solicit ]
	       ;
       } ] ;

	      traceoptions trace_options
		     Specifies the tracing options for OSPF. (See Trace State‐
		     ments and the OSPF specific tracing options below.)

	      preference preference ;
		     Specifies the preference of all Router Discovery  default
		     routes.  The default is 55.

	      interface interface_list
		     Specifies	the  parameters	 that apply to physical inter‐
		     faces. Note a slight difference in	 convention  from  the
		     rest  of  GateD, interface specifies just physical inter‐
		     faces (such as le0, ef0 and en1).	The  Router  Discovery
		     Client  has  no  parameters  that apply only to interface
		     addresses.

			enable	     Specifies that Router Discovery should be
				     performed	on the specified interface(s).
				     This is the default.

			disable	     Specifies that  Router  Discovery	should
				     not  be performed on the specified inter‐
				     face(s).

			broadcast    Specifies	 that	Router	 Solicitations
				     should  be	 broadcast  on	the  specified
				     interface(s). This is the default	if  IP
				     multicast	support	 is  not  available on
				     this host or interface.

			multicast    Specifies	 that	Router	 Solicitations
				     should  be	 multicast  on	the  specified
				     interface(s).  If	IP  multicast  is  not
				     available	on this host and interface, no
				     solicitation  will	 be   performed.   The
				     default  is to multicast Router Solicita‐
				     tions if the host and  interface  support
				     it.   Otherwise  Router Solicitations are
				     broadcast.

			quiet	     Specifies that  no	 Router	 Solicitations
				     will  be  sent  on	 this  interface, even
				     though  Router  Discovery	will  be  per‐
				     formed.

			solicit	     Specifies	that  initial Router Solicita‐
				     tions will be  sent  on  this  interface.
				     This is the default.

   Tracing options
       The  Router  Discovery  Client  and Server support the state trace flag
       which traces various protocol occurrences.

	      state	State transitions
       The Router Discovery Client and Server  do  not	directly  support  any
       packet  tracing options, tracing of router discovery packets is enabled
       via the ICMP Statement.

The Kernel Statement
       While the kernel interface is not technically a	routing	 protocol,  it
       has many characteristics of one, and GateD handles it similarly to one.
       The routes GateD chooses to install in the kernel forwarding table  are
       those that will actually be used by the kernel to forward packets.

       The add, delete and change operations GateD must use to update the typ‐
       ical kernel forwarding table take a nontrivial amount  of  time.	  This
       does  not  present  a  problem  for older routing protocols (RIP, EGP),
       which are not particularly time critical and do not easily handle  very
       large numbers of routes anyway. The newer routing protocols (OSPF, BGP)
       have stricter timing requirements and are often used  to	 process  many
       more  routes.  The  speed of the kernel interface becomes critical when
       these protocols are used.

       To prevent GateD from  locking  up  for	significant  periods  of  time
       installing  large  numbers  of  routes (up to a minute or more has been
       observed on real networks), the processing of these routes is now  done
       in  batches.  The size of these batches may be controlled by the tuning
       parameters described below, but normally the  default  parameters  will
       provide the proper functionality.

       During  normal  shutdown	 processing,  GateD  normally  deletes all the
       routes it has installed in the  kernel  forwarding  table,  except  for
       those marked with retain. Optionally, GateD can leave all routes in the
       kernel forwarding table by  not	deleting  any  routes.	In  this  case
       changes will be made to insure that routes with a retain indication are
       installed in the table. This is useful on systems with large numbers of
       routes  as  it  prevents	 the  need to re-install the routes when GateD
       restarts. This can greatly reduce the time it takes to recover  from  a
       restart.

   Forwarding tables and Routing tables
       The  table  in  the kernel that controls the forwarding of packets is a
       forwarding table, also know in ISO speak as  a  forwarding  information
       base,  or  FIB.	The  table that GateD uses internally to store routing
       information it learns from routing protocols is a routing table,	 known
       in  ISO	speak as a routing information base, or RIB. The routing table
       is used to collect and store routes from various	 protocols.  For  each
       unique  combination of network and mask an active route is chosen, this
       route will be the one with the best (numerically smallest)  preference.
       All the active routes are installed in the kernel forwarding table. The
       entries in this table are what the  kernel  actually  uses  to  forward
       packets.

   Updating the Forwarding Table
       There  are  two	main  methods  of updating the kernel FIB, the ioctl()
       interface and the routing socket interface.  Their various characteris‐
       tics are described here.

   Updating the Forwarding Table with the ioctl interface
       The  ioctl  interface to the forwarding table was introduced in BSD 4.3
       and widely distributed in BSD 4.3. This is a one-way interface, it only
       allows  GateD  to  update  the  kernel forwarding table. It has several
       other limitations:

	      Fixed subnet masks
		     The BSD 4.3 networking code assumed that all subnets of a
		     given  network  had the same subnet mask. This limitation
		     is enforced by the kernel. The network mask is not stored
		     in	 the  kernel  forwarding  table, but determined when a
		     packet is forwarded by searching for  interfaces  on  the
		     same network.

	      One way interface
		     GateD  is able to update the kernel forwarding table, but
		     it is not aware of other modifications of the  forwarding
		     table. GateD is able to listen to ICMP messages and guess
		     how the kernel has	 updated  the  forwarding  table  with
		     response to ICMP redirects.

	      Blind updates
		     GateD is not able to detect changes to the forwarding ta‐
		     ble resulting from the use of the route  command  by  the
		     system administrator. Use of the route command on systems
		     that use the ioctl() interface  is	 strongly  discouraged
		     while GateD is running.

	      Changes not supported
		     In	 all  known implementations, there is no change opera‐
		     tion supported, to change a route that exists in the ker‐
		     nel, the route must be deleted and a new one added.

   Updating the Forwarding Table with the routing socket interface
       The  routing socket interface to the kernel forwarding table was intro‐
       duced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved
       in  BSD	4.4.   This  interface	is  simply  a socket, similar to a UDP
       socket, on which the kernel and GateD exchange messages. It has several
       advantages over the ioctl() interface:

	      Variable subnet masks
		     The network mask is passed to the kernel explicitly. This
		     allows different masks to be used on subnets of the  same
		     network.  It  also allows routes with masks that are more
		     general than the natural mask to be used. This  is	 known
		     as classless routing.

	      Two way interface
		     Not  only	is  GateD able to change the kernel forwarding
		     table with this interface, but the kernel can also report
		     changes to the forwarding table to GateD. The most inter‐
		     esting of these is an indication that a redirect has mod‐
		     ified  the kernel forwarding table; this means that gated
		     no longer needs to monitor ICMP messages to  learn	 about
		     redirects.	 Plus,	there  is an indication of whether the
		     kernel processed the redirect, GateD  can	safely	ignore
		     redirect messages that the kernel did not process.

	      Updates visible
		     Changes  to the routing table by other processes, includ‐
		     ing the  route  command  are  received  via  the  routing
		     socket.  This allows GateD to insure that the kernel for‐
		     warding table is in sync with the routing table. Plus  it
		     allows  the  system  administrator the ability to do some
		     operations with the route command while gated is running.

	      Changes supported
		     There is a functioning change message that allows	routes
		     in	 the  kernel to be atomically changed. Some early ver‐
		     sions of the routing socket code had bugs in  the	change
		     message  processing.  There are compilation time and con‐
		     figuration	 time  options	that  cause  delete  and   add
		     sequences to be used in lieu of change messages.

	      Expandable
		     New levels of kernel/GateD communications may be added by
		     adding new message types.

   Reading the Forwarding Table
       When GateD starts up it reads the kernel forwarding table and  installs
       corresponding routes in the routing table. These routes are called rem‐
       nants and are timed out after a configured interval (which defaults  to
       3  minutes),  or	 as  soon  as a more attractive route is learned. This
       allows forwarding to occur during the time it takes the routing	proto‐
       cols to start learning routes.

       There  are three main methods for reading the forwarding table from the
       kernel.

   Reading forwarding table via kmem
       On many systems, especially those based on BSD  4.3,  GateD  must  have
       knowledge  of  the kernel data structures and can go into the kernel to
       read the current state of forwarding table. This	 method	 is  slow  and
       subject	to error if the kernel forwarding table is updated while GateD
       is in the middle of reading it. This can happen if the system  adminis‐
       trator  uses the route command, or an ICMP redirect message is received
       while GateD is starting up.

       Due to an oversight some systems, such as OSF/1, which are based on BSD
       4.3  Reno or later, do not have the getkerninfo() system call described
       below which allows GateD to read routes from the	 kernel	 without  know
       about  kernel  internal structures. On these systems it is necessary to
       read the kernel radix tree from the kernel by poking around  in	kernel
       memory.	This is even more error prone than reading the hash based for‐
       warding table.

   Reading the forwarding table via getkerninfo/sysctl
       Besides the routing socket, BSD 4.3 Reno introduced  the	 getkerninfo()
       system call. This call allows a user process (of which GateD is one) to
       read various information from the kernel without knowledge of the  ker‐
       nel  data  structures.  In  the	case  of  the  forwarding table, it is
       returned to gated atomically as a series of  routing  socket  messages.
       This prevents the problem associated with the forwarding table changing
       while GateD is in the process of reading it.

       BSD 4.4 changed the getkerninfo() interface into	 the  sysctl()	inter‐
       face, which takes different parameters, but otherwise functions identi‐
       cally.

   Reading the forwarding table via OS specific methods
       Some operating systems, for example SunOS 5, define their own method of
       reading	the kernel forwarding table. The SunOS 5 version is similar in
       concept to the getkerninfo() method.

   Reading the interface list
       The kernel support subsystem of GateD is responsible  for  reading  the
       status  of  the	kernel	physical and protocol interfaces periodically.
       GateD detects changes in the interface list and notifies the  protocols
       so  they	 can  start  or stop instances or peers. The interface list is
       read one of two ways:

   Reading the interface list with SIOCGIFCONF
       On systems based on BSD 4.3, 4.3 Reno and 4.3 Net/2  the	 interface  is
       used  to	 read  the  kernel interface list. Using this method a list of
       interfaces and some basic information about them	 is  returned  by  the
       call.   Other  information  must	 be learned by issuing other ioctls to
       learn the interface  network  mask,  flags,  MTU,  metric,  destination
       address	(for  point-to-point  interfaces)  and	broadcast address (for
       broadcast capable interfaces).

       GateD reads re-reads this list every 15	second	looking	 for  changes.
       When  the routing socket is in use, it also re-reads it whenever a mes‐
       sages  is  received  indicating	a  change  in  routing	configuration.
       Receipt of a SIGUSR2 signal also causes GateD to re-read the list. This
       interval may be explicitly configured in the interface configuration.

   Reading the interface list with sysctl
       BSD 4.4 added the ability to read the kernel  interface	list  via  the
       sysctl  system  call.  The interface status is returned atomically as a
       list of routing socket messages which GateD  parses  for	 the  required
       information.

       BSD  4.4	 also added routing socket messages to report interface status
       changes immediately. This allows GateD to react quickly to  changes  in
       interface configuration.

       When this method is in use, GateD re-reads the interface list only once
       a minute. It also re-reads it on routing table changes indications  and
       when  a SIGUSR2 is received. This interval may be explicitly configured
       in the interface configuration.

   Reading interface physical addresses
       Later version of the getkerninfo() and sysctl() interfaces  return  the
       interface  physical  addresses as part of the interface information. On
       most systems where this information is not returned,  GateD  scans  the
       kernel physical interface list for this information for interfaces with
       set, assuming that their drivers are handled the same as Ethernet driv‐
       ers.  On	 some  systems,	 such  as SunOS 4 and SunOS 5, system specific
       interfaces are used to learn this information

       The interface physical addresses are useful for IS-IS,  for  IP	proto‐
       cols, they are not currently used, but may be in the future.

   Reading kernel variables
       At startup, GateD reads some special variables out of the kernel.  This
       is usually done with the nlist (or kvm_nlist)  system  call,  but  some
       systems use different methods.

       The variables read include the status of UDP checksum creation and gen‐
       eration, IP forwarding and kernel version (for informational purposes).
       On systems where the routing table is read directly from kernel memory,
       the root of the hash table or radix tree routing table is read. On sys‐
       tems  where  interface  physical	 addresses  are	 not supplied by other
       means, the root of the interface list is read.

   Special route flags
       The later BSD based kernel support the special  route  flags  described
       here.

	      RTF_REJECT
		     Instead  of  forwarding  a	 packet	 like  a normal route,
		     routes with RTF_REJECT cause packets to  be  dropped  and
		     unreachable  messages  to	be sent to the packet origina‐
		     tors. This flag is only valid on routes pointing  at  the
		     loopback interface.

	      RTF_BLACKHOLE
		     Like the RTF_REJECT flag, routes with RTF_BLACKHOLE cause
		     packets to be dropped, but unreachable messages  are  not
		     sent.  This  flag is only valid on routes pointing at the
		     loopback interface.

	      RTF_STATIC
		     When GateD starts, it reads all the routes	 currently  in
		     the kernel forwarding table. Besides interface routes, it
		     usually marks everything else as a remnant from a	previ‐
		     ous run of GateD and deletes it after a few minutes. This
		     means that routes added with the route command  will  not
		     be retained after GateD has started.

		     To fix this the RTF_STATIC flag was added. When the route
		     command is used to install a route that is not an	inter‐
		     face  route  it sets the RTF_STATIC flag. This signals to
		     GateD that said route was added by the  systems  adminis‐
		     trator and should be retained.

   Kernel Configuration
       kernel {
	   options
	       [ nochange ]
	       [ noflushatexit ]
	       [ remnantholdtime time ]
	       ;
	   routes number ;
	   flash
	       [ limit number ]
	       [ type interface | interior | all ]
	       ;
	   background
	       [ limit number ]
	       [ priority flash | higher | lower ]
	       ;
	   traceoptions trace_options ;
       } ;

	      options option_list
		     Configure kernel options. The valid options are:

			nochange
			       On  systems  supporting the routing socket this
			       insures that changes  operations	 will  not  be
			       performed,  only deletes and adds. This is use‐
			       ful on early versions  of  the  routing	socket
			       code where the change operation was broken.

			noflushatexit
			       During normal shutdown processing GateD deletes
			       all routes from	the  kernel  forwarding	 table
			       that  do	 not  have  a  retain  indication. The
			       noflushatexit option prevents  route  deletions
			       at  shutdown.  Instead,	routes are changed and
			       added to make sure that all the	routes	marked
			       with retain get installed.

			       This  is	 handy	on  systems  with thousands of
			       routes. Upon startup GateD  will	 notice	 which
			       routes  are  in the kernel forwarding table and
			       not have add them back.

			remnantholdtime time
			       Normally remnant routes read  from  the	kernel
			       forwarding  table  at  startup are timed out in
			       three minutes or as soon as they	 are  overrid‐
			       den. This option allows the interval to be con‐
			       figured to a value between zero and 15 minutes.
			       Setting	it  to	zero causes these routes to be
			       deleted immediately.

	      routes number
		     On some systems kernel memory is at a premium. With  this
		     parameter	a limit can be placed on the maximum number of
		     routes GateD will install in the kernel.  Normally	 gated
		     adds/changes/deletes  routes in interface/internal/exter‐
		     nal order.	 It queues interface routes first, followed by
		     internal  routes,	followed  by external routes, and pro‐
		     cesses the queue from the beginning. If a this  parameter
		     is	 specified  and the limit is hit, GateD does two scans
		     of the list instead. On the first scan it	does  deletes,
		     and  also	deletes all changed routes, turning the queued
		     changes into adds. It then rescans the list doing adds in
		     interface/internal/external order until it hits the limit
		     again. This will  tend  to	 favor	internal  routes  over
		     external  routes.	The default is not to limit the number
		     of routes in the kernel forwarding table.

	      flash  When routes change, the process of notifying  the	proto‐
		     cols  is called a flash update. The kernel forwarding ta‐
		     ble interface is the first to  be	notified.  Normally  a
		     maximum  of  20  interface routes may be processed during
		     one flash update. The  flash  command  allows  tuning  of
		     these parameters.

			limit number
			       Specifies  the  maximum	number of routes which
			       may be processed during one flash  update.  The
			       default	is  20.	 A  value of -1 will cause all
			       pending route changes of the specified type  to
			       be processed during the flash update.

			type interface | interior | all
			       Specifies  the type of routes that will be pro‐
			       cessed during a flash update.  Interior	speci‐
			       fies  that  interior routes (See the definition
			       of interior gateway  protocols)	will  also  be
			       installed. All specifies the inclusion of exte‐
			       rior routes (See	 the  definition  of  exterior
			       gateway	protocols)  as	well.  The  default is
			       interface which specifies that  only  interface
			       routes will be installed during a flash update.

		     Specifying	 flash	limit  -1  all causes all routes to be
		     installed during the flash update; this mimics the behav‐
		     ior of previous versions of GateD.

	      background
		     Since only interface routes are normally installed during
		     a flash update, the remaining  routes  are	 processed  in
		     batches  in the background, that is, when no routing pro‐
		     tocol traffic is being received. Normally, 120 routes are
		     installed	at a time to allow other tasks to be performed
		     and this background processing is done at lower  priority
		     than  flash updates the following parameters allow tuning
		     of these parameters:

			limit number
			       Specifies the number of route which may be pro‐
			       cessed at during one batch. The default is 120.

			priority flash | higher | lower
			       Specifies  the  priority	 of  the processing of
			       batches of kernel updates  in  relationship  to
			       the  flash  update  processing.	The default is
			       lower which means that flash updates  are  pro‐
			       cessed  first. To process kernel updates at the
			       same priority as flash updates, specify	flash;
			       to process them at a lower priority, use lower.

   Tracing options
       While  the  kernel  interface is not technically a routing protocol, in
       many cases it is handled as one. The following two symbols  make	 sense
       when  entered  from  the	 command line since the code that uses them is
       executed before the trace file is parsed.

	      symbols
		     Symbols read from	the  kernel,  by  nlist()  or  similar
		     interface.

	      iflist Interface	list  scan. This option is useful when entered
		     from the command line as the first interface list scan is
		     performed before the configuration file is parsed.

       The  following  tracing options may only be specified in the configura‐
       tion file. They are not valid from the command line.

	      remnants
		     Routes read from the kernel when GateD starts.

	      request
		     Requests by GateD to Add/Delete/Change routes in the ker‐
		     nel forwarding table.

Static Statements
       Static  statements  define  the	static routes used by GateD.  A single
       static statement can specify any number routes.	The static  statements
       occur  after  protocol  statements and before control statements in the
       gated.conf file. Any number of static statements may be specified, each
       containing  any number of static route definitions. These routes can be
       overridden by routes with better preference values.

       static {
	   ( host host ) | default |
	   ( network [ ( mask mask ) | ( masklen number ) ] )
	       gateway gateway_list
	       [ interface interface_list ]
	       [ preference preference ]
	       [ retain ]
	       [ reject ]
	       [ blackhole ]
	       [ noinstall ] ;
	   ( network [ ( mask mask ) | ( masklen number ) ] )
	       interface interface
	       [ preference preference ]
	       [ retain ]
	       [ reject ]
	       [ blackhole ]
	       [ noinstall ] ;
       } ;

	      host host gateway gateway_list
	      ( network [ ( mask mask ) | ( masklen number ) ] )
	      default gateway gateway_list
		     This is the most general form of the static statement. It
		     defines  a	 static	 route	through	 one or more gateways.
		     Static routes are installed when one or more of the gate‐
		     ways  listed  are	available  on directly attached inter‐
		     faces. If more than one eligible gateways are  available,
		     they  are limited by the number of multipath destinations
		     supported	(this  compile	time  parameter	 is  currently
		     almost always one on Unix).

		     Parameters for static routes are:

		     interface interface_list
			    When  this	parameter  is  specified, gateways are
			    only considered valid when	they  are  on  one  of
			    these interfaces.See the section on interface list
			    specification for the description  of  the	inter‐
			    face_list.

		     preference preference
			    This  option selects the preference of this static
			    route.  The preference  controls  how  this	 route
			    competes  with  routes  from  other protocols. The
			    default preference is 60.

		     retain Normally gated removes all routes except interface
			    routes  from  the kernel forwarding table during a
			    graceful shutdown.	The retain option may be  used
			    to	prevent	 specific  static  routes  from	 being
			    removed. This is useful to insure that some	 rout‐
			    ing is available when gated is not running.

		     reject Instead  of	 forwarding  a	packet	like  a normal
			    route, reject routes cause packets to  be  dropped
			    and	 unreachable messages to be sent to the packet
			    originators. Specifying this  option  causes  this
			    route  to  be installed as a reject route. Not all
			    kernel forwarding engines support reject routes.

		     blackhole
			    A blackhole route is the same as  a	 reject	 route
			    except  that  unreachable  messages	 are  not sup‐
			    ported.

		     noinstall
			    Normally the route with the lowest	preference  is
			    installed  in  the	kernel forwarding table and is
			    the route exported to other protocols. When	 noin‐
			    stall  is  specified  on  a	 route, it will not be
			    installed in the kernel forwarding table  when  it
			    is	active,	 but  it  will still be eligible to be
			    exported to other protocols.

	      ( network [ ( mask mask ) | ( masklen number  )  ]  )  interface
	      interface
		     This  form defines a static interface route which is used
		     for primitive support of multiple	network	 addresses  on
		     one interface.  The preference, retain, reject, blackhole
		     and noinstall options are the same as described above.

Control Statements Overview
       Control statements control routes that are imported from routing	 peers
       and routes that are exported to these peers. These are the final state‐
       ments to be included in the gated.conf  file.  The  control  statements
       are:

	      ·	 the Import Statement

	      ·	 the Export Statement

	      ·	 the Aggregate Statement

	      ·	 the Generate Statement

Route Filtering
       Routes  are  filtered  by  specifying  configuration language that will
       match a certain set of routes by destination,  or  by  destination  and
       mask.  Among  other  places, route filters are used on martians, import
       and export statements.

       The action taken when no match is found is dependent  on	 the  context,
       for  instance import and export route filters assume an all reject ; at
       the end a list.

       A route will match the most specific filter  that  applies.  Specifying
       more than one filter with the same destination, mask and modifiers will
       generate an error.

   Filtering syntax
       network [ exact | refines ]
       network mask mask [ exact | refines ]
       network masklen number [ exact | refines ]
       all
       default
       host host

       These are all the possible formats for a route filter. Not all of these
       formats	are available in all places, for instance the host and default
       formats are not valid for martians.

       In most cases it is possible to specify additional parameters  relevant
       to the context of the filter. For example, on a martian statement it is
       possible to specify the allow keyword, on an import statement  you  can
       specify a preference, and on a export you can specify a metric.

	      network [ exact | refines ]
	      network mask mask [ exact | refines ]
	      network masklen number [ exact | refines ]
		     Matching  usually	requires  both	an address and a mask,
		     although the mask	is  implied  in	 the  shorthand	 forms
		     listed  below.  These three forms vary in how the mask is
		     specified. In the first form, the mask is implied	to  be
		     the  natural mask of the network. In the second, the mask
		     is explicitly specified. In the third, the mask is speci‐
		     fied by the number of contiguous one bits.

		     If	 no  additional parameters are specified, any destina‐
		     tion that falls in the range given	 by  the  network  and
		     mask  is matched. The mask of the destination is ignored.
		     If a natural network is specified, the network, any  sub‐
		     nets, and any hosts will be match. The two optional modi‐
		     fiers cause the mask of the destination to be  considered
		     also:

			exact  This  parameter	specifies that the mask of the
			       destination  must  match	 the   supplied	  mask
			       exactly.	 This  is used to match a network, but
			       no subnets or hosts of that network.

			refines
			       Specifies that the mask of the destination must
			       be  more	 specified  (longer)  than  the filter
			       mask. This is  used  to	match  subnets	and/or
			       hosts of a network, but not the network.

	      all    This entry matches anything. It is equivalent to:

			0.0.0.0 mask 0.0.0.0

	      default
		     Matches  the default route. To match, the address must be
		     the default address and the mask must be all zeros.  This
		     is equivalent to:

			0.0.0.0 mask 0.0.0.0 exact

	      host host
		     Matches  the  specific  host.  To match, the address must
		     exactly match the specified host  and  the	 network  mask
		     must be a host mask (all ones). This is equivalent to:

			host mask 255.255.255 exact

Matching AS paths
       An AS path is a list of autonomous_systems that routing information has
       passed through to get to this router, and an indicator of the origin of
       the  AS path. This information can be used to prefer one path to a des‐
       tination network over another. The primary method for doing  this  with
       GateD  is  to specify a list of patterns to be applied to AS paths when
       importing and exporting routes.

       Each autonomous system that a route passed through prepends its AS num‐
       ber to the beginning of the AS path.

       The origin information details the completeness of AS path information.
       An origin of igp indicates the route was learned from an interior rout‐
       ing  protocol  and  is most likely complete. An origin of egp indicates
       the route was learned from an exterior routing protocol that  does  not
       support AS paths (EGP for example) and the path is most likely not com‐
       plete. When the path information is definitely not complete, an	origin
       of incomplete is used.

       AS path regular expressions are defined in RFC 1164 section 4.2.

   AS path matching syntax
       An AS path is matched using the following syntax.

	      aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] )

       This specifies that an AS matching the aspath_regexp with the specified
       origin is matched.

   AS path regular expressions
       Technically, an AS path regular expression is a regular expression with
       the alphabet being the set of AS numbers. An AS path regular expression
       is composed of one or more AS paths expressions. An AS path expressions
       is composed of AS path terms and AS path operators.

   AS path terms
       An AS path term is one of the following three objects:

	      autonomous_system
	      .
	      ( aspath_regexp )

       where

	      autonomous_system	       Any  valid  autonomous  system  number,
				       from one through 65534 inclusive.

	      .			       Matches any autonomous system number.

	      ( aspath_regexp )	       Parentheses  group   subexpressions--an
				       operator,  such	as  *  or ? works on a
				       single element or on a regular  expres‐
				       sion enclosed in parentheses

   AS path operators
       An AS path operator is one of the following:

	      aspath_term {m,n}
	      aspath_term {m}
	      aspath_term {m,}
	      aspath_term *
	      aspath_term +
	      aspath_term ?
	      aspath_term | aspath_term

       aspath_term {m,n}
	      a	 regular  expression followed by {m,n} (where m and n are both
	      nonnegative integers and m <= n) means at least m and at most  n
	      repetitions.

       aspath_term {m}
	      a	 regular  expression  followed	by  {m} (where m is a positive
	      integer) means exactly m repetitions.

       aspath_term {m,}
	      a regular expression followed by {m,} (where  m  is  a  positive
	      integer) means m or more repetitions.

       aspath_term *
	      an  AS  path  term followed by * means zero or more repetitions.
	      This is shorthand for {0,}.

       aspath_term +
	      a regular expression followed by + means	one  or	 more  repeti‐
	      tions. This is shorthand for {1,}.

       aspath_term ?
	      a regular expression followed by ? means zero or one repetition.
	      This is shorthand for {0,1}.

       aspath_term | aspath_term
	      matches the AS term on the left, or the AS term on the right.

The Import Statement
       Importation of routes from routing protocols and	 installation  of  the
       routes  in  the	GateD  routing database is controlled by import state‐
       ments. The format of an import statement varies depending on the source
       protocol.

   Specifying preferences
       In  all	cases,	one  of	 two  keywords may be specified to control how
       routes compete with other protocols:

	      restrict
	      preference preference

	      restrict
		     Specifies that the routes are not desired in the  routing
		     table.   In some cases this means that the routes are not
		     installed in the routing table. In others it  means  that
		     they  are installed with a negative preference; this pre‐
		     vents them from becoming  active  so  they	 will  not  be
		     installed	in  the forwarding table, or exported to other
		     protocols.

	      preference preference
		     Specifies the preference value used when  comparing  this
		     route  to	other  routes  from other protocols. The route
		     with the lowest preference available at any  given	 route
		     becomes  the active route, is installed in the forwarding
		     table, and is eligible to be exported to other protocols.
		     The  default preferences are configured by the individual
		     protocols.

   Route Filters
       All the formats allow route filters as shown below. See the section  on
       route  filters  for  a  detailed	 explanation of how they work. When no
       route filtering is specified (when restrict is specified on  the	 first
       line  of	 a statement), all routes from the specified source will match
       that statement. If any filters are specified, only  routes  that	 match
       the specified filters will be imported. Put differently, if any filters
       are specified, an all restrict; is assumed at the end of the list.

	      network [ exact | refines ]
	      network mask mask [exact | refines ]
	      network masklen number [ exact | refines ]
	      default
	      host host

   Importing routes from BGP and EGP
       import proto bgp | egp autonomoussystem autonomous_system
	   restrict ;
       import proto bgp | egp autonomoussystem autonomous_system
	   [ preference preference ] {
	   route_filter [ restrict | ( preference preference ) ] ;
       } ;

       import proto bgp aspath aspath_regexp
	   origin any | ( [ igp ] [egp ] [ incomplete ] )
	   restrict ;
       import proto bgp aspath aspath_regexp
	   origin any | ( [ igp ] [egp ] [ incomplete ] )
	   [ preference preference ] {
	   route_filter [ restrict | ( preference preference ) ] ;
       } ;

       EGP importation may be controlled by autonomous system.	BGP also  sup‐
       ports  controlling propagation by the use of an AS path regular expres‐
       sions, which are documented in the section on Matching AS paths.	  Note
       that EGP and BGP versions 2 and 3 only support the propagation of natu‐
       ral networks, so the host and default route  filters  are  meaningless.
       BGP  version 4 supports the propagation of any destination along with a
       contiguous network mask.

       EGP and BGP both store any routes that were rejected implicitly by  not
       being mentioned in a route filter, or explicitly with the restrict key‐
       word in the routing table with a negative preference. A negative	 pref‐
       erence  prevents	 a  route from becoming active, which prevents it from
       being installed in the forwarding table, or exported  to	 other	proto‐
       cols. This alleviates the need to break and re-establish a session upon
       reconfiguration if importation policy is changed.

   Importing routes from an RIP, HELLO and Redirects
       import proto rip | hello | redirect
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   restrict ;
       import proto rip | hello | redirect
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   [ preference preference ] {
	   route_filter [ restrict | ( preference preference ) ] ;
       } ;

       The importation of RIP, HELLO and Redirect routes may be controlled  by
       any  of protocol, source interface and source gateway. If more than one
       is specified, they are processed from most general (protocol)  to  most
       specific (gateway).

       RIP  and	 HELLO	do not support the use of preference to choose between
       routes of the same protocol. That is  left  to  the  protocol  metrics.
       These  protocols	 do not save routes that were rejected since they have
       short update intervals.

   Importing routes from OSPF
       import proto ospfase [ tag ospf_tag ] restrict ;
       import proto ospfase [ tag ospf_tag ]
	   [ preference preference ] {
	   route_filter [ restrict | ( preference preference ) ] ;
       } ;

       Due to the nature of OSPF, only the importation of ASE  routes  may  be
       controlled.  OSPF intra- and inter-area routes are always imported into
       the gated routing table with a preference of 10.	 If a  tag  is	speci‐
       fied,  the  import  clause will only apply to routes with the specified
       tag.

       It is only possible to restrict the importation of OSPF ASE routes when
       functioning  as an AS border router. This is accomplished by specifying
       an export ospfase clause. Specification of an empty export  clause  may
       be  used	 to  restrict  importation  of	ASEs  when  no	ASEs are being
       exported.

       Like the other interior protocols, preference can not be used to choose
       between	OSPF  ASE routes, that is done by the OSPF costs.  Routes that
       are rejected by policy are stored in the table with a negative  prefer‐
       ence.

The Export Statement
       The  import statement controls which routes received from other systems
       are used by GateD, and the export statement controls which  routes  are
       advertised  by  GateD  to other systems. Like the import statement, the
       syntax of the export statement varies slightly per protocol. The syntax
       of  the	export statement is similar to the syntax of the import state‐
       ment, and the meanings of many of the  parameters  are  identical.  The
       main difference between the two is that while route importation is just
       controlled by source information, route exportation  is	controlled  by
       both destination and source.

       The outer portion of a given export statement specifies the destination
       of the routing information you  are  controlling.  The  middle  portion
       restricts the sources of importation that you wish to consider. And the
       innermost portion is a route filter used to select individual routes.

   Specifying metrics
       The most specific specification of a metric is the one applied  to  the
       route  being  exported.	The  values that may be specified for a metric
       depend on the destination protocol that is referenced  by  this	export
       statement.

	      restrict
	      metric metric

	      restrict
		     Specifies	that  nothing should be exported. If specified
		     on the destination portion of the	export	statement,  it
		     specifies	that nothing at all should be exported to this
		     destination. If specified on the source portion, it spec‐
		     ifies that nothing from this source should be exported to
		     this destination. If specified as part of a route filter,
		     it	 specifies that the routes matching that filter should
		     not be exported.

	      metric metric
		     Specifies the metric to be used  when  exporting  to  the
		     specified destination.

   Route Filters
       All  the formats allow route filters as shown below. See the section on
       route filters for a detailed explanation of  how	 they  work.  When  no
       route  filtering	 is specified (when restrict is specified on the first
       line of a statement), all routes from the specified source  will	 match
       that  statement.	 If  any filters are specified, only routes that match
       the specified filters will be exported. Put differently, if any filters
       are specified, an all restrict ; is assumed at the end of the list.

	      network [ exact | refines ]
	      network mask mask [exact | refines ]
	      network masklen number [ exact | refines ]
	      default
	      host host

   Specifying the destination
       As mentioned above, the syntax of the export statement varies depending
       on the protocol it is being applied to. One thing that applies  in  all
       cases  is the specification of a metric. All protocols define a default
       metric to be used for routes being exported, in most cases this can  be
       overridden at several levels of the export statement.

       The  specification  of  the  source  of	the  routing information being
       exported (the export_list) is described below.

   Exporting to EGP and BGP
       export proto bgp | egp as autonomous system
	   restrict ;
       export proto bgp | egp as autonomous system
	   [ metric metric ] {
	   export_list ;
       } ;

       Exportation to EGP and BGP is controlled by autonomous system, the same
       policy  is  applied to all routers in the AS.  EGP metrics range from 0
       to 255 inclusive with 0 being the most attractive.

       BGP metrics are 16 bit unsigned quantities. They range from 0 to	 65535
       inclusive  with	0 being the most attractive. While BGP version 4 actu‐
       ally supports 32 bit unsigned quantities, GateD does  not  yet  support
       this.

       If  no  export  policy is specified, only routes to attached interfaces
       will be exported. If any policy is specified, the defaults are overrid‐
       den;  it	 is  necessary to explicitly specify everything that should be
       exported.

       Note that EGP and BGP versions 2 and 3 only support the propagation  of
       natural	networks,  so  the host and default route filters are meaning‐
       less. BGP version 4 supports the propagation of any  destination	 along
       with a contiguous network mask.

   Exporting to RIP and HELLO
       export proto rip | hello
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   restrict ;
       export proto rip | hello
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   [ metric metric ] {
	   export_list ;
       } ;

       Exportation  to	RIP and HELLO is controlled by any of protocol, inter‐
       face or gateway. If more than one is specified, they are processed from
       most general (protocol) to most specific (gateway).

       It is not possible to set metrics for exporting RIP routes into RIP, or
       exporting HELLO routes into HELLO. Attempts to  do  this	 are  silently
       ignored.

       If no export policy is specified, RIP and interface routes are exported
       into RIP and HELLO and interface routes are exported into HELLO. If any
       policy  is  specified,  the defaults are overridden. It is necessary to
       explicitly specify everything that should be exports.

       RIP version 1 and HELLO assume that all subnets of the  shared  network
       have the same subnet mask so they are only able to propagate subnets of
       that network. RIP version 2 removes that restriction and is capable  of
       propagating all routes when not sending version 1 compatible updates.

       To  announce  routes which specify a next hop of the loopback interface
       (static and internally generated default routes) via RIP or  HELLO,  it
       is  necessary to specify the metric at some level in the export clause.
       Just setting a default metric for RIP or HELLO is not sufficient.  This
       is a safeguard to verify that the announcement is intended.

   Exporting to OSPF
       export proto ospfase [ type 1 | 2 ] [ tag ospf_tag ]
	   restrict ;
       export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ]
	   [ metric metric ] {
	   export_list ;
       } ;

       It  is  not  possible  to  create  OSPF	intra- or inter-area routes by
       exporting routes from the GateD routing table into  OSPF.  It  is  only
       possible	 to  export from the GateD routing table into OSPF ASE routes.
       It is also not possible to  control  the	 propagation  of  OSPF	routes
       within the OSPF protocol.

       There are two types of OSPF ASE routes, type 1 and type 2, see the OSPF
       protocol configuration for a detailed explanation of the two types. The
       default type is specified by the defaults subclause of the ospf clause.
       This may be overridden by a specification on the export statement.

       OSPF ASE routes also have the provision to carry	 a  tag.  This	is  an
       arbitrary  32  bit  number  that	 can be used on OSPF routers to filter
       routing information. See the OSPF protocol configuration	 for  detailed
       information  on	OSPF  tags.  The  default  tag	specified  by the ospf
       defaults clause may be overridden by a  tag  specified  on  the	export
       statement.

   Specifying the source
       The export list specifies export based on the origin of a route and the
       syntax varies depending on the source.

   Exporting BGP and EGP routes
       proto bgp | egp autonomoussystem autonomous_system
	   restrict ;
       proto bgp | egp autonomoussystem autonomous_system
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       BGP and EGP routes may be specified by source  autonomous  system.  All
       routes may be exported by as path, see below for more information.

   Exporting RIP and HELLO routes
       proto rip | hello
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   restrict ;
       proto rip | hello
	   [ ( interface interface_list ) | (gateway gateway_list ) ]
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       RIP  and	 HELLO	routes	may  be exported by protocol, source interface
       and/or source gateway.

   Exporting OSPF routes
       proto ospf | ospfase restrict ;
       proto ospf | ospfase [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       Both OSPF, and OSPF ASE routes may be exported  into  other  protocols.
       See below for information on exporting by tag.

   Exporting routes from nonrouting protocols
   Nonrouting with interface
       proto direct | static | kernel
	   [ (interface interface_list ) ]
	   restrict ;
       proto direct | static | kernel
	   [ (interface interface_list ) ]
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       These protocols may be exported by protocol, or by the interface of the
       next hop. These protocols are:

	      direct Routes to directly attached interfaces.

	      static Static routes specified in a static clause.

	      kernel On systems with the routing socket, routes	 learned  from
		     the routing socket are installed in the GateD routing ta‐
		     ble with a	 protocol  of  kernel.	These  routes  may  be
		     exported  by  referencing	this  protocol. This is useful
		     when it is desirable to have a script install routes with
		     the  route	 command  and  propagate them to other routing
		     protocols.

   Nonrouting by protocol
       proto default | aggregate
	   restrict ;
       proto default | aggregate
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       These protocols may only be referenced by protocol.

	      default
		     Refers to routes created by the gendefault option. It  is
		     recommended that route generation be used instead.

	      aggregate
		     Refers  to	 routes synthesized from other routes when the
		     aggregate and generate statements are used. See the  sec‐
		     tion on Route Aggregation for more information.

   Exporting by AS path
       proto proto | all aspath aspath_regexp
	   origin any | ( [ igp ] [egp ] [ incomplete ] )
	   restrict ;
       proto proto | all aspath aspath_regexp
	   origin any | ( [ igp ] [egp ] [ incomplete ] )
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       When  BGP  is  configured, all routes are assigned an AS path when they
       are added to the routing table. For all interior routes	this  AS  path
       specifies  IGP as the origin and no ASes in the AS path (the current AS
       is added when the route is exported). For EGP routes this AS path spec‐
       ifies  EGP  as  the  origin  and	 the source AS as the AS path. For BGP
       routes, the AS path is stored as learned from BGP.

       AS path regular expressions are documented in the section  on  Matching
       AS paths.

   Exporting by route Tag
       proto proto | all tag tag restrict ;
       proto proto | all tag tag
	   [ metric metric ] {
	   route_filter [ restrict | ( metric metric ) ] ;
       } ;

       Both OSPF and RIP version 2 currently support tags, all other protocols
       always have a tag of  zero.  The	 source	 of  exported  routes  may  be
       selected	 based	on this tag. This is useful when routes are classified
       by tag when the are exported into a given routing protocol.

Route Aggregation
       Route aggregation is a method of generating a more general route	 given
       the presence of a specific route. It is used, for example, at an auton‐
       omous system border to generate a route to a network to	be  advertised
       via  EGP	 given	the  presence  of  one or more subnets of that network
       learned via RIP. Older versions of GateD automatically  performed  this
       function, generating an aggregate route to a natural network (using the
       old Class A, B and C concept) given an interface to a  subnet  of  that
       natural	network.  However that was not always the correct thing to do,
       and with the advent of classless interdomain routing it	is  even  more
       frequently  the	wrong  thing  to do, so aggregation must be explicitly
       configured. No aggregation is performed unless explicitly requested  in
       an aggregate statement.

       Route  aggregation  is  also  used by regional and national networks to
       reduce the amount of routing information passed	around.	 With  careful
       allocation  of network addresses to clients, regional networks can just
       announce one route to regional networks instead of hundreds.

       Aggregate routes are not actually used for  packet  forwarding  by  the
       originator of the aggregate route, only by the receiver (if it wishes).
       A router receiving a packet which does not match one of	the  component
       routes which led to the generation of an aggregate route is supposed to
       respond with an ICMP network unreachable message. This  is  to  prevent
       packets	for  unknown  component	 routes from following a default route
       into another network where they would be forwarded back to  the	border
       router, and around and around again and again, until their TTL expires.
       Sending an unreachable message for a missing piece of an	 aggregate  is
       only possible on systems with support for reject routes.

       A slight variation of aggregation is the generation of a route based on
       the existence of certain conditions. This is  sometimes	known  as  the
       route of last resort. This route inherits the next hops and aspath from
       the contributor specified with the lowest (most favorable)  preference.
       The  most  common  usage for this is to generate a default based on the
       presence of a route from a peer on a neighboring backbone.

   Aggregation and Generation syntax
       aggregate default
	   | ( network [ ( mask mask ) | ( masklen number ) ] )
	   [ preference preference ] [ brief ] {
	   proto [ all | direct | static | kernel | aggregate | proto ]
	       [ ( as autonomous system ) | ( tag tag )
		   | ( aspath aspath_regexp ) ]
	       restrict ;
	   proto [ all | direct | static | kernel | aggregate | proto ]
	       [ ( as autonomous system ) | ( tag tag )
		   | ( aspath aspath_regexp ) ]
	       [ preference preference ] {
	       route_filter [ restrict | ( preference preference ) ] ;
	   } ;
       } ;

       generate default
	   | ( network [ ( mask mask ) | ( masklen number ) ] )
	   [ preference preference ] {
	       [ ( as autonomous system ) | ( tag tag )
		   | ( aspath aspath_regexp ) ]
	       restrict ;
	   proto [ all | direct | static | kernel | aggregate | proto ]
	       [ ( as autonomous system ) | ( tag tag )
		   | ( aspath aspath_regexp ) ]
	       [ preference preference ] {
	       route_filter [ restrict | ( preference preference ) ] ;
	   } ;
       } ;

       Routes that match the route filters  are	 called	 contributing  routes.
       They  are  ordered according to the aggregation preference that applies
       to them. If there are more than one contributing routes with  the  same
       aggregating  preference, the preferences of the route are used to order
       the routes. The preference of the aggregate route will be that  of  the
       contributing route with the lowest aggregate preference.

	      preference preference
		     Specifies	the  preference	 to  assign  to	 the resulting
		     aggregate route. The default preference is 130.

	      brief  Used to specify that the AS path should be	 truncated  to
		     the longest common AS path. The default is to build an AS
		     path consisting of SETs and SEQUENCEs of all contributing
		     AS paths.

	      proto proto
		     In	 addition  to  the  special protocols listed, the con‐
		     tributing protocol may be chosen from among  any  of  the
		     ones supported (and currently configured into) GateD.

	      as autonomous_system
		     Restrict  selection  of  routes to those learned from the
		     specified autonomous system.

	      tag tag
		     Restrict selection of routes to those with the  specified
		     tag.

	      aspath aspath_regexp
		     Restrict  selection  of  routes  to  those that match the
		     specified AS path.

	      restrict
		     Indicates that these routes are not to be	considered  as
		     contributors  of  the  specified aggregate. The specified
		     protocol may be any of the protocols supported by GateD.

	      route_filter
		     See below.
       A route may only contribute to an aggregate route which is more general
       than  itself;  it  must	match the aggregate under its mask.  Any given
       route may only contribute to one aggregate route,  which	 will  be  the
       most  specific  configured,  but an aggregate route may contribute to a
       more general aggregate.

   Route Filters
       All the formats allow route filters as shown below. See the section  on
       route  filters  for  a  detailed	 explanation of how they work. When no
       route filtering is specified (when restrict is specified on  the	 first
       line  of	 a statement), all routes from the specified source will match
       that statement. If any filters are specified, only  routes  that	 match
       the  specified  filters will be considered as contributors. Put differ‐
       ently, if any filters are specified, an all restrict ;  is  assumed  at
       the end of the list.

	      network [ exact | refines ]
	      network mask mask [exact | refines ]
	      network masklen number [ exact | refines ]
	      default
	      host host

Glossary of Terms
       Terms used in descriptions throughout this document are defined below:

       A relationship formed between selected neighboring routers for
	      the purpose of exchanging routing information. Not every pair of
	      neighboring routers becomes adjacent.

       A set of routers under a single technical administration, using
	      an interior gateway protocol and common metrics to route packets
	      within  the  AS, and using an exterior gateway protocol to route
	      packets to other ASs. Since this classic definition  was	devel‐
	      oped,  it has become common for a single AS to use several inte‐
	      rior gateway protocols and sometimes  several  sets  of  metrics
	      within  an  AS.  The  use of the term Autonomous System stresses
	      that even when multiple igps and metrics are used, the  adminis‐
	      tration  of an AS appears to other ASs to have a single coherent
	      interior routing plan and presents a consistent picture of  what
	      networks	are  reachable	through it. The AS is represented by a
	      number between 1 and 65534, assigned by  the  Internet  Assigned
	      Numbers Authority.

       One of a class of exterior gateway
	      protocols, described in more detail in the BGP section of
	      the Protocol Overview.

       An OSPF metric. See metric.

       A HELLO metric. Valid values are from zero to 30000 inclusive.
	      The value of  30000  is  the  maximum  metric  and  means
	      unreachable.  See metric.

       OSPF: Each multiaccess network that has at least two
	      attached	routers	 as a designated router. The designated
	      router generates a link state advertisement for the  mul‐
	      tiaccess network and assists in running the protocol. The
	      designated router is elected by the HELLO protocol.

       Any network or any host.

       An EGP metric. See metric. Valid values are from zero to 255
	      inclusive.

       A class of  routing  protocols  used  to	 exchange
       routing information
	      within  an  autonomous  system.  A detailed
	      explanation of exterior  gateway	protocols
	      is available in the Protocol Overview.

       One of a class of exterior gateway
	      protocols,  described in more detail
	      in the EGP section of  the  Protocol
	      Overview.

       An  intermediate destination by which pack‐
       ets are delivered to
	      their ultimate destination.  A  host
	      address  of  another  router that is
	      directly reachable via  an  attached
	      network. As with any host address it
	      may be specified symbolically.

       A list of one or more gateways separated by
       white
	      space.

       One of a class of interior gateway
	      protocols,  described in more detail
	      in the HELLO section of the Protocol
	      Overview.

       The  IP address of any host. Usually speci‐
       fied as a dotted quad,
	      four values in the range of 0 to 255
	      inclusive separated by dots (.). For
	      example 132.236.199.63 or 10.0.0.51.
	      It may also be specified as an eight
	      digit hexadecimal string preceded by
	      0x.   For	  example   0x????????	or
	      0x0a000043.   Finally,  if   options
	      noresolv	is  not	 specified, a sym‐
	      bolic    hostname.    For	   example
	      gated.cornell.edu	  or  nic.ddn.mil.
	      The numeric forms are much preferred
	      over the symbolic form.

       The  host address of an attached interface.
       This is
	      the address of a broadcast, nbma	or
	      loopback	interface  and	the remote
	      address of a  point-to-point  inter‐
	      face.  As	 with  any host address it
	      may be specified symbolically.

       The connection between a router and one	of
       its attached
	      networks.	 A  physical interface may
	      be specified by a single IP address,
	      domain   name,  or  interface  name.
	      (Unless the network is an unnumbered
	      point-to-point  network.)	  Multiple
	      levels of reference in the  configu‐
	      ration language allow identification
	      of interfaces using wildcard, inter‐
	      face   type  name,  or  delete  word
	      address. Be careful with the use	of
	      interface names as future Unix oper‐
	      ating systems may	 allow	more  than
	      one  address  per interface. Dynamic
	      interfaces can be added  or  deleted
	      and  indicated as up or down as well
	      as changes to address,  netmask  and
	      metric parameters.

       One  of	a  class  of routing
       protocols  used	to  exchange
       routing
	      information  within an
	      autonomous  system.  A
	      detailed	 explanation
	      of  interior   gateway
	      protocols is available
	      in the Protocol  Over‐
	      view.

       A  list of one or more inter‐
       face names including wildcard
       names
	      (names  without a num‐
	      ber) and	names  which
	      may  specify more than
	      one    interface	  or
	      address,	or the token
	      "all" for	 all  inter‐
	      faces.   See  the sec‐
	      tion   on	   interface
	      lists  for more infor‐
	      mation.

       One of a	 class	of  interior
       gateway
	      protocols.

       The   host   address   of  an
       attached interface. This is
	      the   address   of   a
	      broadcast,   nbma	  or
	      loopback interface and
	      the local address of a
	      point-to-point  inter‐
	      face. As with any host
	      address  it   may	  be
	      specified	    symboli‐
	      cally.

       A means of  subdividing	net‐
       works using address modifica‐
       tion. A
	      mask is a dotted	quad
	      specifying  which bits
	      of the destination are
	      significant.    Except
	      when used in  a  route
	      filter,	GateD	only
	      supports	  contiguous
	      masks.

       The   number  of	 significant
       bits in the mask.

       One of the units used to help
       a  system  determine the best
       route.
	      Metrics may  be  based
	      on  hop count, routing
	      delay, or an arbitrary
	      value   set   by	 the
	      administrator  depend‐
	      ing  on  the  type  of
	      routing	   protocol.
	      Routing	metrics	 may
	      influence the value of
	      assigned	    internal
	      preferences.	(See
	      preference.)

	      This    sample   table
	      shows  the  range	  of
	      possible	 values	 for
	      each routing  protocol
	      metric  and  the value
	      used by each  protocol
	      (See   Protocol  Over‐
	      view.) to reach a des‐
	      tination.

		 SAMPLE ROUTING PROTOCOL METRICS
		 Protocol  Metric Represents	 Range	  Unreachable
		 --------  -----------------	 -----	  -----------
		 RIP	   distance (hop-count)	 0-15		16
		 HELLO	   delay (milliseconds)	 0-29999     30000
		 OSPF	   cost of path		 0-?????    Delete
		 ISIS	   cost of path		 0-254	    Delete
		 EGP	   distance (unused)	 0-65535       255
		 BGP	   unspecified		 0-65534     65535

       Those  physical networks that
       support	the  attachment	  of
       multiple
	      (more	than	two)
	      routers. Each pair  of
	      routers on such a net‐
	      work is assumed to  be
	      able   to	 communicate
	      directly.

       The format of an	 IP  address
       contains	 the network address
       and the
	      host   address.	 The
	      natural	mask   is  a
	      default value  applied
	      to    the	   3   class
	      addresses:
	      0xff000000 for class A (network.host.host.host),
	      0xffff0000 for class B (network.network.host.host) and
	      0xffffff00 for class C (network.network.network.host).

       Another	router	which	with
       implicit or explicit communi‐
       cation is
	      established by a rout‐
	      ing  protocol.  Neigh‐
	      bors are usually on  a
	      shared   network,	 but
	      not always. This	term
	      is mostly used in OSPF
	      and EGP. Usually	syn‐
	      onymous with peer.

       Two  routers that have inter‐
       faces to a common network. On
	      multiaccess  networks,
	      routers	are  dynami‐
	      cally  discovered	  by
	      the  OSPF HELLO proto‐
	      col.

       Any packet-switched  network.
       A network may be specified by
	      its IP address or net‐
	      work  name.  The	host
	      bits   in	  a  network
	      specification must  be
	      zero.  Default  may be
	      used  to	specify	 the
	      default	     network
	      (0.0.0.0).

       The IP address of a  network.
       Usually specified as a dotted
       quad,
	      one to four values  in
	      the  range of 0 to 255
	      inclusive separated by
	      dots  (.). For example
	      132.236.199,   132.236
	      or  10. It may also be
	      specified as  a  hexa‐
	      decimal	string	pre‐
	      ceded by	0x  with  an
	      even  number of digits
	      between two and eight.
	      For  example 0x??????,
	      0x???? or 0x0a.	Also
	      allowed  is  the	sym‐
	      bolic  value   default
	      which  has the distin‐
	      guished value 0.0.0.0,
	      the  default  network.
	      If options noresolv is
	      not  specified, a sym‐
	      bolic network name can
	      be  used,	 for example
	      nr-tech-prod,	cor‐
	      nellu-net and arpanet.
	      The numeric forms	 are
	      much   preferred	over
	      the symbolic form.

       A positive integer.

       One  of	a  class   of
       interior gateway
	      protocols,
	      described	   in
	      more  detail in
	      the  OSPF	 sec‐
	      tion   of	  the
	      Protocol	Over‐
	      view.

       Another	router
       which	  with
       implicit	    or
       explicit commu‐
       nication is
	      estab‐
	      lished
	      by     a
	      routing
	      proto‐
	      col.
	      Peers
	      are usu‐
	      ally  on
	      a shared
	      network,
	      but  not
	      always.
	      This
	      term  is
	      mostly
	      used  by
	      BGP.
	      Usually
	      synony‐
	      mous
	      with
	      neigh‐
	      bor.

       A  UDP  or  TCP
       port    number.
       Valid	values
       are    from   1
       through 65535
	      inclu‐
	      sive.

       A preference is
       a value between
       0   (zero)  and
       255
	      used  to
	      select
	      between
	      many
	      routes
	      to   the
	      same
	      destina‐
	      tion.
	      The
	      route
	      with the
	      best
	      (numeri‐
	      cally
	      lowest)
	      prefer‐
	      ence  is
	      as   the
	      active
	      route.
	      The
	      active
	      route is
	      the  one
	      installed
	      in   the
	      kernel
	      forward‐
	      ing  ta‐
	      ble  and
	      exported
	      to other
	      proto‐
	      cols.
	      Prefer‐
	      ence
	      zero  is
	      usually
	      reserved
	      for
	      routes
	      to
	      directly
	      attached
	      inter‐
	      faces. A
	      default
	      prefer‐
	      ence  is
	      assigned
	      to  each
	      source
	      from
	      which
	      GateD
	      receives
	      routes.
	      (See
	      Prefer‐
	      ence.)

       A    contiguous
       mask   covering
       the  most  sig‐
       nificant	  bits
       of an
	      address.
	      The pre‐
	      fix
	      length
	      speci‐
	      fies how
	      many
	      bits are
	      covered.

       The  OSI
       equiva‐
       lent  of
       TOS.

       One
       of
       a
       class
       of
       inte‐
       rior
       gate‐
       way    pro‐
	      to‐
	      cols,
	      described
	      in
	      more
	      detail
	      in
	      the
	      RIP
	      sec‐
	      tion
	      of
	      the
	      Pro‐
	      to‐
	      col
	      Over‐
	      view.

       A
       32-bit
       num‐
       ber
       assigned
       to
       each
       router
       run‐
       ning
       the
       OSPF
	      pro‐
	      to‐
	      col.
	      This
	      num‐
	      ber
	      uniquely
	      iden‐
	      ti‐
	      fies
	      the
	      router
	      within
	      the
	      au‐
	      ton‐
	      o‐
	      mous
	      sys‐
	      tem.

       An
       IP
       address
       used
       as
       unique
       iden‐
       ti‐
       fier
       assigned
       to
       rep‐
       re‐
       sent
       a
	      spe‐
	      cific
	      router.
	      This
	      is
	      usu‐
	      ally
	      the
	      address
	      of
	      an
	      attached
	      inter‐
	      face.

       The
       repos‐
       i‐
       tory
       of
       all
       of
       the
       GateD
       retained
       rout‐
       ing
	      infor‐
	      ma‐
	      tion,
	      used
	      to
	      make
	      deci‐
	      sions
	      and
	      as
	      a
	      source
	      for
	      rout‐
	      ing
	      infor‐
	      ma‐
	      tion
	      which
	      is
	      prop‐
	      a‐
	      gated.

       An
       inter‐
       face
       may
       be
       marked
       as
       sim‐
       plex
       either
       by
       the
       ker‐
       nel,
       or
       by     inter‐
	      face
	      con‐
	      fig‐
	      u‐
	      ra‐
	      tion.
	      A
	      sim‐
	      plex
	      inter‐
	      face
	      is
	      an
	      inter‐
	      face
	      on
	      a
	      broad‐
	      cast
	      media
	      that
	      is
	      not
	      capa‐
	      ble
	      of
	      receiv‐
	      ing
	      pack‐
	      ets
	      it
	      broad‐
	      casts.

	      GateD
	      takes
	      advan‐
	      tage
	      of
	      inter‐
	      faces
	      that
	      are
	      capa‐
	      ble
	      of
	      receiv‐
	      ing
	      their
	      own
	      broad‐
	      cast
	      pack‐
	      ets
	      to
	      mon‐
	      i‐
	      tor
	      whether
	      an
	      inter‐
	      face
	      appears
	      to
	      be
	      func‐
	      tion‐
	      ing
	      prop‐
	      erly.

       A
       time
       value,
       usu‐
       ally
       a
       time
       inter‐
       val.
       It
       may
       be
       spec‐
       i‐
       fied
       in     any
	      one
	      of
	      the
	      fol‐
	      low‐
	      ing
	      forms:

		 num‐
		 ber			  A
					  non‐
					  neg‐
					  a‐
					  tive
					  dec‐
					  i‐
					  mal
					  num‐
					  ber
					  of
					  sec‐
					  onds.
					  For
					  exam‐
					  ple,
					  27,
					  60
					  or
					  3600.

		 num‐
		 ber:num‐
		 ber			  A
					  non‐
					  neg‐
					  a‐
					  tive
					  dec‐
					  i‐
					  mal
					  num‐
					  ber
					  of
					  min‐
					  utes
					  fol‐
					  lowed
					  by
					  a
					  sec‐
					  onds
					  value
					  in
					  the
					  range
					  of
					  zero
					  to
					  59
					  inclu‐
					  sive.
					  For
					  exam‐
					  ple,
					  0:27,
					  1:00
					  or
					  60:00.

		 num‐
		 ber:num‐
		 ber:num‐
		 ber			  A
					  non‐
					  neg‐
					  a‐
					  tive
					  dec‐
					  i‐
					  mal
					  num‐
					  ber
					  of
					  hours
					  fol‐
					  lowed
					  by
					  a
					  min‐
					  utes
					  value
					  in
					  the
					  range
					  of
					  zero
					  to
					  59
					  inclu‐
					  sive
					  fol‐
					  lowed
					  by
					  a
					  sec‐
					  onds
					  value
					  in
					  the
					  range
					  of
					  zero
					  to
					  59
					  inclu‐
					  sive.
					  For
					  exam‐
					  ple,
					  0:00:27,
					  0:01:00
					  or
					  1:00:00.

       time
       to
       live
       ttl    The
	      Time
	      To
	      Live
	      (TTL)
	      of
	      an
	      IP
	      packet.
	      Valid
	      val‐
	      ues
	      are
	      from
	      one
	      (1)
	      through
	      255
	      inclu‐
	      sive.

       The
       type
       of
       ser‐
       vice
       is
       for
       inter‐
       net
       ser‐
       vice
       qual‐
       ity    selec‐
	      tion.
	      The
	      type
	      of
	      ser‐
	      vice
	      is
	      spec‐
	      i‐
	      fied
	      along
	      the
	      abstract
	      param‐
	      e‐
	      ters
	      prece‐
	      dence,
	      delay,
	      through‐
	      put,
	      reli‐
	      a‐
	      bil‐
	      ity,
	      and
	      cost.
	      These
	      abstract
	      param‐
	      e‐
	      ters
	      are
	      to
	      be
	      mapped
	      into
	      the
	      actual
	      ser‐
	      vice
	      param‐
	      e‐
	      ters
	      of
	      the
	      par‐
	      tic‐
	      u‐
	      lar
	      net‐
	      works
	      the
	      data‐
	      gram
	      tra‐
	      verses.
	      The
	      vast
	      major‐
	      ity
	      of
	      IP
	      traf‐
	      fic
	      today
	      uses
	      the
	      default
	      type
	      of
	      ser‐
	      vice.

WARN‐
       INGS

       con‐
       tains
       pro‐
       vi‐
       sions
       for
       BGP
       pro‐
       to‐
       col,
       but
       it
       is
       not
       offi‐
       cially
       sup‐
       ported
       by
       HP
       at
       the
       present
       time.
       The
       route
       aggre‐
       ga‐
       tion
       and
       gen‐
       er‐
       a‐
       tion
       state‐
       ments
       which
       gen‐
       er‐
       ate
       a
       more
       gen‐
       eral
       route
       from
       com‐
       press‐
       ing
       the
       spe‐
       cific
       routes
       through
       the
       explicit
       con‐
       fig‐
       u‐
       ra‐
       tion
       are
       not
       sup‐
       ported
       in
       this
       release.

AUTHOR

       See
       gated(1M).

SEE
       ALSO

       RFC
       827:	      E.
		      Rosen,

       RFC
       891:	      D.
		      Mills,

       RFC
       904:	      D.
		      Mills,

       RFC
       1058:	      C.
		      Hedrick,

       RFC
       1105:	      K.
		      Lougheed,
		      Y.
		      Rekhter,

       RFC
       1163:	      K.
		      Lougheed,
		      Y.
		      Rekhter,

       RFC
       1164:	      J.
		      Honig,
		      D.
		      Katz,
		      M.
		      Mathis,
		      Y.
		      Rekhter,
		      J.
		      Yu,

       RFC
       1227:	      M.
		      Rose,

       RFC
       1245:	      J.
		      Moy,

       RFC
       1246:	      J.
		      Moy,

       RFC
       1253:	      F.
		      Baker,
		      R.
		      Coltun,

       RFC
       1256:	      S.
		      Deer‐
		      ing,

       RFC
       1265:	      Y.
		      Rekhter,

       RFC
       1266:	      Y.
		      Rekhter,

       RFC
       1267:	      K.
		      Lougheed,
		      Y.
		      Rekhter,

       RFC
       1268:	      P.
		      Gross,
		      Y.
		      Rekhter,

       RFC
       1269:	      J.
		      Bur‐
		      russ,
		      S.
		      Willis,

       RFC
       1321:	      R.
		      Rivest,

       RFC
       1370:	      Inter‐
		      net
		      Archi‐
		      tec‐
		      ture
		      Board

       RFC
       1388:	      G.
		      Malkin,

       RFC
       1397:	      D.
		      Haskin,

       RFC
       1403:	      K.
		      Varad‐
		      han,

       RFC
       1583:	      J.
		      Moy,

								 gated.conf(4)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net