*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> gated.proto (4)              



NAME    [Toc]    [Back]

       gated.proto  -  Gate  daemon  configuration file (protocol

DESCRIPTION    [Toc]    [Back]

       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 management
  of the interior and exterior routing protocols in
       one software daemon.

   Intra-Domain Routing Protocols    [Toc]    [Back]
       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 supported: The Routing
       Information Protocol, Version 1 and Version 2, is the most
       commonly  used  interior  protocol.  RIP selects the route
       with the lowest metric as the best route.  The metric is a
       hop  count  representing  the  number  of gateways through
       which data  must  pass  to  reach  its  destination.   The
       longest path that RIP accepts is 15 hops. If the metric is
       greater than 15, a destination is  considered  unreachable
       and  gated discards the route.  RIP assumes the best route
       is the one that uses the  fewest  gateways  (the  shortest
       path),  not  taking  into  account  congestion or delay on

              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    [Toc]    [Back]
       Exterior protocols are used to exchange  routing  information
  between  autonomous systems.  Exterior protocols are
       only required when  an  autonomous  system  must  exchange
       routing   information   with  another  autonomous  system.
       Routers within an autonomous system run an interior  routing
  protocol  like RIP.  Only those gateways that connect
       an autonomous system to another autonomous system need  to
       run  an exterior routing protocol.  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 exterior routing protocol
 that assumes a  hierarchical  structure,  became  less

              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
              autonomous  systems, but provides more capabilities
              than EGP.  BGP uses path attributes to provide more
              information about each route as an aid in selecting
              the best route.  Path attributes can  include,  for
              example, administrative preferences based on political,
 organizational, or security (policy)  considerations
  in  the  routing  decision.  BGP supports
              nonhierarchical  topologies  and  can  be  used  to
              implement   a   network   structure  of  equivalent
              autonomous systems.

              BGP version 1 is described in RFC 1105,  version  2
              in  RFC  1163, version 3 in RFC 1267, and version 4
              in RFC 1771.  The version 3 MIB is described in RFC
              1269.   The  documents  RFC 1164, RFC 1268, and RFC
              1772 describe the application of version 2, 3,  and
              4  in  the  Internet.   A  protocol analysis of and
              experience with BGP version 3 are available in  RFC
              1265  and RFC 1266.  RFC 1397 talks about advertising
 a default route in BGP version 2 and 3.

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

   Other Routing Protocols    [Toc]    [Back]
       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)    [Toc]    [Back]

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

       A  router running RIP in active mode broadcasts updates at
       set intervals.  Each update contains paired  values  where
       each pair consists of an IP network address and an integer
       distance to that network.  RIP uses a hop count metric  to
       measure the distance to a destination.  In the RIP metric,
       a router advertises directly connected networks at a  metric
  of  1.  Networks 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  implementations,
 if a gateway is not heard from for 180 seconds, all
       routes from that gateway  are  deleted  from  the  routing
       database.   This 180 second interval also applies to deletion
 of specific routes.

       RIP version 2 (more commonly known as RIP II)  adds  capabilities
  to RIP.  Some of these capabilities are compatible
 with RIP I and  some  are  not.   To  avoid  supplying
       information  to RIP I routes that could be misinterpreted,
       RIP II can only use non-compatible features when its packets
  are multicast.  On interfaces that are not capable of
       IP multicast, RIP I-compatible 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 provided in  RIP  Icompatible
  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 different netmasks
              from being included in RIP packets.   RIP  II  adds
              the  ability to explicitly specify the network mask
              with each network in a packet.

              While RIP I routers will ignore the network mask in
              RIP  II  packets,  their calculation of the network
              mask will quite possibly be wrong.  For  this  reason,
  RIP I-compatible RIP II packets must not contain
 networks that would be misinterpreted.   These
              network  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 specific than  the  natural  netmask),  the
              subnet mask is applied to the destination.  If bits
              outside the mask are set it  is  assumed  to  be  a
              host, otherwise it is assumed to be a subnet.

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

              Unlike in previous releases, the zero  subnet  mask
              (a  network that matches the natural network of the
              interface, but has a more specific, or longer, network
 mask) is ignored.  If this is not desirable, a
              route filter can be used  to  reject  it.   RIP  II
              packets  can  also  contain  one  of  two  types of
              authentication string that can be  used  to  verify
              the validity of the supplied routing data.  Authentication
 can be used in  RIP  I-compatible  RIP  II
              packets, but be aware that RIP I routers ignore it.

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

              The second method uses the MD5 algorithm to  create
              a  crypto-checksum of a RIP packet and an authentication
 key of up to 16 characters.  The transmitted
              packet  does  not  contain  the  authentication key
              itself,  instead  it  contains  a  crypto-checksum,
              called  the digest.  The receiving router will perform
 a calculation using the correct authentication
              key  and  discard the packet if the digest does not
              match.  In addition, a  sequence  number  is  maintained
  to  prevent  the  replay  of older packets.
              This method provides a much stronger assurance that
              routing  data originated from a router with a valid
              authentication key.

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

   RIP Syntax    [Toc]    [Back]
       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
       packets are broadcast regardless of the number  of  interfaces
  present.   This  is  useful when propagating static
       routes or routes learned from anther  protocol  into  RIP.
       In  some cases, the use of broadcast when only one network
       interface is present can cause data packets to traverse  a
       single  network twice.  Specifies that RIP packets are not
       broadcast on attached interfaces, even if there  are  more
       than  one.   If a sourcegateways clause is present, routes
       are unicast directly to that gateway.  Specifies that  RIP
       should not make sure that reserved fields in incoming 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 overridden by a preference
       specified in import policy.  Defines the metric used  when
       advertising  routes  via  RIP that were learned from other
       protocols.  If not specified,  the  default  value  is  16
       (unreachable).   This  choice  of  values  requires you to
       explicitly specify a metric in order to export routes from
       other protocols into RIP. This metric can be overridden by
       a  metric  specified  in  export  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 necessary
 when noripin is used on a wild card  interface
              descriptor.  Specifies that no RIP packets are sent
              on the specified interfaces.   The  default  is  to
              send  RIP on all broadcast and non-broadcast interfaces
 when in broadcast mode.  The sending  of  RIP
              on  point-to-point interfaces must be manually configured.
  This is the default.   This  argument  is
              necessary  when it is desired to send RIP on pointto-point
 interfaces and  might  be  necessary  when
              noripin  is  used on a wild card interface descriptor.
  Specifies the RIP metric to add  to  incoming
              routes  before  they  are  installed in the routing
              table.  The default is the kernel interface  metric
              plus  1  (which  is the default RIP hop count).  If
              this value is specified, it is used as the absolute
              value, the kernel metric is not added.  This option
              is used to  make  this  router  prefer  RIP  routes
              learned  via  the  specified interface(s) less than
              RIP routes from other  interfaces.   Specifies  the
              RIP  metric to be added to routes that are send via
              the specified interface(s).  The default  is  zero.
              This  option  is  used to make other routers prefer
              other sources  of  RIP  routes  over  this  router.
              Specifies  that  RIP packets sent via the specified
              interface(s) are version 1 packets.   This  is  the
              default.   Specifies 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
 authentication.   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 trustedgateways
 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  specific 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    [Toc]    [Back]
       The policy option  logs  info  whenever  a  new  route  is
       announced,  the metric being announced changes, or a route
       goes or leaves holddown.   The  following  packet  tracing
       options, which can be modified with detail, send, or recv,
       are supported: 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    [Toc]    [Back]

       Open Shortest Path Routing (OSPF) is a shortest path first
       (SPF) or link-state protocol.  OSPF is an interior gateway
       protocol  that  distributes  routing  information  between
       routers in a single autonomous system.  OSPF  chooses  the
       least  cost  path  as the best path.  Suitable for complex
       networks with a large number  of  routers,  OSPF  provides
       equal  cost  multipath  routing  where packets to a single
       destination can be sent via more than one interface simultaneously.

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

       OSPF allows networks to be grouped  into  areas.   Routing
       information  passed  between  areas  is abstracted, potentially
 allowing a significant reduction in  routing  traffic.
   OSPF uses four different types of routes, listed in
       order of preference: intra-area, inter-area, type 1 external
  and  type 2 external.  Intra-area paths have destinations
 within the same area, inter-area paths have destinations
  in  other OSPF areas and Autonomous System External
       (ASE) routes are routes to destinations  external  to  the
       AS.   Routes  imported into OSPF as type 1 routes are supposed
 to be from igps whose external metrics are  directly
       comparable  to  OSPF  metrics.  When a routing decision is
       being made, OSPF 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  shortest  paths  with  itself  as the root.  This
       shortest-path tree gives the route to each destination  in
       the AS.  Externally derived routing information appears on
       the tree as leaves.  The link-state  advertisement  format
       distinguishes  between  information acquired from external
       sources and information acquired from internal routers, so
       there  is  no ambiguity about the source or 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 service to  choose
       the best route to the destination.

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

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

   Authentication    [Toc]    [Back]
       All OSPF protocol exchanges can be authenticated.  Authentication
  guarantees  that  routing  information  is  only
       imported from trusted routers, to protect the Internet and
       its users.  A variety of  authentication  schemes  can  be
       used  but  a  single  scheme  must  be configured for each
       interface.  This  enables  some  interfaces  to  use  much
       stricter authentication 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  authentication
  key.   Use  this to prevent certain routers from
       exchanging OSPF packets. The interfaces that  the  packets
       are to be sent on still need to be trusted because the key
       will be placed in the packets and can be  seen  by  anyone
       with access to the network.

              To specify simple authentication, add the following
              line to your OSPF interface statements: auth simple
              auth_key;  In  the  preceding  line,  auth_key is a
              string of up to 8 characters, and is  standardized.
              MD5  authentication. Use this when you do not trust
              other users of your network.  This system works  by
              using shared secret keys. Because the keys are used
              to sign the packets with an MD5 checksum, they cannot
  be  forged or tampered with.  Because the keys
              are not included in the packet, snooping the key is
              not  possible. Users of the network can still snoop
              the contents of packets, however, because the packets
 are not encrypted.

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

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

              If no value is  given  for  the  time  ranges,  the
              default  values are: key is always generated key is
              always accepted

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

   OSPF Syntax    [Toc]    [Back]
       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 interface_list nonbroadcast [cost cost] [
                  pollinterval time ;
                  routers {
                      gateway [eligible] ;
                  } ;
              } ] ;
              Backbone only:
              virtuallink neighborid router_id transitarea area {
              } ;
           }  ;  }  ]  ; 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
       protocols 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 policy 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 information.  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 external route when  no
       metric  is  specified on the export. This option maintains
       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 limited.  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 configured, the  incoming
  requests must match the specified authentication key.
       No OSPF state can be changed by these packets, but the act
       of  querying OSPF can utilize system resources.  Each OSPF
       router must be configured into at least one OSPF area.  If
       more than one area is configured, at least one must the be
       backbone.  The backbone can only be configured  using  the
       backbone  keyword,  it 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 interarea
 routes.  Instead, the specified ranges are advertised
       as  summary  network  LSAs.  If restrict is specified, the
       summary network LSAs are not advertised.  Intra-area  LSAs
       that  do  not  fall  into any range are also advertised as
       summary network LSAs.  This option is very useful on  well
       designed networks in reducing the amount of routing information
 propagated between areas.  The entries in this list
       are  either  networks  or a subnetwork/mask pair.  See the
       section on "Route Filtering" 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 loopback interface (one not on the 127  network)
  and  advertise  it  as a stub host.  If this
              address is the same one used as the  router-id,  it
              enables   routing  to  OSPF  routers  by  router-id
              instead of by  interface  address.   This  is  more
              reliable than routing to one of the router's interface
 addresses, which might not  always  be  reachable.
  This form of the interface clause is used to
              configure a broadcast (which requires IP  multicast
              support)  or  a  point-to-point interface.  See the
              "Interfaces Statement" section in gated.conf(4) for
              the description of the interface_list parameters.

              Each interface has a cost.  The costs of all interfaces
 a packet must cross to  reach  a  destination
              are  summed  to  get  the cost to that 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-capable medium that  does
              not support IP multicasting must be configured as a
              non-broadcast interface.

              A non-broadcast interface supports any of the standard
  interface  clauses  listed previously and the
              following two that are  specific  to  non-broadcast
              interfaces:  Before adjacency is established 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 eligibility to
              become a designated  router.   See  the  "Interface
              Parameters" section for a list of parameters common
              to all interface types.  Virtual links are used  to
              establish  or increase connectivity of the backbone
              area.  The neighborid is the router_id of the other
              end   of   the  virtual  link.   The  transit  area
              specified must also configured on this system.  All
              standard interface parameters defined by the interface
 clause can be specified on a virtual link.

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

   Interface Parameters    [Toc]    [Back]
       The following interface parameters are common to all types
       of interfaces: The number of seconds  between  link  state
       advertisement retransmissions 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
       designated  router.   The  length  of  time,  in  seconds,
       between Hello packets that the router sends on the  interface.
   The  length of time, in seconds, a router's neighbors
 wait to hear a router's Hello packets before the they
       declare  the  router down.  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 oneto
 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 datetime
 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 character  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 interfaces are sent via  the
              IP multicast mechanism.  Some implementations of IP
              multicasting for UNIX, however,  have  a  bug  that
              precludes  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    [Toc]    [Back]
       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 synchronizing OSPF databases.

