unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

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



gated.proto(4)						       gated.proto(4)



NAME

  gated.proto -	Gate daemon configuration file (protocol statements)

DESCRIPTION

  Routing protocols determine the "best" route to each destination and dis-
  tribute routing information among the	systems	on a network.  Routing proto-
  cols are divided into	two general groups: interior (intra-domain) and	exte-
  rior (inter-domain) protocols. The gated software combines management	of
  the interior and exterior routing protocols in one software daemon.

  Intra-Domain Routing Protocols


  Intra-domain (interior) protocols are	used to	exchange reachability infor-
  mation within	an autonomous system (AS).  They are referred to as a class
  by the acronym IGP. The following interior protocols are supported:

  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 destina-
      tion.  The longest path that RIP accepts is 15 hops. If the metric is
      greater than 15, a destination is	considered unreachable and gated dis-
      cards the	route.	RIP assumes the	best route is the one that uses	the
      fewest gateways (the shortest path), not taking into account congestion
      or delay on route.

      The RIP version 1	protocol is described in RFC 1058; the RIP version 2
      protocol is described in RFC 11723.

  OSPF
      Open Shortest Path First (OSPF) 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 2178; OSPF Version 2 is described in RFC	1583.
      The OSPF Version 2 MIB is	defined	in RFC 1850.  Other related documents
      are RFC 1245, RFC	1246, and RFC 1370.

  Exterior Routing Protocols


  Exterior protocols are used to exchange routing information between auto-
  nomous 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.  The following
  exterior protocols are supported by gated:

  EGP Exterior Gateway Protocol	(EGP).	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 architec-
      ture, EGP, an exterior routing protocol that assumes a hierarchical
      structure, became	less effective.

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

  BGP Border Gateway Protocol (BGP) 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 attri-
      butes to provide more information	about each route as an aid in select-
      ing the best route.  Path	attributes can include,	for example, adminis-
      trative 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, and version 4 in RFC 1771.	 The version 3 MIB is
      described	in RFC 1269.  The documents RFC	1164, RFC 1268,	and RFC	1772
      describe the application of version 2, 3,	and 4 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.

      The BGP-4	MIB is draft standard, but schedule to go to standard. Other
      references for BGP are: RFC 1997 for BGP Communities, RFC	1966 for BGP
      Route Reflection,	RFC 1966 for BGP AS Confederations, and	RFC 1403 for
      BGP - OSPF interaction.  A useful	application document is	RFC 1998, "An
      Application of the BGP Community Attribute in Multi-home Routing".

  Other	Routing	Protocols


  The following	routing	protocol is also supported:

  Router Discovery
      The Router Discovery protocol is used to inform hosts of the availabil-
      ity of hosts it can send packets to and is used to supplement a stati-
      cally 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 net-
  work 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
  that are reachable through one other gateway are two hops, and so on.
  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
  encounters 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 might be	substantially faster that a
  path with a hop count	2 that crosses two slow-speed serial lines.  To	com-
  pensate 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, 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 data-
  base.	 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 infor-
  mation 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 destina-
  tion 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, 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)	adds 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 misinterpreted,
  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 pack-
  ets are used that do not contain potentially confusing information.

  The following	is a list of main RIP II enhancements:

  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	hav-
      ing to cross a network twice.

      RIP I routers ignore next	hop information	in RIP II packets.  This
      might 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 dif-
      ferent 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	net-
      works that would be misinterpreted.  These network must only be pro-
      vided in native RIP II packets that are multicast.

      RIP-I derives the	network	mask of	received networks and hosts from the
      network mask of the interface the	packet via which the packet was
      received.	 If a received network or host is on the same natural network
      as the interface over which it was received and that network is subnet-
      ted (the specified mask is more specific than the	natural	netmask), the
      subnet mask is applied to	the destination.  If bits outside the mask
      are set it is assumed to be a host, otherwise it is assumed to be	a
      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 can be used to reject it.

  Authentication
      RIP II packets can also contain one of two types of authentication
      string that can be used to verify	the validity of	the supplied routing
      data.  Authentication can	be used	in RIP I-compatible RIP	II packets,
      but be aware that	RIP I routers ignore it.

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

      The second method	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 receiv-
      ing 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 ori-
      ginated 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 Syntax


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

  The rip statement enables or disables	RIP.  If the rip statement is not
  specified the	default	is rip on;.  If	enabled, RIP assumes nobroadcast when
  there	is only	one interface and broadcast when there is more than one.  The
  following rip	options	are supported:

  broadcast
      Specifies	that RIP packets are 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 are not broadcast on attached interfaces,
      even if there are	more than one.	If a sourcegateways clause is
      present, routes are unicast directly to that gateway.

  nocheckzero
      Specifies	that RIP should	not make sure that reserved fields in incom-
      ing version 1 RIP	packets	are zero.  Normally RIP	rejects	packets	when
      the reserved fields are zero.

  preference preference
      Sets the preference for routes learned from RIP.	The default prefer-
      ence is 100.  This preference can	be overridden by a preference speci-
      fied 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 can be overridden by a metric specified in export pol-
      icy.

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

  interface interface_list
      Controls various attributes of sending RIP on specific interfaces.  See
      the Interface Lists section in gated.conf(4) for the description of the
      interface_list.

      Note that	if there are multiple interfaces configured on the same	sub-
      net, RIP updates are sent	from first one on which	RIP output is config-
      ured.

      The following interface parameters are supported:

      noripin
	Specifies that RIP packets received via	the specified interface	are
	ignored.  The default is to listen to RIP packets on all non-loopback
	interfaces.

      ripin
	This is	the default.  This argument might be necessary when noripin
	is used	on a wild card interface descriptor.

      noripout
	Specifies that no RIP packets are sent on the specified	interfaces.
	The default is to send RIP on all broadcast and	non-broadcast inter-
	faces 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 might be necessary	when
	noripin	is used	on a wild card 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 is used as the absolute value, the kernel	metric is not
	added.	This option is used to make this router	prefer RIP routes
	learned	via the	specified interface(s) less than RIP routes from
	other interfaces.

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

      version 1
	Specifies that RIP packets sent	via the	specified interface(s) are
	version	1 packets.  This is the	default.

      version 2
	Specifies that RIP version 2 packets are sent on the specified
	interfaces(s).	If IP multicast	support	is available on	this inter-
	face, the default is to	send full version 2 packets.  If it is not
	available, version 1 compatible	version	2 packets are 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]
	Defines	the authentication type	to use.	 It applies only to RIP	ver-
	sion 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 a	list of	host names or IP addresses.   By default, all
      routers on the shared network are	trusted	to supply routing informa-
      tion.  But if the	trustedgateways	clause is specified, only updates
      from the gateways	in the list are	accepted.

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

  traceoptions trace_options
      Specifies	the tracing options for	RIP.  (See the Trace Options State-
      ment section in gated.conf(4) and	the RIP-specific tracing options that
      follow.)




  RIP Tracing options


  The policy option logs info whenever a new route is announced, the metric
  being	announced changes, or a	route goes or leaves holddown.	The following
  packet tracing options, which	can be modified	with detail, send, or recv,
  are supported:

  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 con-
      tains routing information.

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

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 net-
  works	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 adver-
  tisements of all routers.  Each participating	router distributes its local
  state	(the router's usable interfaces	and reachable neighbors) 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 con-
  cept 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 adds 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 inter-
  nal 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 external sources and information acquired
  from internal	routers, so there is no	ambiguity about	the source or relia-
  bility of routes.  Externally	derived	routing	information (for example,
  routes learned from EGP or BGP) is passed transparently through the auto-
  nomous system	and is kept separate from OSPF's 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 adminis-
  trators to install multiple routes to	a given	destination for	each type of
  service (for example,	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 rout-
  ing database with a preference of 10.	 It would be a violation of the	pro-
  tocol	if an OSPF router did not participate fully in the area's OSPF,	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	con-
  tiguous despite the physical reality.

  All routers in an area must agree on that area's parameters.	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 that area's configuration.	 Misconfi-
  guration will	lead to	adjacencies not	forming	between	neighbors, and rout-
  ing information might	not flow, or even loop.

  Authentication


  All OSPF protocol exchanges can be authenticated.  Authentication guaran-
  tees that routing information	is only	imported from trusted routers, to
  protect the Internet and its users.  A variety of authentication schemes
  can be used but a single scheme must be configured for each interface.
  This enables some interfaces to use much stricter authentication than	oth-
  ers. The following authentication schemes are	available:

    +  No authentication. To use no authentication, add	the following line to
       the appropriate OSPF interface statements:
	    auth none ;

    +  Simple authentication key.  Use this to prevent certain routers from
       exchanging OSPF packets.	The interfaces that the	packets	are to be
       sent on still need to be	trusted	because	the key	will be	placed in the
       packets and can be seen by anyone with access to	the network.

       To specify simple authentication, add the following line	to your	OSPF
       interface statements:
	    auth simple	auth_key;
       In the preceding	line, auth_key is a string of up to 8 characters, and
       is standardized.

    +  MD5 authentication. Use this when you do	not trust other	users of your
       network.	 This system works by using shared secret keys.	Because	the
       keys are	used to	sign the packets with an MD5 checksum, they cannot be
       forged or tampered with.	 Because the keys are not included in the
       packet, snooping	the key	is not possible. Users of the network can
       still snoop the contents	of packets, however, because the packets are
       not encrypted.

       MD5 authentication is compliant with the	OSPF specification in RFC
       2178. This specification	uses the MD5 algorithm and an authentication
       key of up to 16 characters.  RFC	2178 allows multiple MD5 keys per
       interface. Each key has two associated time ranges.

       To specify a single MD5 key on an interface, add	the following to the
       appropriate OSPF	interface statements:
	    auth md5 md5-key
       where md5-key is:
	    key	your-key id id-number [	{
		[ start-generate date-time ; ]
		[ stop-generate	date-time ; ]
		[ start-accept date-time ; ]
		[ stop-accept date-time	; ]
	    } ]	;
       Where id-number is an integer with a value between 1 and	255 and
       date-time is in the format YYYY/MM/DD HH:MM (If any time	fields are
       used, all are required).

       If no value is given for	the time ranges, the default values are:

	 -- key	is always generated

	 -- key	is always accepted

	 --

	    Thus, if you always	want your key to be accepted, simply specify
	    a sequence such as:
		 auth md5 key "mikeyone" id 1;
	    To specify multiple	MD5 keys on an interface, add the following
	    to the appropriate OSPF interface statements:
		 auth md5 {
		      md5-key
		      md5-key
			 .
			 .
			 .
		      md5-key
		 } ;
	    For	example, two routers may start out generating key 1 and	want
	    to switch to key 2 at 6:00 GMT.  In	order to make the transition
	    between keys easier, the routers agree to stop generating key 1
	    at 6:00 GMT, but accept key	1 until	6:10 GMT.  Key 2 is accepted
	    10 minutes before the planned switch time (5:50 GMT).  These
	    overlapping	ranges allow the clocks	on the routers to be slightly
	    out	of syncronization.  You	can specify this sequence of keys as
	    follows:
		 auth md5 {
		     key "mikeyone" id 1 {
			 stop-generate 1999/05/01 06:00;
			 stop-accept 1999/05/01	06:10;
		     };
		     key "mikeytwo" id 2 {
			 start-generate	1999/05/01 06:00;
			 start-accept 1999/05/01 05:50;
		     };
		 };

  OSPF Syntax


  ospf yes | no	| on | off [ {
      defaults {
	 preference preference ;
	 cost cost ;
	 tag [as] tag ;
	 type 1	| 2 ;
	 inherit-metric	;
      }	;
      exportlimit routes ;
      exportinterval time ;
      traceoptions trace_options ;
      syslog [first pktcnt][ every every_pktcnt] ;
      monitorauthkey authkey ;
      area area	| backbone {
	 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] [ {
	     enable | disable ;
	     interface_parameters
	 } ] ;
	 interface interface_list nonbroadcast [cost cost] [ {
	     pollinterval time ;
	     routers {
		 gateway [eligible] ;
	     } ;
	     interface_parameters
	 } ] ;
	 Backbone only:
	 virtuallink neighborid	router_id transitarea area {
	     interface_parameters
	 } ;
      }	;
  } ] ;

  defaults
      Specify the defaults used	when importing OSPF Autonomous System Exter-
      nal (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	rout-
	ing table into OSPF as an ASE.	The default value is 1.	 This can 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 might be used by export policy to	filter routes.	When
	OSPF is	interacting with an EGP, the tag field can be used to pro-
	pagate 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 can	be explicitly changed here
	and overridden in export policy.

      inherit-metric
	Enables	an OSPF	ASE route to inherit the metric	of the external	route
	when no	metric is specified on the export. This	option maintains com-
	patibility with	all the	current	export functions:

	  +  A metric specified	on the export will take	precedence.

	  +  The cost specified	in the default will be used if inherit-metric
	     is	not specified.

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

      exportinterval time
	Specifies how often a batch of ASE link	state advertisements are gen-
	erated and flooded into	OSPF.  The default is once per second.

      exportlimit routes
	Specifies how many ASEs	are generated and flooded in each batch.  The
	default	is 100.

  traceoptions trace_options
      Specifies	the tracing options for	OSPF.  (See gated.conf(4) and the
      OSPF tracing options section.)

  yslog	[first pktcnt] [every every_pktcnt]
      Specifies	the tracing options for	logging	OSPF packets. The log will
      contain the first	pkcnt packets for every	type of	OSPF packet.  After
      the first	pckcnt packets,	the syslog will	only save one message per
      every every_pktcnt packets.

  monitorauthkey authkey
      OSPF state can be	queried	using the ospf_monitor (This should be a
      hyperlink) utility.  This	utility	sends non-standard OSPF	packets	that
      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
      can be changed by	these packets, but the act of querying OSPF can	util-
      ize system resources.

  area area | backbone
      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 can only be configured using	the backbone keyword, it can-
      not be specified as area 0.  The backbone	interface can be a virtual-
      link.

      stub [cost cost]
	A stub area is one in which there are no ASE routes.  If a cost	is
	specified, this	injects	a default route	into the area with the speci-
	fied cost.

      networks
	The networks list describes the	scope of an area.  Intra-area LSAs
	that fall within the specified ranges are not advertised into other
	areas as inter-area routes.  Instead, the specified ranges are adver-
	tised 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" in	gated.control(4) for more detail
	about specifying ranges.

      stubhosts
	Specifies directly attached hosts that should be advertised as reach-
	able 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 an additional address to the loopback
	interface (one not on the 127 network) and advertise it	as a stub
	host.  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 router's
	interface addresses, which might 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 "Interfaces Statement" section in	gated.conf(4) for the
      description of the interface_list	parameters.

      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 desti-
      nation.  The default cost	is one,	but another non-zero value can be
      specified.

      This form	has one	unique parameter:

      enable | disable
	Enables	or disables the	interface.
  See the "Interface Parameters" section for a list of parameters common to
  all interface	types.

  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) medium.	Because	an
      OSPF broadcast medium must support IP multicasting, a broadcast-capable
      medium 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 previously	and 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 poll	interval.

      routers
	By definition, it is not possible to send broadcast packets to dis-
	cover OSPF neighbors on	a non-broadcast, so all	neighbors must be
	configured.  The list includes one or more neighbors and an indica-
	tion of	their eligibility to become a designated router.
  See the "Interface Parameters" section for a list of parameters common to
  all interface	types.

  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 can be specified on a virtual link.

      See the "Interface Parameters" section for a list	of parameters common
      to all interface types.

  Interface Parameters


  The following	interface parameters are common	to all types of	interfaces:

  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.  The transitdelay parameter takes into	account
    transmission and propagation delays	and must be greater than 0.

  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 net-
    work 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	length of time,	in seconds, a router's neighbors wait to hear a
    router's Hello packets before the they declare the router down.

  passive
    Do not send	or receive packets on this interface. This has the effect of
    originating	a stub link to this interface into the domain.

  auth [none | simple auth_key | md5 md5-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.  See the
    "Authentication" section for additional information.

    Specify MD5	authentication with the	md5-key, which is specified as:
	 key auth-key id id-number [ {
	     [start-generate date-time;]
	     [stop-generate date-time;]
	     [start-accept date-time;]
	     [stop-accept date-time;]
	 }];
    Where auth-key is a	one-to-eight character string, id-number is an
    integer with a value between 1 and 255, and	date-time is in	the format
    YYYY/MM/DD HH:MM.  If any time fields are used, all	are required.
     See the "Authentication" section for additional information.

  secondary [none | simple | md5] auth_key
    Used by OSPF authentication	to generate and	verify the secondary authen-
    tication field in the OSPF header. The authentication key can be config-
    ured on a per-interface basis. It is specified by one to eight decimal
    digits separated by	periods, a one-to-eight	byte hexadecimal string	pre-
    ceded by 0x, or a one-to-eight character string in double quotes. See the
    "Authentication" section for more information.

    Point-to-point interfaces also support the following parameter:

  nomulticast
    By default,	OSPF packets to	neighbors on point-to-point interfaces are
    sent via the IP multicast mechanism.  Some implementations of IP multi-
    casting for	UNIX, however, have a bug that precludes the use of IP multi-
    casting on these interfaces.  The gated daemon detects this	condition and
    falls 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 can be specified to force
    the	use of unicast OSPF packets.  You can also use this option to elim-
    inate warnings when	gated detects the previously described bug.


  OSPF Tracing options


  In addition to the following OSPF specific trace flags, OSPF supports	the
  state	that traces interface and neighbor state machine transitions.

  lsabuild
      Creates the Link State Advertisement

  lsatransmit or (lsatx)
      Traces the link state packets transmitted

  lsareceive or	(lsarx)
      Traces the link state packets received

  spf Traces the Shortest Path First (SPF) calculations

  debug
      Traces OSPF at the debugging level of detail The following packet	trac-
      ing options, which can be	modified with detail, send, and	recv, are
      supported:

  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 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	data-
      bases.

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 sys-
  tems.	 Unlike	interior protocols, EGP	propagates only	reachability indica-
  tions, not true metrics.  EGP	updates	contain	metrics, called	distances,
  that range from 0 to 255. The	gated daemon compares EGP distances learned
  from the same	AS.

  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	mes-
  sages	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 neighbor's routes from its database.

  EGP Syntax



  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
	      [preference preference]
	      [preference2 preference]
	      [metricout metric]
	      [nogendefault]
	      [importdefault]
	      [exportdefault]
	      [gateway gateway]
	      [lcladdr local_address]
	      [sourcenet network]
	      [minhello	| p1 time]
	      [minpoll | p2 time]
	      [ttl ttl]
	      [traceoptions trace_options]
	      ;
      }	;
  } ] ;

  preference preference
      Sets the preference for routes learned from RIP.	The default prefer-
      ence is 200.  This preference can	be overridden by a preference speci-
      fied on the group	or neighbor statements or by import policy.

  defaultmetric	metric ;
      Defines the metric used when advertising routes via EGP.	If not speci-
      fied, the	default	value is 255, which some systems can consider
      unreachable.  This choice	of values requires you to explicitly specify
      a	metric when exporting routes to	EGP neighbors.	This metric can	be
      overridden by a metric specified on the neighbor or group	statements or
      in export	policy.

  packetsize maxpacketsize
      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 is incomplete and is	discarded.  The	length of this packet
      is noted and the expected	size is	increased to be	able to	receive	a
      packet of	this size.  Specifying the parameter here prevents 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 can be overridden on	a
      group or neighbor	basis.	(See the Trace Options Statement section in
      gated.conf(4) and	the EGP-specific tracing options that follow.)

  group
      EGP neighbors must be specified as members of a group.  A	group is
      usually used to group all	neighbors in one autonomous system.  Parame-
      ters specified on	the group clause apply to all of the subsidiary
      neighbors	unless explicitly overridden on	a neighbor clause.  Any
      number of	group clauses can specify any number of	neighbor clauses.

      Any parameters from the neighbor subclause can be	specified on the
      group clause to provide defaults for the whole group (which can 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 is	learned	dynamically.

      localas
	Identifies the autonomous system that gated is representing to the
	group.	The default is that which has been set globally	in the auto-
	nomoussystem 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.
	The gated daemon attempts to acquire the first maxup neighbors in the
	order listed.  If one of the first neighbors is	not available, it
	acquires one farther down the list.  If	after start-up gated does
	manage to acquire the more desirable neighbor, it drops	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 neigh-
      bor.  The	following parameters are optional:

      preference preference
	Specifies the preference used for routes learned from these neigh-
	bors.  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 can be explicitly
	overriden by import policy.

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

      metricout	metric
	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 generated	only
	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 con-
	tained 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 rarely used.

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

      sourcenet	network
	Specifies the network queried in the EGP Poll packets.	By default
	this is	the network shared with	neighbors address specified.  If
	there is no network shared with	the neighbor, specify one of the net-
	works to which the neighbor is attached.  You can also use this
	parameter to specify a network shared with the neighbor	other than
	the one	on which the EGP packets are sent.  This parameter is nor-
	mally 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 neigh-
	bor a better chance to respond.	 The minhello parameter	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 neigh-
	bor is declared	down and all routes learned from that neighbor are
	removed	from the routing database.  A longer polling interval sup-
	ports a	more stable routing database, but is not as responsive to
	routing	changes.  The minpoll parameter	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 the
	Trace Options Statement	section	in gated.conf(4) and the EGP tracing
	options	that follow.)

  EGP Tracing options


  The state and	policy options work with EGP.  The following packet tracing
  options, which can be	modified with detail, send, and	recv, are supported
  for the EGP protocol:

  packets
      Traces all EGP packets

  hello
      Traces EGP HELLO/I-HEARD-U packets, which	are used to determine neigh-
      bor reachability.

  acquire
      Traces EGP ACQUIRE/CEASE packets,	which are used to initiate and ter-
      minate EGP sessions.

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

