gated.proto man page on OSF1

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
OSF1 logo
[printable version]

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
       distribute routing information among the systems on a network.  Routing
       protocols  are divided into two general groups: interior (intra-domain)
       and exterior (inter-domain) protocols. The gated software combines man‐
       agement	of the interior and exterior routing protocols in one software
       daemon.

   Intra-Domain Routing Protocols
       Intra-domain (interior) protocols are  used  to	exchange  reachability
       information  within an autonomous system (AS).  They are referred to as
       a class by the acronym IGP. The following interior protocols  are  sup‐
       ported:	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 repre‐
       senting the number of gateways through which data must  pass  to	 reach
       its  destination.  The longest path that RIP accepts is 15 hops. If the
       metric is greater than 15, a destination is considered unreachable  and
       gated  discards	the route.  RIP assumes the best route is the one that
       uses the fewest gateways (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.	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 au‐
       tonomous systems.  Exterior protocols are only required when an autono‐
       mous  system  must exchange routing information with another autonomous
       system.	Routers within an autonomous system run	 an  interior  routing
       protocol like RIP.  Only those gateways that connect an autonomous sys‐
       tem to another autonomous system need to run an exterior routing proto‐
       col.  The following exterior protocols are supported by gated: 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 architecture, EGP, an exte‐
       rior routing protocol that assumes  a  hierarchical  structure,	became
       less effective.

	      The  EGP	protocol  is described in RFC 827 and RFC 904.	Border
	      Gateway Protocol (BGP) is replacing EGP as the exterior protocol
	      of  choice.   BGP exchanges reachability information between au‐
	      tonomous systems, but provides more capabilities than EGP.   BGP
	      uses  path  attributes  to  provide  more information about each
	      route as an aid in selecting the best  route.   Path  attributes
	      can  include,  for  example, administrative preferences based on
	      political, organizational, or security  (policy)	considerations
	      in  the  routing decision.  BGP supports nonhierarchical topolo‐
	      gies and can be used to implement a network structure of equiva‐
	      lent 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 Confedera‐
	      tions, and RFC 1403 for BGP - OSPF interaction.  A useful appli‐
	      cation  document	is RFC 1998, "An Application of the BGP Commu‐
	      nity Attribute in Multi-home Routing".

   Other Routing Protocols
       The following routing protocol is also supported: The Router  Discovery
       protocol	 is  used  to inform hosts of the availability of hosts it can
       send packets to and is  used  to	 supplement  a	statically  configured
       default	router.	 This is the preferred protocol for hosts to run, they
       are discouraged from wiretapping routing protocols.

	      Router Discovery is described in RFC 1256.

Routing Information Protocol (RIP)
       One of the most widely used interior gateway protocols is  the  Routing
       Information  Protocol  (RIP).   RIP is an implementation of a distance-
       vector, or Bellman-Ford routing protocol for local networks.  It	 clas‐
       sifies  routers	as active and passive (silent).	 Active routers adver‐
       tise 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 inter‐
       vals.  Each update contains paired values where each pair  consists  of
       an  IP  network	address	 and an integer distance to that network.  RIP
       uses a hop count metric to measure the distance to a  destination.   In
       the  RIP	 metric,  a router advertises directly connected networks at a
       metric of 1.  Networks 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 compensate for differences in technology
       many routers advertise artificially high hop counts for slow links.

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

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

       RIP version 2 (more commonly known as RIP II) 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 misinter‐
       preted, RIP II can only use non-compatible features  when  its  packets
       are multicast.  On interfaces that are not capable of IP multicast, RIP
       I-compatible packets are used that do not contain potentially confusing
       information.

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

	      RIP I routers 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  pro‐
	      vided  in	 RIP  I-compatible RIP II packets.  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  differ‐
	      ent  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 pack‐
	      ets, their calculation of the network mask will  quite  possibly
	      be wrong.	 For this reason, RIP I-compatible RIP II packets must
	      not contain networks that would be misinterpreted.   These  net‐
	      work  must  only	be  provided in native RIP II packets that are
	      multicast.

	      RIP-I derives the network mask of received  networks  and	 hosts
	      from  the network mask of the interface the packet via which the
	      packet was received.  If a received network or host  is  on  the
	      same natural network as the interface over which it was received
	      and that network is subnetted (the specified mask is  more  spe‐
	      cific  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.	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 authen‐
	      tication key itself,  instead  it	 contains  a  crypto-checksum,
	      called the digest.  The receiving router will perform a calcula‐
	      tion using the correct authentication key and discard the packet
	      if the digest does not match.  In addition, a sequence number is
	      maintained to prevent the replay of older packets.  This	method
	      provides	a much stronger assurance that routing data originated
	      from a router with a valid authentication key.

	      Two authentication methods can be specified per interface. Pack‐
	      ets are always sent using the primary method, but received pack‐
	      ets 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: Specifies that RIP pack‐
       ets 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 sin‐
       gle network twice.  Specifies that RIP packets  are  not	 broadcast  on
       attached interfaces, even if there are more than one.  If a sourcegate‐
       ways clause is present, routes are unicast directly  to	that  gateway.
       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.	Sets the preference for routes learned
       from RIP.  The default preference is 100.  This preference can be over‐
       ridden  by a preference specified in import policy.  Defines the metric
       used when advertising routes via RIP that were learned from other  pro‐
       tocols.	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  policy.	Specifies  the
       authentication  required	 of  query  packets that do not originate from
       routers.	 The default is none.  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  subnet,  RIP  updates are sent from first one on which RIP
	      output is configured.

	      The following interface parameters are supported: Specifies that
	      RIP  packets  received  via the specified interface are ignored.
	      The default is to listen to  RIP	packets	 on  all  non-loopback
	      interfaces.  This is the default.	 This argument might be neces‐
	      sary when noripin is used on a wild card	interface  descriptor.
	      Specifies	 that  no RIP packets are sent on the specified inter‐
	      faces.  The default is to send RIP on  all  broadcast  and  non-
	      broadcast interfaces when in broadcast mode.  The sending of RIP
	      on point-to-point interfaces must be manually configured.	  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.	 Spec‐
	      ifies 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 inter‐
	      face(s) less than RIP routes from other  interfaces.   Specifies
	      the RIP metric to be added to routes that are send via the spec‐
	      ified interface(s).  The default is zero.	 This option  is  used
	      to  make	other  routers prefer other sources of RIP routes over
	      this router.  Specifies that RIP packets sent via the  specified
	      interface(s) are version 1 packets.  This is the default.	 Spec‐
	      ifies that RIP version 2	packets	 are  sent  on	the  specified
	      interfaces(s).   If  IP  multicast  support is available on this
	      interface, the default is to send full version 2 packets.	 If it
	      is  not  available,  version  1 compatible version 2 packets are
	      sent.  Specifies that RIP version 2 packets should be  multicast
	      on  this	interface.   This  is the default.  Specifies that RIP
	      version 1-compatible version 2 packets should  be	 broadcast  on
	      this  interface, even if IP multicast is available.  Defines the
	      authentication type to use.  It applies only to  RIP  version  2
	      and  is  ignored	for RIP-1 packets.  The default authentication
	      type is none.  If a password is  specified,  the	authentication
	      type defaults to simple.	The password should be a quoted string
	      with between 0 and 16 characters.

	      If secondary is specified, this defines the secondary  authenti‐
	      cation.	If  omitted,  the primary authentication is specified.
	      The default is primary authentication of none and	 no  secondary
	      authentication.	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 information.  But  if  the	trust‐
	      edgateways  clause  is specified, only updates from the gateways
	      in the list are accepted.	 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  spe‐
	      cific  gateways.	 Updates  to  gateways	in  this  list are not
	      affected by noripout on the interface.   Specifies  the  tracing
	      options  for  RIP.   (See the Trace Options Statement 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 met‐
       ric  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: All RIP packets.  RIP information request
       packets, such as REQUEST, POLL  and  POLLENTRY  RIP  RESPONSE  packets,
       which is the type of packet that actually contains routing information.
       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  dis‐
       tributes	 routing  information  between	routers in a single autonomous
       system.	OSPF chooses the least cost path as the best  path.   Suitable
       for  complex  networks  with  a	large number of routers, OSPF provides
       equal cost multipath routing where packets to a single destination  can
       be sent via more than one interface simultaneously.

       In  a  link-state protocol, each router maintains a database describing
       the entire AS topology, which it builds out of the collected link state
       advertisements  of  all routers.	 Each participating router distributes
       its local state (the router's usable interfaces	and  reachable	neigh‐
       bors) throughout the AS by flooding.  Each multiaccess network that has
       at least two attached routers has a designated router and a backup des‐
       ignated	router.	  The designated router floods a link state advertise‐
       ment for the multiaccess network and has	 other	special	 responsibili‐
       ties.   The designated router concept reduces the number of adjacencies
       required on a multiaccess network.

       OSPF allows networks to be grouped  into	 areas.	  Routing  information
       passed  between areas is abstracted, potentially allowing a significant
       reduction in routing  traffic.	OSPF  uses  four  different  types  of
       routes,	listed	in order of preference: intra-area, inter-area, type 1
       external and type  2  external.	 Intra-area  paths  have  destinations
       within  the same area, inter-area paths have destinations in other OSPF
       areas and Autonomous System External (ASE) routes are routes to	desti‐
       nations external to the AS.  Routes imported into OSPF as type 1 routes
       are supposed to be from igps whose external metrics are directly compa‐
       rable  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 internal OSPF cost to  the  AS	Border
       router is used in the routing decision.

       From the topology database, each router constructs a tree of the short‐
       est paths with itself as the root.  This shortest-path tree  gives  the
       route to each destination in the AS.  Externally derived routing infor‐
       mation appears on the tree as  leaves.	The  link-state	 advertisement
       format distinguishes between information acquired from external sources
       and information acquired from internal routers, so there is no  ambigu‐
       ity  about  the	source	or  reliability of routes.  Externally derived
       routing information (for example, routes learned from EGP  or  BGP)  is
       passed transparently through the autonomous system and is kept separate
       from 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
       administrators  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 ser‐
       vice to choose the best route to the destination.

       OSPF intra- and inter-area routes are always imported  into  the	 gated
       routing	database  with a preference of 10.  It would be a violation of
       the protocol if an OSPF router did not participate fully in the	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 contigu‐
       ous and the backbone is no exception.  To permit	 maximum  flexibility,
       OSPF allows the configuration of virtual links enable the backbone area
       to appear contiguous despite the physical reality.

       All routers in an area must agree on that area's parameters.   A	 sepa‐
       rate 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 configura‐
       tion.  Misconfiguration will lead to adjacencies	 not  forming  between
       neighbors, and routing information might not flow, or even loop.

   Authentication
       All OSPF protocol exchanges can be authenticated.  Authentication guar‐
       antees 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 authenti‐
       cation than others. 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 authenti‐
       cation  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 preced‐
	      ing 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 pack‐
	      ets 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 mul‐
	      tiple  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 generat‐
	      ing 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 spec‐
	      ify 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
	      } ;
	   } ; } ] ; Specify the defaults used when importing OSPF  Autonomous
       System External (ASE) routes into the gated routing table and exporting
       routes from the gated routing table into OSPF ASEs.  The preference  is
       used to determine how OSPF routes compete with routes from other proto‐
       cols in the gated routing table.	 The default value is 150.   The  cost
       is  used	 when  exporting a non-OSPF route from the gated routing table
       into OSPF as an ASE.  The default value is 1.  This can	be  explicitly
       overridden  in  export policy.  OSPF ASE routes have a 32-bit tag field
       that is not used by the OSPF protocol, but might be used by export pol‐
       icy  to	filter	routes.	 When OSPF is interacting with an EGP, the tag
       field can be used to propagate AS path information, in which  case  the
       as  keyword  is specified and the tag is limited to 12 bits of informa‐
       tion.  If not specified, the tag is set to zero.	 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.	 Enables an OSPF ASE route to inherit the metric of the exter‐
       nal route when no metric is specified on the export. This option	 main‐
       tains  compatibility  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.  Because
       of the nature of OSPF, the rate at which ASEs are flooded must be  lim‐
       ited.   The  following  two parameters can be used to adjust those rate
       limits: Specifies how often a batch of ASE  link	 state	advertisements
       are  generated  and flooded into OSPF.  The default is once per second.
       Specifies how many ASEs are generated and flooded in each  batch.   The
       default	is  100.   Specifies  the  tracing  options  for  OSPF.	  (See
       gated.conf(4) and the OSPF tracing  options  section.)	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.  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 con‐
       figured, 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 utilize system resources.  Each OSPF router  must  be
       configured  into at least one OSPF area.	 If more than one area is con‐
       figured, at least one must the be backbone.  The backbone can  only  be
       configured  using  the backbone keyword, it cannot be specified as area
       0.  The backbone interface can be a virtuallink.	 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 specified cost.  The networks list
       describes  the  scope of an area.  Intra-area LSAs that fall within the
       specified ranges are not advertised  into  other	 areas	as  inter-area
       routes.	 Instead,  the specified ranges are advertised as summary net‐
       work 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 propa‐
       gated 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.   Specifies
       directly	 attached  hosts  that	should be advertised as reachable from
       this router and the costs they should be	 advertised  with.   Point-to-
       point  interfaces  on  which  it is not desirable to run OSPF should be
       specified here.

	      It is also useful to assign an additional address to  the	 loop‐
	      back  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.	This form of the interface  clause  is
	      used  to configure a broadcast (which requires IP multicast sup‐
	      port) or a point-to-point interface.  See the "Interfaces State‐
	      ment" section in gated.conf(4) for the description of the inter‐
	      face_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 destination.	 The default cost is one, but another non-zero
	      value can be specified.

	      This  form  has  one  unique  parameter: Enables or disables the
	      interface.  See the "Interface Parameters" section for a list of
	      parameters  common  to  all  interface  types.  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-capa‐
	      ble medium that does not support IP multicasting must be config‐
	      ured as a non-broadcast interface.

	      A non-broadcast interface supports any of the standard interface
	      clauses  listed  previously  and the following two that are spe‐
	      cific to non-broadcast interfaces: Before	 adjacency  is	estab‐
	      lished  with  a  neighbor, OSPF packets are sent periodically at
	      the specified poll interval.  By definition, it is not  possible
	      to  send	broadcast packets to discover OSPF neighbors on a non-
	      broadcast, so  all  neighbors  must  be  configured.   The  list
	      includes one or more neighbors and an indication of their eligi‐
	      bility to become a designated router.  See the "Interface Param‐
	      eters"  section for a list of parameters common to all interface
	      types.  Virtual links are used to establish or increase  connec‐
	      tivity of the backbone area.  The neighborid is the router_id of
	      the other end of the virtual link.  The 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	inter‐
       faces:  The number of seconds between link state advertisement retrans‐
       missions for adjacencies belonging to this  interface.	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.  A number between 0
       and 255 specifying the priority for becoming the designated  router  on
       this interface.	When two routers attached to a network both attempt to
       become designated router, the one with the highest  priority  wins.   A
       router whose router priority is set to 0 is ineligible to become desig‐
       nated router.  The length of time, in seconds,  between	Hello  packets
       that  the  router  sends on the interface.  The length of time, in sec‐
       onds, a router's neighbors wait to hear a router's Hello packets before
       the  they  declare  the router down.  Do not send or receive packets on
       this interface. This has the effect of originating a stub link to  this
       interface into the domain.  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.
	      Used by OSPF authentication to generate and verify the secondary
	      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	 char‐
	      acter  string in double quotes. See the "Authentication" section
	      for more information.

	      Point-to-point interfaces also support the following  parameter:
	      By  default,  OSPF packets to neighbors on point-to-point inter‐
	      faces are sent via the IP multicast mechanism.  Some implementa‐
	      tions of IP multicasting for UNIX, however, have a bug that pre‐
	      cludes the use of IP  multicasting  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 eliminate 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.
       Creates the Link State Advertisement  Traces  the  link	state  packets
       transmitted  Traces the link state packets received Traces the Shortest
       Path First (SPF) calculations Traces OSPF at  the  debugging  level  of
       detail The following packet tracing options, which can be modified with
       detail, send, and recv, are supported: OSPF HELLO  packets,  which  are
       used  to	 determine  neighbor  reachability.  OSPF Database Description
       packets, which are used in synchronizing	 OSPF  databases.   OSPF  Link
       State  Request packets, which are used in synchronizing OSPF databases.
       OSPF Link State Update packets, which are used  in  synchronizing  OSPF
       databases.   OSPF Link State Ack packets, which are used in synchroniz‐
       ing OSPF databases.