The Exterior Gateway Protocol (EGP)    [Toc]    [Back]

       The Exterior Gateway Protocol (EGP) is an exterior routing
       protocol used  for  exchanging  routing  information  with
       gateways  in  other  autonomous  systems.  Unlike interior
       protocols, EGP propagates only  reachability  indications,
       not  true  metrics.   EGP  updates contain metrics, called
       distances, that range from 0 to 255. The gated daemon compares
 EGP distances learned from the same AS.

       Before  EGP  sends routing information to a remote router,
       it must establish an adjacency with that router.  This  is
       accomplished  by  an exchange of Hello (not to be confused
       with the HELLO protocol or  OSPF  HELLO  messages)  and  I
       Heard  You  (I-H-U)  messages with that router.  Computers
       communicating via EGP are called EGP  neighbors,  and  the
       exchange  of  HELLO  and  I-H-U messages is referred to as
       acquiring a neighbor.

       Once the neighbor is acquired, the system polls the neighbor
  for  routing  information.   The neighbor responds by
       sending an update containing routing information.  If  the
       system receives a poll from its neighbor, it responds with
       its own  update  packet.   When  the  system  receives  an
       update,  it includes routes from the update into its routing
 database.  If the neighbor fails to respond  to  three
       consecutive polls, gated assumes that the neighbor is down
       and removes the neighbor's routes from its database.

   EGP Syntax    [Toc]    [Back]
       egp yes | no | on | off [ {
           preference preference ;
           defaultmetric metric ;
           packetsize number ;
           traceoptions trace_options ;
               [peeras autonomous_system]
               [localas autonomous_system]
               [maxup number]
               neighbor host
                   [preference preference]
                   [preference2 preference]
                   [metricout metric]
                   [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  preference  is 200.  This preference can be overridden
 by a preference specified 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
       policy.  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  overridden  on a group or neighbor basis.
       (See the Trace Options Statement section in  gated.conf(4)
       and  the  EGP-specific  tracing options that follow.)  EGP
       neighbors must be specified as  members  of  a  group.   A
       group  is  usually  used  to  group  all  neighbors in one
       autonomous system.   Parameters  specified  on  the  group
       clause  apply  to  all  of the subsidiary neighbors unless
       explicitly overridden on a neighbor clause.  Any number of
       group  clauses 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.  Identifies 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
              neighbor_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 overrides the  default
              metric  set  in  the  egp statement and any metrics
              specified by export policy, but only for this  specific
  neighbor  or  group  of neighbors.  Prevents
              gated from generating  a  default  route  when  EGP
              receives  a  valid  update  from its neighbor.  The
              default route is generated only when the gendefault
              option  is  enabled.   Enables  gated to accept the
              default route ( if  it  is  included  in  a
              received  EGP update. If not specified, the default
              route contained in an EGP update is  ignored.   For
              efficiency,  some  networks  have  external routers
              announce a default route to avoid sending large EGP
              update  packets.   Enables  gated  to  include  the
              default route ( 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.  Specifies
              the address used on the local end of the connection
              with the neighbor.  The local address must be on an
              interface that is shared with the neighbor or  with
              the  neighbor's  gateway when the gateway parameter
              is used.  A session is opened only when  an  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 specified.
  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 acceptable interval between the  transmission
  of  EGP  HELLO packets.  The default hello
              interval is 30 seconds.  If the neighbor  fails  to
              respond  to three hello packets, gated stops trying
              to acquire the neighbor.  Setting a larger interval
              gives the neighbor a better chance to respond.  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 neighbor is  declared  down
              and  all  routes  learned  from  that  neighbor are
              removed  from  the  routing  database.   A   longer
              polling  interval  supports  a  more stable routing
              database, but  is  not  as  responsive  to  routing
              changes.  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    [Toc]    [Back]
       The state and policy options work with EGP.  The following
       packet tracing options, which can be modified with detail,
       send, and recv, are supported for the EGP protocol: Traces
       all  EGP packets Traces EGP HELLO/I-HEARD-U packets, which
       are used to determine neighbor reachability.   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

The BGP Protocol Statement    [Toc]    [Back]

       The Border Gateway Protocol (BGP) is an  exterior  routing
       protocol  used  for exchanging routing information between
       autonomous systems.  BGP is used for exchange  of  routing
       information between multiple transit autonomous systems as
       well as between transit and stub autonomous systems.   BGP
       is  related  to  EGP,  but  operates with more capability,
       greater flexibility, and less required bandwidth.

       BGP uses path attributes to provide more information about
       each  route,  and in particular maintain an AS path, which
       includes the AS number of each autonomous system the route
       has transited, providing information sufficient to prevent
       routing loops in an arbitrary topology.   Path  attributes
       can  also  be used to distinguish between groups of routes
       to determine 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  sessions  run
       between routers in  different  autonomous  systems.   When
       sending  routes to an external peer the local AS number is
       prepended to the AS path, hence routes  received  from  an
       external peer are guaranteed to have the AS number of that
       peer at the s

 Similar pages
Name OS Title
gated.control Tru64 Gate daemon configuration file (control statements)
gated.conf Tru64 Gate daemon configuration file (general information)
ntpd.conf OpenBSD Network Time Protocol daemon configuration file
ntp.conf FreeBSD Network Time Protocol (NTP) daemon configuration file
bgpd.conf OpenBSD Border Gateway Protocol daemon configuration file
gated_intro Tru64 Information about the gate daemon and its implementation
dhcpv6d HP-UX Dynamic Host Configuration Protocol Server daemon for IPv6
evmdaemon.conf Tru64 EVM daemon configuration file
sshd_config FreeBSD OpenSSH SSH daemon configuration file
sshd_config OpenBSD OpenSSH SSH daemon configuration file
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service