The BGP	Protocol Statement

  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 can
  also be used to distinguish between groups of	routes to determine adminis-
  trative preferences, allowing	greater	flexibility in determining route
  preference to	achieve	a variety of administrative ends.

  BGP supports two basic types of sessions between neighbours, 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 neighbour
  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 neighbour received the route from an external peer.
  Routes with no AS numbers in the path	can be legitimately received from
  internal neighbours; these indicate that the received	route should be	con-
  sidered internal to your own AS.

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

  External BGP sessions	may or may not include a single	metric,	which BGP
  calls	the Multi-Exit Discriminator (MED), 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 preferred.	 Currently this	metric is only used to break ties
  between routes with equal preference from the	same neighbour 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 ver-
  sion 4 sessions can 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 that
  is specified.

  BGP collapses	routes with similar path attributes into a single update for
  advertisement.  Routes that are received in a	single update are readver-
  tised	in a single update.  The churn caused by the loss of a neighbor	is
  minimized and	the initial advertisement sent during peer establishment is
  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 might cause
  other	protocols to be	blocked	for prolonged intervals	by a busy peer con-
  nection.

  All unreachable messages are collected into a	single message and sent	prior
  to reachable routes during a flash update.  For these	unreachable announce-
  ments, 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	con-
  nections, 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	that are host
  addresses on that subnet (though this	constraint can be relaxed by confi-
  guration for testing).  For groups of	internal peers,	however, you can
  select one of	the following group types:

  internal
    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 adver-
    tisements can be used directly for forwarding.

  routing
    Type routing groups	determine the immediate	next hops for routes by	using
    the	next hop received with a route from a peer as a	forwarding address,
    and	using this to look up an immediate next	hop in an IGP's	routes.	 Such
    groups support distant peers, but need to be informed of the IGP whose
    routes they	are using to determine immediate next hops.

  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 minim-
  izes the computational load of running large numbers of peers	in these
  types	of groups.  BGP	allows unconfigured peers to connect if	an appropri-
  ate group has	been configured	with an	allow clause.

  BGP Syntax


  At the top of	your configuration file, you must specify the AS and routerid
  in order for BGP to operate.

  bgp yes | no | on | off
  [ {
     preference	preference ;
     defaultmetric metric ;
     traceoptions trace_options	;
     [clusterid	host ; ]
     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
	    [authcheck]
	    [gateway gateway]
	    [holdtime time]
	    [ignorefirstashop]
	    [keep [all | none]]
	    [keepalivesalways]
	    [lcladdr local_address]
	    [logupdown]
	    [med]
	    [metricout metric]
	    [nexthopself]
	    [noaggregatorid]
	    [nogendefault]
	    [nov4asloop]
	    [passive]
	    [preference	preference]
	    [preference2 preference]
	    [recvbuffer	number]
	    [sendbuffer	number]
	    [showwarnings]
	    [traceoptions trace_options]
	    [ttl ttl]
	    [v3asloopokay]
	    [version number]
	    ;
     } ;
  } ] ;
  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 to not send a metric.

  The following	options	are supported:

  preference preference
      Sets the preference for routes learned from RIP.	The default prefer-
      ence is 170.  This preference can	be overridden by a preference speci-
      fied on the group	or peer	statements or by import	policy.

  defaultmetric	metric
      Defines the metric used when advertising routes via BGP.	If not speci-
      fied, no metric is propagated.  This metric can be overridden by a
      metric specified on the neighbor or group	statements or in export	pol-
      icy.

  traceoptions trace_options
      Specifies	the tracing options for	BGP.  By default, these	are inherited
      from the global trace options. These values can be overridden on a
      group or neighbor	basis. (See the	Trace Options Statement	section	in
      gated.conf(4) and	the BGP	tracing	options	that follow.)

  clusterid host
      Specifies	the route reflection cluster ID	for BGP. The cluster ID
      defaults to be the same as the router ID.	If a router is to be a route
      reflector, you should select and configure a single cluster ID on	all
      route reflectors in the cluster. Use the following guidelines in choos-
      ing a cluster ID:

	+  IDs of clusters within an AS	must be	unique within that AS

	+  The cluster ID must not be 0.0.0.0.
  Choosing the cluster ID to be	the router ID of one router in the cluster
  will always fulfill these criteria. If there is only one route reflector in
  the cluster, the clusterid setting may be omitted because the	default	will
  suffice.

  BGP Groups


  BGP peers are	grouped	by type	and the	autonomous system of the peers.	 Any
  number of groups can be specified, but each must have	a unique combination
  of type and peer autonomous system. The following four group types are sup-
  ported:

  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 machine's local interfaces.
      By default, no metric is included	in external advertisements, and	the
      next hop is computed with	respect	to the shared interface.

  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 peers 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 can
      be applied to group advertisements.  Routes received from	external BGP
      or EGP peers are by default readvertised with the	received metric.

      The lcladdr, outdelay, and metricout options must	be set in the group
      clause, not on a per-peer	basis, for the group types internal and	rout-
      ing. If these options are	set on the peer	subclause, they	must equal
      the values set on	the corresponding group	clause.

  group	type igp peeras	autonomous_system proto	proto
      An internal group	to which the router is not connected.  The proto key-
      word names the interior protocol to be used to resolve BGP route next
      hops, and	might be the name of any IGP in	the configuration, including
      static.

  group	type routing peeras autonomous_system proto proto
      An internal group	that uses the routes of	an interior protocol to
      resolve forwarding addresses.  A type routing group propagates external
      routes between routers that are not directly connected, and computes
      immediate	next hops for these routes by using the	BGP next hop that
      arrived with the route as	a forwarding address to	be resolved via	an
      internal protocol's routing information.	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 can be the	name of	any IGP	in the configuration.  By
      default, the next	hop in BGP routes advertised to	type routing peers is
      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 can be used
      instead.

      The lcladdr, outdelay, and metricout options must	be set in the group
      clause, not on a per-peer	basis, for the group types internal and	rout-
      ing. If these options are	set on the peer	subclause, they	must equal
      the values set on	the corresponding group	clause.

  group	type test peeras autonomous_system
      An extension to external BGP that	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 local	machine's current
      next hop.	 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- and BGP-derived routes
      are forwarded in the advertisement; otherwise no metric is included.

  BGP Group parameters

  The BGP statement has	group clauses and peer subclauses.  Any	number of
  peer subclauses can 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.  Most	parameters from	the peer subclause
  can be specified on the group	clause to provide defaults for the whole
  group, which can be overridden for individual	peers.

  The following	optional parameters apply to both groups and peers:

  ascount count
    [External groups only] Describes the number	of times that this router
    will insert	its own	AS number when it sends	the AS path to an external
    peer.  The default is 1. Higher values are typically used to bias
    upstream peers' route selection. (Most routers will	prefer to use routes
    with shorter AS Paths. Using ascount, the AS Path this router sends	can
    be artificially lengthened.)

    Note: ascount supersedes the nov4asloop option. Regardless of whether
    nov4asloop is set, this router will	send multiple copies of	its own	AS if
    the	ascount	option is set to something greater than	1.  Also, if the
    value of ascount is	changed	and gated is reconfigured, routes will not be
    sent to reflect the	new setting. If	you want these routes to be sent,
    restart the	peer session by	commenting out the group ascount, reconfigur-
    ing, and then uncommenting and reconfiguring again,	or by restarting
    gated.

  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 usually not needed.

  holdtime time
    Specifies the BGP holdtime value, in seconds, to use when negotiating the
    connection with this peer.	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, the BGP connection is
    closed. The	value must be either 0 (no keepalives will be sent) or at
    least 3.

  ignorefirstashop
    Some routers, known	as route servers, are capable of propagating routes
    without appending their own	AS to the AS Path.  By default,	gated drops
    such routes.  Specifying ignorefirstashop on the group clause allows
    gated to keep these	routes.	 Use this option only if you are sure that
    the	peers in this group are	route servers and not normal routers.

  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.

  keep (all | none)
    The	all parameter retains routes learned from a peer even if the routes'
    AS paths contain one of our	exported AS numbers. The none parameter	(the
    default) causes gated to disregard routes containing the router's own AS
    numbers.

  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 that is shared with the peer or with the peer's gateway when
    the	gateway	parameter is used.  A session with an external peer is opened
    only 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 is	maintained when	any interface
    with the specified local address is	operating.  In either case, incoming
    connections	are recognized as matching a configured	peer if	they are
    addressed to the configured	local address.

  localas autonomous_system
    Identifies the autonomous system that gated	is representing	to this	group
    of peers.  The default is that which has been set globally in the auto-
    nomoussystem statement.

  logupdown
    [Routing groups only] Causes messages to be	logged via the syslog mechan-
    ism	whenever a BGP group enters or leaves the ESTABLISHED state.

  med
    By default,	any metric (Multi Exit Discriminator) received on a BGP	con-
    nection is ignored.	 If MEDs are used in routing computations, the med
    option must	be specified on	the group.  By default,	MEDs are not sent on
    external connections.  To send MEDs, use the metric	option of the export
    statement or the metricout option to the peer or group parameter.

  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	pol-
    icy.

  nexthopself
    [Internal and external groups only]	Sets this group's next hops to the
    router's own address even if it would normally be possible to send a
    third-party	next hop.  Using this option, may cause	inefficient routes to
    be followed, but it	may be needed in some cases to deal with broken
    bridged interconnect media (in cases where the routers on the shared
    medium do not really have full connectivity	to each	other) or when other
    situations cause broken links.

  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.

  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.

  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 that would incorrectly	forward	the routes on to version 3 neigh-
    bours.

  passive
    Specifies that active OPENs	to this	peer should not	be attempted. The
    gated daemon should	wait for the peer to issue an open.  By	default, all
    explicitly configured peers	are active; they periodically send OPEN	mes-
    sages until	the peer responds.

  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 peers, over	oth-
    ers.  This preference can be explicitly overriden by import	policy.

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

  recvbuffer buffer_size

  sendbuffer buffer_size
    Control the	amount of receive and send buffering required of the kernel.
    The	maximum	supported is 65535 bytes, although many	kernels	have a lower
    limit.  By default,	gated configures the maximum supported.	These parame-
    ters are not needed	on normally functioning	systems.

  showwarnings
    Forces gated to issue warning messages when	receiving questionable BGP
    updates, such as duplicate routes or deletions of non-existing routes.
    Typically these events are silently	ignored.

  traceoptions trace_options
    [Routing groups only] Specifies the	tracing	options	for this BGP neigh-
    bor.  By default these are inherited from group or BGP global trace
    options.  (See the Trace Options Statement section in gated.conf(4)	and
    the	BGP specific tracing options that follow.)

  ttl ttl
    [Routing groups only] By default, gated sets the IP	TTL for	local peers
    to one and the TTL for non-local peers to 255.  This option	is provided
    for	communicating 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.

  v3asloopokay
    By default,	gated does not advertise routes	whose AS path is looped	(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.

  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 nego-
    tiation is attempted.  If it is specified, only the	specified version is
    offered during negotiation.	 Currently supported version are 2, 3, and 4.

  The following	parameters apply to groups only:

  aspath-opt
    Originates the specified AS	path attributes.  If the attributes are
    already present, they may be augmented (as with communities) or possibly
    replaced (with other attributes that may be	supported in the future).

  indelay time
    Specifies the amount of time a BGP route must be present before it is
    accepted into the gated routing database.  The default value is 0, mean-
    ing	that this feature is disabled.

  interface interface_list
    [Routing groups only] Provides a list of interfaces	whose routes are car-
    ried via the IGP for which third-party next	hops may be used.

  outdelay time
    Specifies the amount of time a route must be present in the	gated routing
    database before it is exported to BGP.  The	default	value is 0, meaning
    that this feature is disabled.

  reflector-client [no-client-reflect]
    [Internal, IGP, and	routing	groups only] Specifies that gated will act as
    a route reflector for this group.  The no-client-reflect option specifies
    that gated will not	act as an intra-group reflector.

  setpref metric
    [IGP and routing groups only] Allows BGP's Local_Pref attribute to be
    used to set	the gated preference on	reception, and allows gated prefer-
    ence to set	the Local_Pref on transmission.	The setpref metric works as a
    lower limit, below which the imported Local_Pref may not set the gated
    preference.

  Specifying peers

  Within a group, BGP peers can	be configured in either	of the following
  ways:	explicitly with	a peer statement or implicitly with the	allow state-
  ment.	 A description of each is as follows:

  peer host
      Configures an individual peer.  Each peer	inherits all parameters
      specified	on a group as defaults.	 Those default can be overridden by
      parameters explicitly specified on the peer subclause.

  allow
      Allows for peer connections from any addresses in	the specified range
      of network and mask pairs.  All parameters for these peers must be con-
      figured on the group clause.  The	internal peer structures are created
      when an incoming open request is received	and destroyed when the con-
      nection is broken.  For more detail on specifying	the network/mask
      pairs, see the section on	Route Filtering	in gated.control(4).

  Within each group clause, individual peers can be specified or a group of
  potential peers can be specified using allow.	 The allow statement is	used
  to specify a set of address masks.  If gated receives	a BGP connection
  request from any address in the set specified, it accepts it and sets	up a
  peer relationship.

  BGP Peer parameters

  The BGP peer subclause allows	the following optional parameters, which can
  also be specified on the group clause:

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

  BGP Tracing options


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

  The following	packet tracing options,	which can be modified with detail,
  send,	and recv, are supported:

  packets
      Traces all BGP packets.

  open
      Traces BGP OPEN packets, which are used to establish a peer relation-
      ship.

  update
      Traces BGP UPDATE	packets, which are used	to pass	network	reachability
      information.

  keepalive
      Traces BGP KEEPALIVE packets, which are used to verify peer reachabil-
      ity.

  all traces additions,	changes, and deletions to the gated routing table.

The ICMP Statement

  On systems without the BSD routing socket, gated listens to ICMP messages
  received by the system.  Currently, gated processes only ICMP	redirect
  packets, but might process additional	ICMP messages, such as router
  discovery messages, in the future.  Processing of ICMP redirect messages is
  handled by the redirect statement.

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

  ICMP Syntax


  icmp {
      traceoptions trace_options ;
  }

  traceoptions trace_options ;
      Specifies	the tracing options for	ICMP. (See the Trace Options State-
      ment section in gated.conf(4) and	the ICMP tracing options that fol-
      low.)

  ICMP Tracing options


  The following	packet tracing options,	which can be modified with detail and
  recv,	are supported:

  packets
      Traces all ICMP packets received.

  redirect
      Traces only ICMP REDIRECT	packets	received.

  routerdiscovery
      Traces only ICMP ROUTER DISCOVERY	packets	received.

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

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




Redirect Statement

  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 verifies whether
  the kernel forwarding	table has been modified.  On systems where ICMP	mes-
  sages	are monitored, this is accomplished by guessing	what the kernel	would
  have done with the redirect.	On systems with	the routing socket, the	ker-
  nel provides an 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
  changed, the necessary requests to the kernel	are made to restore the
  correct state.

  Note:	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 kernel's state.  Because of
  the mechanism's 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	inte-
  rior gateway protocol	(RIP or	OSPF).	It is impossible to enable redirects
  once they have been automatically disabled.  Listening to RIP	in nobroad-
  cast 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:	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.

  Redirect Syntax


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

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

  interface interface_list
      The interface statement allows the enabling and disabling	of redirects
      on an interface-by-interface basis.  See the Interface List section in
      gated.conf(4) for	the description	of the interface_list.	The following
      parameters are supported:

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

      redirects
	This is	the default. This argument might be necessary when
	noredirects is used on a wild card interface descriptor.

  trustedgateways gateway_list
      Defines the list of gateways from	which redirects	are 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.

  Redirect 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 two portions: the server portion, which runs on
  routers, and the client portion, which runs on hosts.	 The gated daemon
  treats these as two separate protocols, only one of which can	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 might	send a Router Solici-
  tation to which the router responds with a unicast Router Advertisement
  (unless a multicast or broadcast advertisement is due	momentarily).

  Each Router Advertisement contains a Advertisement Lifetime field indicat-
  ing for how long the advertised addresses are	valid.	This lifetime is con-
  figured such that another Router Advertisement is sent before	the lifetime
  has expired.	A lifetime of zero indicates that one or more addresses	are
  no longer valid.

  On systems supporting	IP multicasting, the Router Advertisements are by
  default sent to the all-hosts	multicast address 224.0.0.1.  However, the
  use of broadcast can be specified.  When Router Advertisements are 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.



  Router Discovery Server Syntax


  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 Options
      Statement	section	in gated.conf(4) and the Router	Discovery specific
      tracing options.)

  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.

      The following interface parameters are supported:

      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 these 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) are included in Router
	Advertisements.	 This is the default.

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

      broadcast
	Specifies that the given address(es) are included in a broadcast
	Router Advertisement because this system does not support IP multi-
	casting, or some hosts on attached network do not support IP
	multicasting.  It is possible to mix addresses on a physical inter-
	face 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) are included in a multicast
	Router Advertisement.  If the system does not support IP multicast-
	ing, the address(es) are not included.	By default, if the system and
	given interface	support	IP multicasting, the address(es) are included
	in a multicast Router Advertisement.  If the interface does not	sup-
	port IP	multicasting, the address(es) are 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: hex 80000000	can only be specified as ineligible.
	The default is 0.

      ineligible
	Specifies that the given address(es) are 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 avail-
	able.

  The Router Discovery Client


  A host listens for Router Advertisements via the all-hosts multicast
  address (224.0.0.2), if IP multicasting is available and enabled, or on the
  interface's broadcast	address.  When starting	up, or when reconfigured, a
  host can send	a few Router Solicitations to the all-routers multicast
  address, 224.0.0.2, or the interface's broadcast address.

  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 is	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 are	deleted.  The same happens when	a Router Advertisement is not
  received to refresh these routes before the lifetime expires.

  Router Discovery Client Syntax


  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 the	Trace Options State-
      ment section in gated.conf(4) and	the OSPF-specific tracing options
      that follow.)

  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 speci-
	fied interface(s).

      broadcast
	Specifies that Router Solicitations should be broadcast	on the speci-
	fied 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 speci-
	fied interface(s).  If IP multicast is not available on	this host and
	interface, no solicitation is 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 are sent	on this	interface,
	even though Router Discovery is	performed.

      solicit
	Specifies that initial Router Solicitations are	sent on	this inter-
	face.  This is the default.

  Router Discovery Tracing options


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

  state
      Traces 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 SNMP Statement

  The Simple Network Management	Protocol (SNMP)	is a not a routing protocol
  but a	network	management protocol.  The snmp statement controls whether
  gated	tries to contact the SNMP Multiplexing daemon to register supported
  variables.  The SNMP daemon (usually smuxd) must be run independently.  The
  snmp statement only controls whether gated keeps the management software
  apprised of its status.

  The gated daemon communicates	with the SNMP daemon via the SMUX protocol
  that is described in RFC 1227.


  SNMP Syntax


  snmp yes | no	| on | off
  [{
      port port	;
      debug ;
      traceoptions traceoptions	;
  }] ;

  Reporting is enabled by specifying yes or on and disabled with no or off.
  The default is on.

  port port
      Specifies	that gated try to contact the SMUX daemon on a port other
      than the default port.  By default, the SMUX daemon listens for
      requests on port 199.

  debug
      Enables debugging	of the ISODE SMUX code.	 The default is	debugging
      disabled.

  traceoptions trace_options
      Specifies	the tracing options for	SMUX. (See the Trace Options State-
      ment section in gated.conf(4) and	the SMUX tracing options that fol-
      low.)

  SNMP Tracing options


  There	are no SNMP-specific trace options.  SNMP requests received via	the
  SMUX protocol	from the SNMP daemon are not handles quite like	packets	and
  are currently	handled	differently. The detail, send, and recv	options	are
  not supported.

  receive
      SNMP requests received from the SMUX daemon and the associated
      responses.

  register
      Protocol requests	to register variables.

  resolve
      Protocol requests	to resolve variable names.

  trap
      SNMP trap	requests from protocols.

