unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (HP-UX-11.11)
Page:
Section:
Apropos / Subsearch:
optional field



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




 NAME
      gated.config - GateDaemon Configuration Guide

 SYNOPSIS
      /etc/gated.conf

 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





 Hewlett-Packard Company	    - 1 -   HP-UX Release 11i: November 2000






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




	   +  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
      terminated by a semi-colon (`;'). Statements are composed of tokens
      separated 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 ``backbone'' 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 gated.conf 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.





 Hewlett-Packard Company	    - 2 -   HP-UX Release 11i: November 2000






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




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

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




 Hewlett-Packard Company	    - 3 -   HP-UX Release 11i: November 2000






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




	   bgp (protocol)		 enables BGP protocol.

	   redirect (protocol)		 configures the processing of ICMP
					 redirects.

	   icmp (protocol)		 configures the processing of
					 general 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.
      Preference may not be used to control the selection of routes within
      an igp, this is accomplished automatically by the protocol based on
      metric. 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 Glossary of Terms: Preference.) The preference value is an
      arbitrarily assigned value used to determine the order of routes to
      the same destination in a single routing database. The active route is
      chosen by the lowest preference value.  Some protocols implement a
      second preference (preference2), sometimes referred to as a tie-
      breaker.

    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.





 Hewlett-Packard Company	    - 4 -   HP-UX Release 11i: November 2000






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




	   +  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



 Hewlett-Packard Company	    - 5 -   HP-UX Release 11i: November 2000






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




      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 rip 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
      specifications, control options, and global and protocol specific
      tracing options. Unless overridden, tracing options from the next
      higher level are inherited by lower levels. For example, BGP peer
      tracing options are inherited from BGP group tracing options, which
      are inherited from global BGP tracing options, which are inherited
      from global GateD tracing options. At each level tracing
      specifications override the inherited options.

    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



 Hewlett-Packard Company	    - 6 -   HP-UX Release 11i: November 2000






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




		     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 policy
		     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
      potentially create too much output.

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

      Global tracing statements have an immediate effect, especially parsing
      options that effect the parsing of the configuration file. Tracing
      values inherited by protocols specified in the configuration file are
      initially inherited from the global options in effect as they are
      parsed, unless they are overridden by more specific options. After the
      configuration file is read, tracing options that were not explicitly
      specified are inherited from the global options in effect at the end
      of the configuration file.

    Packet tracing
      Tracing of packets is very flexible. For any given protocol there are



 Hewlett-Packard Company	    - 7 -   HP-UX Release 11i: November 2000






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




      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
      specification 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
		     specified 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
		     (minimum specification is 2).

	   control_options
		     Specifies options that control the appearance of
		     tracing. Valid values are:

		     nostamp
			  Specifies that a timestamp should not be prepended



 Hewlett-Packard Company	    - 8 -   HP-UX Release 11i: November 2000






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




			  to all trace lines.

	   except trace_options
		     Used to enable a broad class of tracing and then
		     disable 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
      language parser about included files and the directories in which
      these files reside. Directive statements are immediately acted upon by
      the parser. Other statements terminate with a semi-colon (;), but
      directive statements terminate with a newline. The two directive
      statements are:

	   %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 encountered.
		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 nesting 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:




 Hewlett-Packard Company	    - 9 -   HP-UX Release 11i: November 2000






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




	   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 getnetbyname()
		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 information 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 systems
		where setlogmask() is supported. The available logging
		levels and other terminology are as defined in the
		setlogmask(3) man page. The default is equivalent to syslog



 Hewlett-Packard Company	   - 10 -   HP-UX Release 11i: November 2000






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




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

 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 configuration language allow identification of interfaces using
      wildcard, interface 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



 Hewlett-Packard Company	   - 11 -   HP-UX Release 11i: November 2000






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




		     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 interface
		     list for changes. The default is every 15 seconds on
		     most systems, and 60 seconds on systems that pass
		     interface status changes through the routing socket
		     (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 primary is used, the primary interface
		     address (default) will be installed. If lowestip is
		     used, the address with the lowest IP address will be
		     installed. If keepall is used, all interface routes are
		     kept in the  kernel up to a maximum of RT_N_MULTIPATH
		     routes. This is a compile-time constant.  This is a
		     global parameter that may be overridden for interfaces
		     using the interface option.

	   interface interface_list
		Sets interface options on the specified interfaces. An
		interface list is all or a list of interface names (see
		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 properly. The
		     default preference is 0.

		down preference preference
		     Sets the preference for routes to this interface when
		     GateD does not believe it to be functioning properly,
		     but the kernel does not 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.





 Hewlett-Packard Company	   - 12 -   HP-UX Release 11i: November 2000






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




		simplex
		     Defines an interface as unable to hear its own
		     broadcast packets. Some systems define an interface as
		     simplex with the IFF_SIMPLEX flag, on others it needs
		     to be specified in the configuration file. On simplex
		     interfaces, packets from myself are assumed to have
		     been looped back in software and are not used as an
		     indication that the interface is functioning 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 kernel.
		     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 kernel.
		     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 interface when
		     multiple adresses are assigned to an interface like the
		     Service Guard environment. If primary is used, the
		     primary interface address (default) will be installed.
		     If lowestip is used, the address with the lowest IP
		     address will be installed. If keepall is used, all
		     interface routes are kept in the  kernel up to a
		     maximum of RT_N_MULTIPATH routes. This is a compile-
		     time constant. This parameter overrides the global
		     option for this interface.

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

		broadcast address
		     Defines the interface as broadcast capable (Ethernet or



 Hewlett-Packard Company	   - 13 -   HP-UX Release 11i: November 2000






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




		     Token Ring) and specifies the broadcast address.

		pointtopoint address
		     Defines the interface as a point-to-point interface
		     (SLIP or PPP) and specifies the address on the local
		     side.  The first address on the define statement
		     references the address of the host on the remote end of
		     the interface, the address specified after this
		     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 non-broadcast multiaccess (NBMA), such as an
		X.25 network.

		netmask mask
		     Specifies the subnetmask to be used on this interface.
		     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
      interfaces. 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
		Ethernet 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
		followed by a numeric part. This will match one specific
		interface. But be aware that on many systems, there can be
		more than one protocol (IP) address on a given physical
		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



 Hewlett-Packard Company	   - 14 -   HP-UX Release 11i: November 2000






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




		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
      create the specific parameter list for a given interface. If the same
      parameter is specified on more than one list, the parameters with the
      most specific interface 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. Packets
		sent to this interface are sent back to the originator. 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 additional address to
		this interface that is the same as the OSPF or BGP router
		id; this allows routing to a system based on the router id
		which will work if some interfaces are down.

	   broadcast
		This is a multi-access interface capable of a physical level
		broadcast, such as Ethernet, Token Ring and FDDI. This
		interface has an associated subnet mask and broadcast
		address. The interface route to 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.



 Hewlett-Packard Company	   - 15 -   HP-UX Release 11i: November 2000






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




		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 interface,
		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.

	   non-broadcast multi-access or nbma
		This type of interface is multi-access, 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
      forwarding table. This is to prevent protocols like OSPF from routing
      packets to this address across a serial interface when this system
      could be functioning as a host.

      When the status of an interface changes, GateD notifies all the
      protocols, 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 interface that has the same local and remote addresses, it
      assumes it is in some sort of loopback test mode.



 Hewlett-Packard Company	   - 16 -   HP-UX Release 11i: November 2000






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




 Definition Statements
      Definition statements are general configuration statements that relate
      to all of GateD or at least to more than one protocol. The three
      definition statements are autonomoussystem, routerid and martians. if
      used, 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
      system. 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
      controls 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 preferred.

    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 martians, are rejected by the routing software. This command
      allows additions to the list of martian addresses. See the section on
      Route Filtering 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 {



 Hewlett-Packard Company	   - 17 -   HP-UX Release 11i: November 2000






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




	  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
      exterior 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 acronym 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
	   considered 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
	   factor in choosing the best route. Round-trip time is the length
	   of time it takes a datagram to travel from the source and
	   destination. 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.



 Hewlett-Packard Company	   - 18 -   HP-UX Release 11i: November 2000






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




	   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
	   provides 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
      autonomous systems. Exterior protocols are only required when an
      autonomous 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 system to another autonomous system need to run an exterior
      routing protocol.	 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 architecture, EGP, an exterior routing protocol
	   which assumes a hierarchical 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
	   autonomous 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, organizational, or security (policy) considerations in
	   the routing decision. 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



 Hewlett-Packard Company	   - 19 -   HP-UX Release 11i: November 2000






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




	   availability of hosts it can send packets to and is used to
	   supplement a statically configured default router. This is the
	   preferred 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-
      vector, or Bellman-Ford routing protocol for local networks.  It
      classifies routers as active and passive (silent). Active routers
      advertise their routes (reachability information) to others; passive
      routers listen and update their routes based on advertisements, but do
      not advertise. Typically, routers run RIP in active mode, while hosts
      use passive mode.

      A router running RIP in active mode broadcasts updates at set
      intervals. 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 implementations, if a gateway is not heard from for 180 seconds,



 Hewlett-Packard Company	   - 20 -   HP-UX Release 11i: November 2000






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




      all routes from that gateway are deleted from the routing database.
      This 180 second interval also applies to deletion of specific routes.

      RIP version 2 (more commonly known as RIP II) add additional
      capabilities 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 mis-interpreted, RIP II can only use non-compatible
      features when its packets are multicast. On interfaces that are not
      capable of IP multicast, 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 packets.
	   This may result in packets crossing a network twice, which is
	   exactly what happens with RIP I. So this information is provided
	   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
	   network masks for all routes received. This assumption prevents
	   subnets with different netmasks from being included in RIP
	   packets. 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
	   packets, 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 mis-interpreted.
	   These network must only be provided in native RIP II packets that
	   are multicast.

      Authentication
	   RIP II packets may also contain one of two types of
	   authentication string that may be used to verify the validity of
	   the supplied routing data. Authentication may be used in RIP I
	   compatible 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



 Hewlett-Packard Company	   - 21 -   HP-UX Release 11i: November 2000






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




	   learn the authentication key by watching RIP packets.

	   The second method is still experimental and may change in
	   incompatible ways in future releases. This method uses the MD5
	   algorithm to create a crypto-checksum of a RIP packet and an
	   authentication 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
	   authentication 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
      subnetted (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 subnet.

      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]



 Hewlett-Packard Company	   - 22 -   HP-UX Release 11i: November 2000






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




	      [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. Normally 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 overridden 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.



 Hewlett-Packard Company	   - 23 -   HP-UX Release 11i: November 2000






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




	   interface interface_list
		Controls various attributes of sending RIP on specific
		interfaces. See the section on interface list specification
		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 specified
		     interface will be ignored. The default is to listen to
		     RIP packets on all non-loopback interfaces.

		ripin
		     This is the default. This argument may be necessary
		     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 non-broadcast 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 absolute 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



 Hewlett-Packard Company	   - 24 -   HP-UX Release 11i: November 2000






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




		     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 authentication type defaults to
		     simple. The password should be a quoted string with
		     between 0 and 16 characters.

		     If secondary is specified, this defines the secondary
		     authentication. If omitted, the primary authentication
		     is specified. The default is primary 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.




 Hewlett-Packard Company	   - 25 -   HP-UX Release 11i: November 2000






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




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

    Tracing options
      The policy option logs info whenever a new route is announce, the
      metric 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
      information which allows receivers to compute the shortest delay paths
      to destinations. 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
      metric. In order to do that, the following table is used:

	   Hops	   HELLO metric
	      0		  0
	      1		100
	      2		148
	      3		219



 Hewlett-Packard Company	   - 26 -   HP-UX Release 11i: November 2000






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




	      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
      subnetted (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 subnet.

      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



 Hewlett-Packard Company	   - 27 -   HP-UX Release 11i: November 2000






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




      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 overridden
		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 specification
		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 limitation 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 non-loopback interfaces.

		helloin
		     This is the default. This argument may be necessary



 Hewlett-Packard Company	   - 28 -   HP-UX Release 11i: November 2000






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




		     when nohelloin is used on a wildcard interface
		     descriptor.

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

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



 Hewlett-Packard Company	   - 29 -   HP-UX Release 11i: November 2000






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




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

    Tracing options
      The policy option logs info whenever a new route is announce, the
      metric 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
      distributes 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 multipath 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 Autonomous 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 metrics. 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
      shortest paths with itself as the root. This shortest-path tree gives
      the route to each destination in the AS. Externally derived routing
      information appears on the tree as leaves. The link-state
      advertisement format distinguishes between information acquired from



 Hewlett-Packard Company	   - 30 -   HP-UX Release 11i: November 2000






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




      external sources and information acquired from internal routers, so
      there is no ambiguity 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
      possible 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 contiguous 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
      configuration 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
      guarantees 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 protect the Internet and its
      users. There are two authentication schemes available. The first uses
      a simple authentication key of up to 8 characters and is standardized.
      The second is still experimental and uses the MD5 algorithm and an
      authentication key of up to 16 characters.



 Hewlett-Packard Company	   - 31 -   HP-UX Release 11i: November 2000






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




      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:



 Hewlett-Packard Company	   - 32 -   HP-UX Release 11i: November 2000






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




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

      ASE export rate
	   Because of the nature of OSPF, the rate at which ASEs are flooded



 Hewlett-Packard Company	   - 33 -   HP-UX Release 11i: November 2000






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




	   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
		     generated 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 non-standard OSPF
	   packets which generate a text response from OSPF. By default
	   these requests are not authenticated, if an authentication key is
	   configured, the incoming requests must match the specified
	   authentication 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
	   interface 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
		authentication, 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



 Hewlett-Packard Company	   - 34 -   HP-UX Release 11i: November 2000






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




		advertised into other areas as inter-area routes. Instead,
		the specified ranges are advertised as summary network LSAs.
		If restrict is specified, the summary network LSAs are not
		advertised. Intra-area LSAs that do not fall into any range
		are also advertised as summary network 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 section 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 specified
		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 interface_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 non-zero value may be specified.

		Interface parameters common to all types of interfaces are:

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

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





 Hewlett-Packard Company	   - 35 -   HP-UX Release 11i: November 2000






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




		     priority priority
			  A number between 0 and 255 specifying the priority
			  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 configured 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 multicast
			  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 non-broadcast multi-access
		(NBMA) media. Since an OSPF broadcast media must support IP



 Hewlett-Packard Company	   - 36 -   HP-UX Release 11i: November 2000






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




		multicasting, a broadcast capable media, such as Ethernet,
		that does not support IP multicasting must be configured as
		a non-broadcast interface.

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

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

		     routers
			  By definition it is not possible to send broadcast
			  packets to discover OSPF neighbors on a non-
			  broadcast, so all neighbors must be configured.
			  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 connectivity
		of the backbone area. The neighborid is the router_id of the
		other end of the virtual link. The transit area specified
		must also configured on this system. All standard interface
		parameters defined by the interface 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
      transitions.

	   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
		synchronizing OSPF databases.

	   request
		OSPF Link State Request packets which are used in



 Hewlett-Packard Company	   - 37 -   HP-UX Release 11i: November 2000






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




		synchronizing OSPF databases.

	   lsu	OSPF Link State Update packets which are used in
		synchronizing OSPF databases.

	   ack	OSPF Link State Ack packets which are used in synchronizing
		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
      autonomous systems. Unlike interior protocols, EGP propagates only
      reachability indications, not true metrics. EGP updates contain
      metrics, called distances which range from 0 to 255. GateD will only
      compare EGP distances learned from the same AS.  them.

      Before EGP sends routing information to a remote router, it must
      establish 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 ]



 Hewlett-Packard Company	   - 38 -   HP-UX Release 11i: November 2000






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




		  [ 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 overridden 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 exporting routes to EGP
		neighbors. This metric may be overridden by a metric
		specified on the neighbor or group statements 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
		autonomous system. Parameters specified on the group clause
		apply to all of the subsidiary neighbors unless explicitly
		overridden on a neighbor clause. Any number of group clauses
		may specify any number of neighbor clauses.





 Hewlett-Packard Company	   - 39 -   HP-UX Release 11i: November 2000






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




		Any parameters from the neighbor subclause may be specified
		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 specified, 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 usually
			  only used when masquerading as another autonomous
			  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 parameters 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.




 Hewlett-Packard Company	   - 40 -   HP-UX Release 11i: November 2000






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




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

		     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 network
			  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



 Hewlett-Packard Company	   - 41 -   HP-UX Release 11i: November 2000






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




			  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 packets, GateD
			  stops trying to acquire the neighbor. Setting a
			  larger interval gives the neighbor a better chance
			  to respond. Minhello is an alias for the P1 value
			  defined in the EGP specification.

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

		     ttl ttl
			  By default, GateD sets the IP TTL for local
			  neighbors to one and the TTL for non-local
			  neighbors to 255. This option is provided when
			  attempting to communicate with improperly
			  functioning 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):




 Hewlett-Packard Company	   - 42 -   HP-UX Release 11i: November 2000






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




	   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
      autonomous systems as well as between transit and stub autonomous
      systems. 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 routing 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 preference 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
      capability 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



 Hewlett-Packard Company	   - 43 -   HP-UX Release 11i: November 2000






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




      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
      version 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 neighbor 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 considered 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 metric 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
      connection, 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
      forwarding. 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



 Hewlett-Packard Company	   - 44 -   HP-UX Release 11i: November 2000






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




      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
      common 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 connect 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 ]



 Hewlett-Packard Company	   - 45 -   HP-UX Release 11i: November 2000






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




		  [ 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
      metric.

	   preference preference
		Sets the preference for routes learned from RIP. The default
		preference is 170. This preference may be overridden 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
      combination 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 interface.



 Hewlett-Packard Company	   - 46 -   HP-UX Release 11i: November 2000






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




	   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 readvertised
		with the received metric.

	   group type igp peeras autonomous_system proto proto
		An internal group that runs in association with an interior
		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 internal 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 advertised routes are routes that IGP already exports.

	   interface_list
	   group type routing peeras autonomous_system proto proto interface
		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 computes
		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 internal 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 propagated 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.




 Hewlett-Packard Company	   - 47 -   HP-UX Release 11i: November 2000






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




	   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 network. 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 advertisement. 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 subclause 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
      configured 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
      specify 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.





 Hewlett-Packard Company	   - 48 -   HP-UX Release 11i: November 2000






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




    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 representing
		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 preference 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



 Hewlett-Packard Company	   - 49 -   HP-UX Release 11i: November 2000






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




		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 version 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
		configures 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 features 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 numbers.

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



 Hewlett-Packard Company	   - 50 -   HP-UX Release 11i: November 2000






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




	   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 aggregate
		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 completely 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 advertised
		to version 4 external peers. This can be useful to avoid
		advertising such routes to peer which would incorrectly
		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 non-local peers to 255. This option mainly is
		provided when attempting to communicate with improperly
		functioning routers that ignore packets sent with a TTL of
		one.  Not all kernels allow the TTL to be specified 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.



 Hewlett-Packard Company	   - 51 -   HP-UX Release 11i: November 2000






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




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

	   update
		BGP UPDATE packets which are used to pass network
		reachability 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
      messages 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.



 Hewlett-Packard Company	   - 52 -   HP-UX Release 11i: November 2000






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




	   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 redirect. 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
      figure 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 systems 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
      possible 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 manually configured off in these cases.

      Note that in accordance with the latest IETF Router Requirements
      document, 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
      redirects, only from listening to them.

    The Redirect Statement
      redirect yes | no | on | off
      [ {
	  preference preference ;



 Hewlett-Packard Company	   - 53 -   HP-UX Release 11i: November 2000






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




	  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 description
		of the interface_list. The possible parameters are:

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

		     redirects
			  This is the default. This argument may be
			  necessary 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 network(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 non-error 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



 Hewlett-Packard Company	   - 54 -   HP-UX Release 11i: November 2000






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




      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
      existence to hosts. It does this by periodically multicasting or
      broadcasting 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
      indicating 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 Advertisement. 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 tracing options



 Hewlett-Packard Company	   - 55 -   HP-UX Release 11i: November 2000






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




		below.)

	   interface interface_list
		Specifies the parameters that apply to physical interfaces.
		Note a slight difference in convention from the rest of
		GateD, interface specifies just physical interfaces (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 broadcast
			  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 seconds).

		     minadvinterval time
			  The minimum time allowed between sending
			  unsolicited broadcast or multicast Router
			  Advertisements from the interface. Must be no less
			  than 3 seconds and no greater than maxadvinterval.
			  The default is 0.75 * maxadvinterval.

		     lifetime time
			  The lifetime of addresses in a Router
			  Advertisement. 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, interface
		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



 Hewlett-Packard Company	   - 56 -   HP-UX Release 11i: November 2000






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




			  included in a broadcast Router Advertisement
			  because this system does not support IP
			  multicasting, 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 Advertisement
			  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 Advertisement.
			  If the system does not support IP multicasting,
			  the address(es) will not be included. If the
			  system supports IP multicasting, 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 multicasting, 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
      reconfigured, a host may send a few Router Solicitations to the all-
      routers multicast address, 224.0.0.2, or the interface broadcast
      address.





 Hewlett-Packard Company	   - 57 -   HP-UX Release 11i: November 2000






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




      When a Router Advertisement with non-zero 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
      Advertisement 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
		Statements 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 interfaces.
		Note a slight difference in convention from the rest of
		GateD, interface specifies just physical interfaces (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
				  interface(s).




 Hewlett-Packard Company	   - 58 -   HP-UX Release 11i: November 2000






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




		     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
				  Solicitations 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 performed.

		     solicit	  Specifies that initial Router
				  Solicitations 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
      typical kernel forwarding table take a non-trivial 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



 Hewlett-Packard Company	   - 59 -   HP-UX Release 11i: November 2000






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




      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
      characteristics 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



 Hewlett-Packard Company	   - 60 -   HP-UX Release 11i: November 2000






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




		ICMP redirects.

	   Blind updates
		GateD is not able to detect changes to the forwarding table
		resulting from the use of the 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 operation
		supported, to change a route that exists in the kernel, 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
      introduced 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 interesting of
		these is an indication that a redirect has modified 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, including
		the route command are received via the routing socket. This
		allows GateD to insure that the kernel forwarding 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 versions of
		the routing socket code had bugs in the change message



 Hewlett-Packard Company	   - 61 -   HP-UX Release 11i: November 2000






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




		processing. There are compilation time and configuration
		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
      remnants 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
      protocols 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
      administrator 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 forwarding 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
      kernel 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()
      interface, which takes different parameters, but otherwise functions
      identically.

    Reading the forwarding table via OS specific methods
      Some operating systems, for example SunOS 5, define their own method



 Hewlett-Packard Company	   - 62 -   HP-UX Release 11i: November 2000






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




      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 SIOCGIFCONF
      ioctl interface is used to read the kernel interface list. Using this
      method a list of interfaces and some basic information about them is
      return by the SIOCGIFCONF 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
      messages 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 IFF_BROADCAST set, assuming that their drivers are handled the
      same as Ethernet drivers. On some systems, such as SunOS 4 and SunOS
      5, system specific interfaces are used to learn this information





 Hewlett-Packard Company	   - 63 -   HP-UX Release 11i: November 2000






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




      The interface physical addresses are useful for IS-IS, for IP
      protocols, 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
      generation, 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 systems 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 originators. 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 previous
		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 interface
		route it sets the RTF_STATIC flag. This signals to GateD
		that said route was added by the systems administrator and
		should be retained.

    Kernel Configuration
      kernel {
	  options
	      [ nochange ]
	      [ noflushatexit ]
	      [ remnantholdtime time ]



 Hewlett-Packard Company	   - 64 -   HP-UX Release 11i: November 2000






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




	      ;
	  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 useful
			  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 overridden. This
			  option allows the interval to be configured 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/external



 Hewlett-Packard Company	   - 65 -   HP-UX Release 11i: November 2000






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




		order.	It queues interface routes first, followed by
		internal routes, followed by external routes, and processes
		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 protocols
		is called a flash update. The kernel forwarding table
		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
			  processed during a flash update. Interior
			  specifies that interior routes (See the definition
			  of interior gateway protocols) will also be
			  installed. All specifies the inclusion of exterior
			  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 behavior
		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 protocol 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:




 Hewlett-Packard Company	   - 66 -   HP-UX Release 11i: November 2000






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




		     limit number
			  Specifies the number of route which may be
			  processed 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 processed
			  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
      configuration 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 kernel
		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 ]



 Hewlett-Packard Company	   - 67 -   HP-UX Release 11i: November 2000






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




	      [ 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 gateways listed
		are available on directly attached interfaces. 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
		     interface_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 routing 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



 Hewlett-Packard Company	   - 68 -   HP-UX Release 11i: November 2000






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




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

		noinstall
		     Normally the route with the lowest preference is
		     installed in the kernel forwarding table and is the
		     route exported to other protocols. When noinstall 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
      statements 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.




 Hewlett-Packard Company	   - 69 -   HP-UX Release 11i: November 2000






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




    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 specified by the number
		of contiguous one bits.

		If no additional parameters are specified, any destination
		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 subnets, and
		any hosts will be match. The two optional modifiers 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




 Hewlett-Packard Company	   - 70 -   HP-UX Release 11i: November 2000






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




	   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 destination 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
      number 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 routing 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 complete. 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:



 Hewlett-Packard Company	   - 71 -   HP-UX Release 11i: November 2000






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




	   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
				    expression 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
	   non-negative 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 repetitions.
	   This is shorthand for {1,}.

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



 Hewlett-Packard Company	   - 72 -   HP-UX Release 11i: November 2000






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




      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
      statements. 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 prevents 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 ;



 Hewlett-Packard Company	   - 73 -   HP-UX Release 11i: November 2000






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




      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
      supports controlling propagation by the use of an AS path regular
      expressions, which are documented in the section on Matching AS paths.
      Note that EGP and BGP versions 2 and 3 only support the propagation of
      natural 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
      keyword in the routing table with a negative preference. A negative
      preference prevents a route from becoming active, which prevents it
      from being installed in the forwarding table, or exported to other
      protocols. 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.





 Hewlett-Packard Company	   - 74 -   HP-UX Release 11i: November 2000






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




    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
      specified, 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 preference.

 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
      statement, 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





 Hewlett-Packard Company	   - 75 -   HP-UX Release 11i: November 2000






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




	   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
		specifies 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



 Hewlett-Packard Company	   - 76 -   HP-UX Release 11i: November 2000






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




      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
      actually 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
      overridden; 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
      meaningless. 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,
      interface 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.



 Hewlett-Packard Company	   - 77 -   HP-UX Release 11i: November 2000






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




    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 ) ] ;
      } ;



 Hewlett-Packard Company	   - 78 -   HP-UX Release 11i: November 2000






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




      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 non-routing protocols
    Non-routing 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 table 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.

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

      These protocols may only be referenced by protocol.





 Hewlett-Packard Company	   - 79 -   HP-UX Release 11i: November 2000






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




	   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 section
		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
      specifies 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
      autonomous 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



 Hewlett-Packard Company	   - 80 -   HP-UX Release 11i: November 2000






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




      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 ;



 Hewlett-Packard Company	   - 81 -   HP-UX Release 11i: November 2000






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




	  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
		contributing 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



 Hewlett-Packard Company	   - 82 -   HP-UX Release 11i: November 2000






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




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

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

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

      autonomous system
	   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
	   developed, it has become common for a single AS to use several
	   interior 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 administration
	   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.

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

      cost An OSPF metric. See metric.





 Hewlett-Packard Company	   - 83 -   HP-UX Release 11i: November 2000






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




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

      designated router
	   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 multiaccess network and assists
	   in running the protocol. The designated router is elected by the
	   HELLO protocol.

      destination
	   Any network or any host.

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

      egp
      exterior gateway protocol
      exterior routing protocol
	   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.

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

      gateway
	   An intermediate destination by which packets 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.

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

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

      host The IP address of any host. Usually specified 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 symbolic hostname. For example
	   gated.cornell.edu or nic.ddn.mil. The numeric forms are much



 Hewlett-Packard Company	   - 84 -   HP-UX Release 11i: November 2000






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




	   preferred over the symbolic form.

      interface
	   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 interface. As with any host address it may be
	   specified symbolically.

      interface
	   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 configuration language allow identification of interfaces
	   using wildcard, interface 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. Dynamic
	   interfaces can be added or deleted and indicated as up or down as
	   well as changes to address, netmask and metric parameters.

      igp
      interior gateway protocol
      interior routing protocol
	   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
	   Overview.

      interface_list
	   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.
	   See the section on interface lists for more information.

      IS-IS
	   One of a class of interior gateway protocols.

      local_address
	   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 interface. As with any host address it may be
	   specified symbolically.

      mask A means of subdividing networks using address modification. 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.

      mask length
	   The number of significant bits in the mask.




 Hewlett-Packard Company	   - 85 -   HP-UX Release 11i: November 2000






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




      metric
	   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 depending 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 Overview.) to reach a destination.

		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

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

      natural mask
	   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).

      neighbor
	   Another router which with implicit or explicit communication is
	   established by a routing protocol. Neighbors are usually on a
	   shared network, but not always. This term is mostly used in OSPF
	   and EGP. Usually synonymous with peer.

      neighboring routers
	   Two routers that have interfaces to a common network. On
	   multiaccess networks, routers are dynamically discovered by the
	   OSPF HELLO protocol.

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




 Hewlett-Packard Company	   - 86 -   HP-UX Release 11i: November 2000






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




      network
	   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 hexadecimal string preceded by 0x with an even
	   number of digits between two and eight. For example 0x??????,
	   0x???? or 0x0a.  Also allowed is the symbolic value default which
	   has the distinguished value 0.0.0.0, the default network. If
	   options noresolv is not specified, a symbolic network name can be
	   used, for example nr-tech-prod, cornellu-net and arpanet. The
	   numeric forms are much preferred over the symbolic form.

      number
	   A positive integer.

      OSPF
      Open Shortest Path First
	   One of a class of interior gateway protocols, described in more
	   detail in the OSPF section of the Protocol Overview.

      ospf_area
      peer Another router which with implicit or explicit communication is
	   established by a routing protocol. Peers are usually on a shared
	   network, but not always. This term is mostly used by BGP.
	   Usually synonymous with neighbor.

      port A UDP or TCP port number. Valid values are from 1 through 65535
	   inclusive.

      preference
	   A preference is a value between 0 (zero) and 255 used to select
	   between many routes to the same destination. The route with the
	   best (numerically lowest) preference is as the active route. The
	   active route is the one installed in the kernel forwarding table
	   and exported to other protocols. Preference zero is usually
	   reserved for routes to directly attached interfaces. A default
	   preference is assigned to each source from which GateD receives
	   routes. (See Preference.)

      prefix
	   A contiguous mask covering the most significant bits of an
	   address. The prefix length specifies how many bits are covered.

      QoS
      quality of service
	   The OSI equivalent of TOS.

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



 Hewlett-Packard Company	   - 87 -   HP-UX Release 11i: November 2000






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




      router id
	   A 32-bit number assigned to each router running the OSPF
	   protocol. This number uniquely identifies the router within the
	   autonomous system.

      router_id
	   An IP address used as unique identifier assigned to represent a
	   specific router. This is usually the address of an attached
	   interface.

      RIB
      routing information base
      routing database
      routing table
	   The repository of all of the GateD retained routing information,
	   used to make decisions and as a source for routing information
	   which is propagated.

      simplex
	   An interface may be marked as simplex either by the kernel, or by
	   interface configuration. A simplex interface is an interface on a
	   broadcast media that is not capable of receiving packets it
	   broadcasts.

	   GateD takes advantage of interfaces that are capable of receiving
	   their own broadcast packets to monitor whether an interface
	   appears to be functioning properly.

      time A time value, usually a time interval. It may be specified in any
	   one of the following forms:

		number			 A non-negative decimal number of
					 seconds. For example, 27, 60 or
					 3600.

		number:number		 A non-negative decimal number of
					 minutes followed by a seconds value
					 in the range of zero to 59
					 inclusive. For example, 0:27, 1:00
					 or 60:00.

		number:number:number	 A non-negative decimal number of
					 hours followed by a minutes value
					 in the range of zero to 59
					 inclusive followed by a seconds
					 value in the range of zero to 59
					 inclusive. For example, 0:00:27,
					 0:01:00 or 1:00:00.

      time to live




 Hewlett-Packard Company	   - 88 -   HP-UX Release 11i: November 2000






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




      ttl  The Time To Live (TTL) of an IP packet. Valid values are from one
	   (1) through 255 inclusive.

      TOS
      type of service
	   The type of service is for internet service quality selection.
	   The type of service is specified along the abstract parameters
	   precedence, delay, throughput, reliability, and cost.  These
	   abstract parameters are to be mapped into the actual service
	   parameters of the particular networks the datagram traverses. The
	   vast majority of IP traffic today uses the default type of
	   service.

 WARNINGS
      gated contains provisions for BGP protocol, but it is not officially
      supported by HP at the present time.  The route aggregation and
      generation statements which generate a more general route from
      compressing the specific routes through the explicit configuration are
      not supported in this release.

 AUTHORS
      See gated(1M).

 SEE ALSO
      RFC 827:	     E. Rosen, Exterior Gateway Protocol EGP

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

      RFC 904:	     D. Mills, Exterior Gateway Protocol formal
		     specification

      RFC 1058:	     C. Hedrick, Routing Information Protocol

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

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

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

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

      RFC 1245:	     J. Moy, OSPF Protocol Analysis

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

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




 Hewlett-Packard Company	   - 89 -   HP-UX Release 11i: November 2000






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




      RFC 1256:	     S. Deering, ICMP Router Discovery Messages

      RFC 1265:	     Y. Rekhter, BGP Protocol Analysis

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

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

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

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

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

      RFC 1370:	     Internet Architecture Board Applicability Statement for
		     OSPF

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

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

      RFC 1403:	     K. Varadhan, BGP OSPF Interaction

      RFC 1583:	     J. Moy, OSPF Version 2

























 Hewlett-Packard Company	   - 90 -   HP-UX Release 11i: November 2000