The Exterior Gateway Protocol (EGP)
       The Exterior Gateway Protocol (EGP) is  an  exterior  routing  protocol
       used  for exchanging routing information with gateways in other autono‐
       mous systems.  Unlike interior protocols, EGP propagates	 only  reacha‐
       bility  indications,  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 estab‐
       lish an adjacency  with	that  router.	This  is  accomplished	by  an
       exchange	 of  Hello (not to be confused with the HELLO protocol or OSPF
       HELLO messages) and I Heard You	(I-H-U)	 messages  with	 that  router.
       Computers  communicating	 via  EGP  are	called	EGP neighbors, and the
       exchange of HELLO and I-H-U messages is	referred  to  as  acquiring  a
       neighbor.

       Once  the neighbor is acquired, the system polls the neighbor for rout‐
       ing 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]
		   ;
	   } ; } ] ;

       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.   Defines
       the metric used when advertising routes via EGP.	 If not specified, 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 pol‐
       icy.  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.   Specifies	the tracing options for EGP.  By default these
       are inherited from the global trace options.  These values can be over‐
       ridden  on a group or neighbor basis.  (See the Trace Options Statement
       section in gated.conf(4) and the EGP-specific tracing options that fol‐
       low.)   EGP neighbors must be specified as members of a group.  A group
       is usually used to  group  all  neighbors  in  one  autonomous  system.
       Parameters specified on the group clause apply to all of the subsidiary
       neighbors unless explicitly overridden on a neighbor clause.  Any  num‐
       ber 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:
	      Identifies  the  autonomous system number expected from peers in
	      the group.  If not specified, it is learned dynamically.	 Iden‐
	      tifies  the  autonomous system that gated is representing to the
	      group.  The default is that which has been set globally  in  the
	      autonomoussystem	statement.   This  option is usually only used
	      when masquerading as another autonomous system and  its  use  is
	      discouraged.   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.  Each
	      neighbor subclause defines one EGP neighbor within a group.  The
	      only  part  of  the  subclause  that  is	required is the neigh‐
	      bor_address argument, which is the  symbolic  host  name	or  IP
	      address of the neighbor.	The following parameters are optional:
	      Specifies the preference used  for  routes  learned  from	 these
	      neighbors.   This can differ from the default EGP preference set
	      in the egp statement, so that gated can prefer routes  from  one
	      neighbor,	 or group of neighbors, over another.  This preference
	      can be explicitly overriden by import policy.  In the case of  a
	      preference  tie, the second preference, preference2, can be used
	      to break the tie.	 The default value is 0.  Defines a metric  to
	      be  used	for all routes sent to this neighbor.  The value over‐
	      rides the default metric set in the egp statement and  any  met‐
	      rics  specified  by  export  policy,  but only for this specific
	      neighbor or group of neighbors.  Prevents gated from  generating
	      a default route when EGP receives a valid update from its neigh‐
	      bor.  The default route is generated only	 when  the  gendefault
	      option  is  enabled.   Enables gated to accept the default route
	      (0.0.0.0) if it is included in a received	 EGP  update.  If  not
	      specified,  the  default	route  contained  in  an EGP update is
	      ignored.	For efficiency, some networks  have  external  routers
	      announce a default route to avoid sending large EGP update pack‐
	      ets.  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.  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.	 Spec‐
	      ifies  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
	      interface	 with the appropriate local address (through which the
	      neighbor or gateway address is directly reachable) is operating.
	      Specifies	 the  network  queried	in  the	 EGP Poll packets.  By
	      default this is the network shared with neighbors address speci‐
	      fied.   If there is no network shared with the neighbor, specify
	      one of the networks 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 normally not needed.  Sets the minimum accept‐
	      able interval between the transmission  of  EGP  HELLO  packets.
	      The default hello interval is 30 seconds.	 If the neighbor fails
	      to respond to three hello packets, gated stops trying to acquire
	      the  neighbor.   Setting	a larger interval gives the neighbor a
	      better chance to respond.	 The minhello parameter	 is  an	 alias
	      for  the	P1  value  defined in the EGP specification.  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 inter‐
	      val supports 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.   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.   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 trac‐
       ing  options,  which  can  be modified with detail, send, and recv, are
       supported for the EGP protocol:	Traces	all  EGP  packets  Traces  EGP
       HELLO/I-HEARD-U	packets,  which are used to determine neighbor reacha‐
       bility.	Traces EGP ACQUIRE/CEASE packets, which are used  to  initiate
       and  terminate EGP sessions.  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  au‐
       tonomous	 systems  as  well as between transit and stub autonomous sys‐
       tems.  BGP is related  to  EGP,	but  operates  with  more  capability,
       greater flexibility, and less required bandwidth.

       BGP  uses path attributes to provide more information about each route,
       and in particular maintain an AS path, which includes the AS number  of
       each  autonomous	 system the route has transited, providing information
       sufficient to prevent routing loops in  an  arbitrary  topology.	  Path
       attributes  can also be used to distinguish between groups of routes to
       determine administrative preferences, allowing greater  flexibility  in
       determining  route  preference  to  achieve a variety of administrative
       ends.

       BGP supports two basic types of sessions between	 neighbours,  internal
       (sometimes  referred  to	 as IBGP) and external.	 Internal sessions are
       run between routers in the same autonomous system, while external  ses‐
       sions  run between routers in different autonomous systems.  When send‐
       ing 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 considered internal to  your
       own AS.

       The  BGP	 implementation	 supports  three versions of the BGP protocol,
       versions 2, 3 and 4.  BGP versions 2 and 3 are quite similar  in	 capa‐
       bility  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 neigh‐
       bour AS.

       Internal BGP sessions carry at least one metric in the path attributes,
       which  BGP calls the LocalPref.	The size of the metric is identical to
       the MED.	 For BGP versions 2 and 3, this metric	is  considered	better
       when  its  value	 is  smaller;  for  version  4 it is better when it is
       larger.	BGP version 4 sessions 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
       readvertised  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 connection.

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

       The BGP implementation expects external peers to be  directly  attached
       to a shared subnet, and expects those peers to advertise next hops that
       are host addresses on  that  subnet  (though  this  constraint  can  be
       relaxed	by  configuration for testing).	 For groups of internal peers,
       however, you can select one of the following group types: Type internal
       groups  expect  all peers to be directly attached to a shared subnet so
       that, like external peers, the next hops received in BGP advertisements
       can be used directly for forwarding.  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 com‐
       mon policy.  A copy of the message is sent to every peer in the	group,
       with  possible adjustments to the next hop field as appropriate to each
       peer.  This minimizes the computational load of running	large  numbers
       of  peers  in  these types of groups.  BGP allows unconfigured peers to
       connect if an appropriate 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 met‐
       ric.

       The following options are supported: Sets  the  preference  for	routes
       learned	from RIP.  The default preference is 170.  This preference can
       be overridden by a preference specified on the group or peer statements
       or  by  import policy.  Defines the metric used when advertising routes
       via BGP.	 If not specified, no metric is propagated.  This  metric  can
       be overridden by a metric specified on the neighbor or group statements
       or in export policy.   Specifies	 the  tracing  options	for  BGP.   By
       default,	 these are inherited from the global trace options. These val‐
       ues 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.)  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 choosing 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 clus‐
       ter 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 com‐
       bination	 of  type and peer autonomous system. The following four group
       types are supported: 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.	 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  readver‐
       tised 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 routing. If these options are set on the peer sub‐
	      clause, they must equal the  values  set	on  the	 corresponding
	      group clause.  An internal group to which the router is not con‐
	      nected.  The proto keyword 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.	  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 com‐
	      putes 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  configu‐
	      ration.	By  default,  the next hop in BGP routes advertised to
	      type routing peers is set to the local address on the  BGP  con‐
	      nection to those peers, as it is assumed a route to this address
	      will be propagated via the IGP.  The interface_list can  option‐
	      ally  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 routing. If these options are set on the peer  sub‐
	      clause,  they  must  equal  the  values set on the corresponding
	      group clause.  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 net‐
	      work, 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	adver‐
	      tised  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  usu‐
       ally  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:
       [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  set‐
	      ting. If you want these routes to be sent, restart the peer ses‐
	      sion by commenting out the  group	 ascount,  reconfiguring,  and
	      then  uncommenting  and  reconfiguring  again,  or by restarting
	      gated.  If a network is not shared with a peer,  gateway	speci‐
	      fies  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.	  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.  Some routers, known as route servers, are capa‐
	      ble 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.	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 specifica‐
	      tions on this point.  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 num‐
	      bers.  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.	Identifies the autonomous system that gated is	repre‐
	      senting  to  this group of peers.	 The default is that which has
	      been set globally in the autonomoussystem	 statement.   [Routing
	      groups  only] Causes messages to be logged via the syslog mecha‐
	      nism whenever a BGP  group  enters  or  leaves  the  ESTABLISHED
	      state.   By  default,  any  metric  (Multi  Exit	Discriminator)
	      received on a BGP connection 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.  If	speci‐
	      fied,  this  metric  is used as the primary metric on all routes
	      sent to  the  specified  peer(s).	  This	metric	overrides  the
	      default  metric, a metric specified on the group, and any metric
	      specified by export policy.  [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.	 Causes gated to spec‐
	      ify 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.	  Pre‐
	      vents  gated from generating a default route when EGP receives a
	      valid update from its neighbor.  The default route is only  gen‐
	      erated  when  the gendefault option is enabled.  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
	      neighbours.  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  messages  until  the  peer
	      responds.	 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 others.	 This  preference  can
	      be  explicitly  overriden	 by  import  policy.  In the case of a
	      preference tie, the second preference, preference2 can  be  used
	      to  break	 the tie.  The default value is 0.  Control the amount
	      of receive and send buffering required of the kernel.  The maxi‐
	      mum supported is 65535 bytes, although many kernels have a lower
	      limit.  By default,  gated  configures  the  maximum  supported.
	      These parameters are not needed on normally functioning systems.
	      Forces gated to issue warning messages when receiving  question‐
	      able  BGP updates, such as duplicate routes or deletions of non-
	      existing routes.	Typically these events are  silently  ignored.
	      [Routing groups only] Specifies the tracing options for this BGP
	      neighbor.	 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  fol‐
	      low.)   [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 func‐
	      tioning routers that ignore packets sent with a TTL of one.  Not
	      all  kernels  allow the TTL to be specified for TCP connections.
	      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.	 Specifies the
	      version of the BGP protocol to use with this peer.  If not spec‐
	      ified,  the  highest supported version is used first and version
	      negotiation is attempted.	 If it is specified, only  the	speci‐
	      fied version is offered during negotiation.  Currently supported
	      version are 2, 3, and 4.

       The following parameters apply to groups only: 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).  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, meaning that this fea‐
       ture is disabled.  [Routing groups only] Provides a list of  interfaces
       whose  routes  are  carried via the IGP for which third-party next hops
       may be used.  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.  [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.	 [IGP and routing groups only]
       Allows BGP's Local_Pref attribute to be used to set the	gated  prefer‐
       ence on reception, and allows gated preference 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
       statement.  A description of each is as follows: Configures an individ‐
       ual 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.	 Allows for peer connections from  any
       addresses in the specified range of network and mask pairs.  All param‐
       eters for these peers must be configured	 on  the  group	 clause.   The
       internal	 peer  structures are created when an incoming open request is
       received and destroyed when the connection is broken.  For more	detail
       on  specifying the network/mask pairs, see the section on Route Filter‐
       ing 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: 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: Traces all BGP packets.	Traces
       BGP  OPEN  packets,  which  are	used to establish a peer relationship.
       Traces BGP UPDATE packets, which are used to pass network  reachability
       information.   Traces  BGP  KEEPALIVE packets, which are used to verify
       peer reachability.  traces additions, changes,  and  deletions  to  the
       gated routing table.

The ICMP Statement
       On  systems  without the BSD routing socket, gated listens to ICMP mes‐
       sages received by the system.  Currently, gated processes only ICMP re‐
       direct  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 ; } Specifies the	 tracing  options  for
       ICMP. (See the Trace Options Statement section in gated.conf(4) and the
       ICMP tracing options that follow.)

   ICMP Tracing options
       The following packet tracing options, which can be modified with detail
       and recv, are supported: Traces all ICMP packets received.  Traces only
       ICMP REDIRECT packets received.	 Traces	 only  ICMP  ROUTER  DISCOVERY
       packets	received.   Traces  only  ICMP	informational  packets,	 which
       include	 mask	request/response,    info    request/response,	  echo
       request/response	 and  time  stamp  request/response.  Traces only ICMP
       error packets, which include time exceeded, parameter problem, unreach‐
       able 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 re‐
       direct.	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 messages are monitored, this	is  accomplished  by  guessing
       what the kernel would have done with the redirect.  On systems with the
       routing socket, the kernel provides an indication of whether the	 redi‐
       rect 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
       interior	 gateway  protocol  (RIP or OSPF).  It is impossible to enable
       redirects once they have been automatically disabled.  Listening to RIP
       in  nobroadcast	mode  does not cause redirects to be ignored, nor does
       the use of EGP and BGP.	Redirects must be manually configured  off  in
       these cases.

       Note:  In accordance with the latest IETF Router Requirements document,
       gated insures that all ICMP net redirects are processed as  host	 redi‐
       rects.	When  an  ICMP	net  redirect  is  accepted,  gated issues the
       requests to the kernel to make sure that the kernel forwarding table is
       updated to reflect a host redirect instead of a net redirect.

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

   Redirect Syntax
       redirect yes | no | on | off [{
	   preference preference ;
	   interface interface_list
	       [noredirects] | [redirects] ;
	   trustedgateways gateway_list ;
	   traceoptions trace_options ; }] ; Sets the preference for  a	 route
       learned	from  a redirect.  The default is 30.  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:  Specifies  that redirects received via the specified inter‐
       face are ignored.  The default is to accept  redirects  on  all	inter‐
       faces.	This  is  the  default.	 This argument might be necessary when
       noredirects is used on a wild card interface descriptor.	  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.   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	 exis‐
       tence  to  hosts.   It does this by periodically multicasting or broad‐
       casting 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  Solicitation 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 indi‐
       cating for how long the advertised addresses are valid.	This  lifetime
       is configured 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	Adver‐
       tisement.   When	 the  Router advertisements are being sent to a net or
       subnet broadcast, only the address associated with that net  or	subnet
       is included.

   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]
	       ;  }]  ;	 Specifies the Router Discovery tracing options.  (See
       Trace Options Statement section in gated.conf(4) and the Router Discov‐
       ery  specific tracing options.)	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: 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).  The minimum time allowed
	      between sending unsolicited broadcast or multicast Router Adver‐
	      tisements	 from  the  interface.	Must be no less than 3 seconds
	      and no greater than maxadvinterval.  The default is 0.75 *  max‐
	      advinterval.   The  lifetime of addresses in a Router Advertise‐
	      ment.  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.  Specifies	 the  parameters  that
	      apply to the specified set of addresses on these physical inter‐
	      faces.  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.  Specifies that the specified address(es)
	      are included in Router Advertisements.   This  is	 the  default.
	      Specifies	 that  the  specified  address(es) are not included in
	      Router Advertisements.  Specifies that the given address(es) are
	      included in a broadcast Router Advertisement because this system
	      does not support IP multicasting, or some hosts on attached net‐
	      work  do	not  support  IP  multicasting.	 It is possible to mix
	      addresses on a physical interface such that some are included in
	      a broadcast Router Advertisement and some are included in a mul‐
	      ticast Router Advertisement.  This is the default if the	router
	      does  not	 support  IP  multicasting.   Specifies that the given
	      address(es) are included in a  multicast	Router	Advertisement.
	      If  the system does not support IP multicasting, the address(es)
	      are not included.	 By default, if the system and given interface
	      support  IP multicasting, the address(es) are included in a mul‐
	      ticast Router Advertisement.  If the interface does not  support
	      IP  multicasting,	 the  address(es)  are included in a broadcast
	      Router Advertisement.  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.	Speci‐
	      fies  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	 redi‐
	      rect.   This allows the hosts to verify that the given addresses
	      are up and available.

   The Router Discovery Client
       A host listens for Router Advertisements via  the  all-hosts  multicast
       address (224.0.0.2), if IP multicasting is available and enabled, or on
       the interface's broadcast address.  When starting up, or when reconfig‐
       ured,  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 prefer‐
       ence 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]
	  ; }] ; Specifies the tracing	options	 for  OSPF.   (See  the	 Trace
       Options	Statement section in gated.conf(4) and the OSPF-specific trac‐
       ing options that follow.)  Specifies the preference of all Router  Dis‐
       covery  default	routes.	  The default is 55.  Specifies the parameters
       that apply to physical interfaces.  Note a slight difference in conven‐
       tion  from  the rest of gated: interface specifies just physical inter‐
       faces (such as le0, ef0 and en1).  The Router Discovery Client  has  no
       parameters  that	 apply	only  to  interface addresses.	Specifies that
       Router Discovery should be performed  on	 the  specified	 interface(s).
       This  is	 the  default.	 Specifies that Router Discovery should not be
       performed on the specified interface(s).	 Specifies that Router Solici‐
       tations should be broadcast on the specified interface(s).  This is the
       default, if IP multicast support is  not	 available  on	this  host  or
       interface.   Specifies that Router Solicitations should be multicast on
       the specified interface(s).  If IP multicast is not available  on  this
       host  and  interface,  no solicitation is performed.  The default is to
       multicast Router Solicitations if the host and  interface  support  it;
       otherwise,  Router  Solicitations  are  broadcast.   Specifies  that no
       Router Solicitations are sent on this  interface,  even	though	Router
       Discovery  is  performed.   Specifies that initial Router Solicitations
       are sent on this interface.  This is the default.

   Router Discovery Tracing options
       The Router Discovery Client and Server support the  state  trace	 flag,
       which traces various protocol occurrences.  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 proto‐
       col 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 inde‐
       pendently.   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	proto‐
       col 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.	 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.   Enables  debugging  of  the
       ISODE  SMUX  code.   The	 default is debugging disabled.	 Specifies the
       tracing options for SMUX. (See the Trace Options Statement  section  in
       gated.conf(4) and the SMUX tracing options that follow.)

   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 pack‐
       ets  and	 are currently handled differently. The detail, send, and recv
       options are not supported.  SNMP requests received from the SMUX daemon
       and the associated responses.  Protocol requests to register variables.
       Protocol requests to resolve variable names.  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 typ‐
       ical  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 eas‐
       ily 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 inter‐
       face 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 functionality.

       During normal shutdown  processing,  gated  normally  deletes  all  the
       routes  it  has	installed  in  the kernel forwarding table, except for
       those marked with retain.  Optionally, gated can leave  all  routes  in
       the  kernel forwarding table by not deleting any routes.	 In this case,
       changes 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
       forwarding  table (referred to in ISO as a forwarding information base,
       or FIB).	 The table that gated uses internally to store routing	infor‐
       mation 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()
       interface and the routing socket interface.  Their various characteris‐
       tics 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:	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 ker‐
       nel forwarding table, but determined when  a  packet  is	 forwarded  by
       searching for interfaces on the same network.  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.  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.	 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 intro‐
       duced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved
       in  BSD	4.4.   This  interface	is  simply  a socket, similar to a UDP
       socket, on which the kernel and gated exchange messages.	  It  has  the
       following  advantages  over  the ioctl() interface: The network mask is
       passed to the kernel explicitly.	 This allows  different	 masks	to  be
       used  on subnets of the same network.  It also allows routes with masks
       that are more general than the natural mask to be used.	This is	 known
       as classless routing.  Not only is gated able to change the kernel for‐
       warding 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 forward‐
       ing  table;  this means that gated no longer needs to monitor ICMP mes‐
       sages to learn about  redirects.	  Plus,	 there	is  an	indication  of
       whether	the kernel processed the redirect; gated can safely ignore re‐
       direct messages that the kernel did not process.	 Changes to the	 rout‐
       ing  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  routing table.  Plus it
       allows the system administrator the ability to do some operations  with
       the  route  command  while  gated  is  running.	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 configu‐
       ration  time  options that cause delete and add sequences to be used in
       lieu of change messages.	 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
       remnants, and are timed out after a configured interval (which defaults
       to 3 minutes), or as soon as a more attractive route is learned.	  This
       allows  forwarding to occur during the time it takes the routing proto‐
       cols 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
       forwarding 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 broad‐
       cast address (for broadcast 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 con‐
       figured 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 physical interface list for this information for interfaces with
       IFF_BROADCAST set, assuming that their drivers are handled the same  as
       Ethernet drivers.  On some systems, system specific interfaces are used
       to learn this information.

       The interface physical addresses are useful for IS-IS.  For  IP	proto‐
       cols, they are not currently used, but 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 gen‐
       eration, IP forwarding, and  kernel  version  (for  informational  pur‐
       poses).	 On systems where the routing table is read directly from ker‐
       nel 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:
       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.  Like the RTF_REJECT	 flag,	routes
       with  RTF_BLACKHOLE  cause  packets to be dropped, but unreachable mes‐
       sages are not sent.  This flag is valid only on routes pointing at  the
       loopback	 interface.   When  gated starts, it reads all the routes cur‐
       rently in the kernel forwarding table.  Besides	interface  routes,  it
       usually marks everything else as a remnant from a previous run of gated
       and deletes it after a few minutes.  This means that routes added  with
       the route command are not retained after gated has started.

	      To fix this, the RTF_STATIC flag was added.  When the route com‐
	      mand 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 ; } ; Configures	kernel	options.   The
       following  options are valid: 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 operation was broken.  During normal shutdown process‐
       ing,  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.	 On some systems, kernel  mem‐
	      ory  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  for‐
	      warding table.  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 following parameters: Speci‐
	      fies the maximum number of routes that can be  processed	during
	      one  flash update.  The default is 20.  A value of -1 causes all
	      pending route changes of the specified type to be processed dur‐
	      ing  the	flash  update.	 Specifies the type of routes that are
	      processed during a flash update.	Interior specifies that	 inte‐
	      rior  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 pro‐
	      tocols) 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.   Since  only interface routes are normally
	      installed during a flash update, the remaining routes  are  pro‐
	      cessed  in  batches  in the background, that is, when no routing
	      protocol traffic is being received.  Normally,  120  routes  are
	      installed	 at  a	time  to allow other tasks to be performed and
	      this background processing is done at lower priority than	 flash
	      updates.	The following parameters allow tuning of these parame‐
	      ters: Specifies the number of routes that can  be	 processed  at
	      during  one  batch.  The default is 120.	Specifies the priority
	      of the processing of batches of kernel updates  in  relationship
	      to  the  flash  update  processing.  The default is lower, which
	      means that flash updates are processed first.  To process kernel
	      updates at the same priority as flash updates, specify flash; to
	      process them at a lower priority, use lower.

   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 read from the kernel, by nlist(), or similar interface.	Inter‐
       face list scan.	This option is useful when entered  from  the  command
       line  as the first interface list scan is performed before the configu‐
       ration file is parsed.

       The following tracing options can only be specified in  the  configura‐
       tion  file.   They  are not valid from the command line.	 Traces routes
       read from the kernel when gated starts.	Traces requests	 by  gated  to
       Add/Delete/Change routes in the kernel forwarding table.

       The  following  general option and packet-tracing options only apply on
       systems 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.	 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 exchanged with  the  ker‐
       nel,  including	Add/Delete/Change  messages and Add/Delete/Change mes‐
       sages received from other processes.  Redirect messages	received  from
       the kernel.  Interface status messages received from the kernel.	 These
       are only supported on systems with networking  code  derived  from  BSD
       4.4.   Other  messages  received	 from the kernel, including those men‐
       tioned 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]  ;  } ; 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: When
	      this parameter is specified, gateways are only considered	 valid
	      when  they  are  on one of these interfaces.  See the section on
	      interface list specification for the description of  the	inter‐
	      face_list.   Selects  the	 preference of this static route.  The
	      preference controls how this route  competes  with  routes  from
	      other  protocols.	  The default preference is 60.	 Prevents spe‐
	      cific 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.  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.  A
	      blackhole route is the  same  as	a  reject  route  except  that
	      unreachable  messages  are  not  supported.  Normally, the route
	      with the lowest preference is installed in the kernel forwarding
	      table  and is the route exported to other protocols.  When noin‐
	      stall is specified on a route, it is not installed in the kernel
	      forwarding  table when it is active, but it will still be eligi‐
	      ble to be exported to other  protocols.	This  form  defines  a
	      static  interface	 route	that  is used for primitive support of
	      multiple network addresses on one	 interface.   The  preference,
	      retain, reject, blackhole, and noinstall options are the same as
	      described 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 Proto‐
       col (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.  delim off

								gated.proto(4)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

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

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

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