gated.conf man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

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.

       OSPF considers the virtual IP addresses assigned to the loopback inter‐
       face (lo0:X) as a stub network. A stub segment is a  segment  that  has
       only  one  router   attached  to	 it.  OSPF advertises these virtual IP
       addresses in router-LSA as a single HOST ROUTE regardless of their con‐
       figured	mask.  Host  routes are considered to be subnets whose mask is
       "all ones (0xffffffff)". Such addresses must  be defined in  the	 stub‐
       hosts statement announced through OSPF.

       In  contrast,  virtual  IP  addresses  assigned to a physical interface
       (lanX:Y) are advertised as a NETWORK ROUTE with	the  configured	 mask,
       and  it	is sufficient to define such addresses in the interface state‐
       ment.

       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