The Kernel Statement

  While	the kernel interface is	not technically	a routing protocol, it has
  many characteristics of one, and gated treats	it like	a routing protocol.
  The routes gated chooses to install in the kernel forwarding table are
  those	that are 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 significant amount of time.  This does	not
  present a problem for	older routing protocols	(for example, RIP and EGP),
  which	are not	particularly time critical and do not easily handle very
  large	numbers	of routes. The newer routing protocols (for example, OSPF and
  BGP) have stricter timing requirements and are often used to process many
  more routes.	The speed of the kernel	interface becomes critical when	these
  protocols are	used.

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

  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 are 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
  reinstall 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 for-
  warding table	(referred to in	ISO 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 (referred to	in ISO 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 is 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() inter-
  face and the routing socket interface.  Their	various	characteristics	are
  described as follows:

  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 allows
  gated	to update the kernel forwarding	table only.  It	has the	following
  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 for-
	    warding table, but determined when a packet	is forwarded by
	    searching for interfaces on	the same network.

  One way interface
	    The	gated daemon is	able to	update the kernel forwarding table,
	    but	it is not aware	of other modifications of the forwarding
	    table.  The	gated daemon is	able to	listen to ICMP messages	and
	    determine how the kernel has updated the forwarding	table in
	    response to	ICMP redirects.

  Blind	updates
	    The	gated daemon 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 the following	advantages
  over the ioctl() interface:

  Variable subnet masks
      The network mask is passed to the	kernel explicitly.  This allows	dif-
      ferent 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 pro-
      cessed 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 synchronized with the rout-
      ing 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 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	can be added by	adding new
      message types.

  Reading the Forwarding Table


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

  The following	methods	are used for reading the forwarding table from the
  kernel:


  Reading forwarding table via kmem

  On Tru64 UNIX	systems, gated reads the forwarding table via kmem at boot
  time.	 After the system is booted, gated uses	the Routing Socket interface
  to receive updates from the kernel.

  Reading the forwarding table via OS specific methods

  Some operating systems define	their own method of reading the	kernel for-
  warding table.

  Reading the interface	list


  The kernel support subsystem of gated	is responsible for reading the status
  of the kernel's physical and protocol	interfaces periodically.  The gated
  daemon detects changes in the	interface list and notifies the	protocols so
  they can start or stop instances or peers. The interface list	is read	in
  the following	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 returned 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 broad-
  cast capable interfaces).

  The gated daemon rereads this	list every 15 second looking for changes.
  When the routing socket is in	use, the daemon	also rereads it	whenever a
  message is received indicating a change in routing configuration.  Receipt
  of a SIGUSR2 signal also causes gated	to reread the list.  This interval
  can 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 that 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 used, gated rereads the interface	list only once a
  minute.  It also rereads the list on routing table change indications	and
  when a SIGUSR2 is received.  This interval can be explicitly configured in
  the interface	configuration.

  Reading interface physical addresses

  Later	versions 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 phy-
  sical	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, system specific interfaces are used to learn	this informa-
  tion.

  The interface	physical addresses are useful for IS-IS.  For IP protocols,
  they are not currently used, but might 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 genera-
  tion,	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 kernels support the following special route flags:

  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 valid only 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 valid
      only on routes pointing at the loopback interface.

  RTF_STATIC
      When gated starts, it reads all the routes currently in the kernel for-
      warding 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	are
      not 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 gated that	said route was added by	the
      system administrator and should be retained.

  Kernel Syntax


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

  options option_list
      Configures kernel	options.  The following	options	are valid:

      nochange
	On systems supporting the routing socket, this insures that changes
	operations are not performed, only deletes and adds.  This is useful
	on early versions of the routing socket	code where the change opera-
	tion 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 notices which routes are in the kernel forwarding	table and
	does not add them back.

  routes number
      On some systems, kernel memory is	scarce.	 This parameter	limits the
      maximum number of	routes gated installs in the kernel.  Normally,	gated
      adds, changes, or	deletes	routes in interface, internal, or external
      order; that is, it queues	interface routes first,	followed by internal
      routes, followed by external routes, and processes the queue from	the
      beginning.

      If 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, adding routes in interface/internal/external
      order until it hits the limit again.  This tends to favor	internal
      routes over external routes.  The	default	is to not 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 can be processed
      during one flash update.	The flash command allows tuning	of the fol-
      lowing parameters:

      limit number
	Specifies the maximum number of	routes that can	be processed during
	one flash update.  The default is 20.  A value of -1 causes all	pend-
	ing route changes of the specified type	to be processed	during the
	flash update.

      type interface | interior	| all
	Specifies the type of routes that are processed	during a flash
	update.	 Interior specifies that interior routes (See the definition
	of interior gateway protocols) are also	installed.  The	all parameter
	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 is	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 back-
      ground, 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 parame-
      ters:

      limit number
	Specifies the number of	routes that can	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 pro-
	cess kernel updates at the same	priority as flash updates, specify
	flash; to process them at a lower priority, use	lower.

  Kernel Interface Tracing options


  While	the kernel interface is	not 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	com-
      mand line	as the first interface list scan is performed before the con-
      figuration file is parsed.

  The following	tracing	options	can only be specified in the configuration
  file.	 They are not valid from the command line.

  remnants
      Traces routes read from the kernel when gated starts.

  request
      Traces requests by gated to Add/Delete/Change routes in the kernel for-
      warding table.

  The following	general	option and packet-tracing options only apply on	sys-
  tems that use	the routing socket to exchange routing information with	the
  kernel.  They	do not apply on	systems	that use the old BSD4.3	ioctl()
  interface to the kernel.

  info
      Informational messages received from the routing socket, such as TCP
      loss, routing lookup failure, and	route resolution requests.  The	gated
      daemon does not currently	do processing on these messages, just logs
      the information if requested.

  The following	packet tracing options,	which can be modified with detail,
  send,	and recv, are supported:

  routes
      Routes exchanged with the	kernel,	including Add/Delete/Change messages
      and Add/Delete/Change messages received from other processes.

  redirect
      Redirect messages	received from the kernel.

  interface
      Interface	status messages	received from the kernel.  These are only
      supported	on systems with	networking code	derived	from BSD 4.4.

  other
      Other messages received from the kernel, including those mentioned in
      the info type above.




  Static Routes	Statements


  The 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 can	be specified, each
  containing any number	of static route	definitions.  These routes can be
  overridden by	routes with better preference values.

  Static Syntax


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

  host host gateway gateway_list

  (network [(mask mask)	| (masklen number)])

  default gateway gateway_list
      This is the most general form of the static statement.  It defines a
      static route through one or more gateways.  Static routes	are installed
      when one or more of the 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).

      The following parameters for static routes are supported:

      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 inter-
	face list specification	for the	description of the interface_list.

      preference preference
	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
	Prevents specific static routes	from being removed.  Normally, gated
	removes	all routes except interface routes from	the kernel forwarding
	table during a graceful	shutdown.  This	is useful to insure that some
	routing	is available when gated	is not running.

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

      blackhole
	A blackhole route is the same as a reject route	except that unreach-
	able 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 is not installed in the
	kernel forwarding table	when it	is active, but it will still be	eli-
	gible to be exported to	other protocols.

  (network [(mask mask)	| (masklen number)])

  interface interface
      This form	defines	a static interface route that is used for primitive
      support of multiple network addresses on one interface.  The prefer-
      ence, retain, reject, blackhole, and noinstall options are the same as
      described	previously.

RELATED	INFORMATION

  Daemons: gated(8).

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

  Networking: gated_intro(7).

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

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

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

  RFC 1058, Routing Information	Protocol, C. Hedrick.

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

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

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

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

  RFC 1245, OSPF Protocol Analysis, J. Moy.

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

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

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

  RFC 1265, BGP	Protocol Analysis, Y. Rekhter.

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

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

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

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

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

  RFC 1370, Internet Architecture Board	Applicability Statement	for OSPF

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

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

  RFC 1403, BGP	OSPF Interaction, K. Varadhan.

  RFC 1583, OSPF Version 2, J. Moy.