


     GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))                   AAAANNNNNNNNEEEEXXXX                   GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))



     NNNNAAAAMMMMEEEE
          gateways - Annex network initialization

     DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
          When an Annex boots, it reads the ggggaaaatttteeeewwwwaaaayyyyssss section of the
          ccccoooonnnnffffiiiigggg....aaaannnnnnnneeeexxxx file from ////uuuussssrrrr////ssssppppoooooooollll////eeeerrrrppppccccdddd////bbbbffffssss....  This file
          contains commands to initialize the routing tables of all
          Annexes on the local network.  Finally, it can be used to
          add host names to an annex's host name table.

          For routing information, the Annex ggggaaaatttteeeewwwwaaaayyyyssss category has a
          format that corresponds closely to the ////eeeettttcccc////ggggaaaatttteeeewwwwaaaayyyyssss file
          used by _r_o_u_t_e_d(1M).  That is, you can prep the Annex routing
          table with routes for networks and hosts.  However, a few
          differences exist.  The basic entry has the format:
9               {nnnneeeetttt|hhhhoooosssstttt} _a_d_d_r_1 ggggaaaatttteeeewwwwaaaayyyy _a_d_d_r_2 mmmmeeeettttrrrriiiicccc _v_a_l_u_e
               {ppppaaaassssssssiiiivvvveeee|hhhhaaaarrrrddddwwwwiiiirrrreeeedddd}

          The keywords nnnneeeetttt and hhhhoooosssstttt indicate whether the Internet
          address _a_d_d_r_1 specifies a destination network or host. The
          Internet address _a_d_d_r_2 specifies the gateway via which the
          destination is reached.

          Since the RIP implementation on an Annex is listen-only and
          does not exchange any routing information with other
          routers, the Annex does not have the notion of active
          gateways.  Thus, aaaaccccttttiiiivvvveeee routes are not supported in the
          Annex ggggaaaatttteeeewwwwaaaayyyyssss file.  However, a route learned from an
          active gateway producing RIP broadcasts will be aged.  Thus,
          if that gateway stops including a route in its routing
          updates, the route will eventually be discarded.

          The Annex does support passive gateways, and the keyword
          ppppaaaassssssssiiiivvvveeee marks a route as such.  This indicates that the
          gateway does not generate its own routing information.  The
          principal effect of a ppppaaaassssssssiiiivvvveeee route is to keep a routing
          entry from being aged and ultimately discarded.  However,
          such a route can be overridden by a routing update
          containing a better route to the destination.  The Annex
          also supports the notion of hhhhaaaarrrrddddwwwwiiiirrrreeeedddd (or _f_i_x_e_d) routes,
          marked by the keyword hhhhaaaarrrrddddwwwwiiiirrrreeeedddd.  Such a route will never be
          changed or deleted, even if a routing update containing a
          better route is received by the Annex.

          Finally, the metric _v_a_l_u_e indicates the number of hops
          needed to reach the destination.

          There are a few additional differences between the Annex
          ggggaaaatttteeeewwwwaaaayyyyssss category and the ////eeeettttcccc////ggggaaaatttteeeewwwwaaaayyyyssss file used by
          _r_o_u_t_e_d(1M).  First, all Internet addresses in the Annex
          ggggaaaatttteeeewwwwaaaayyyyssss file are required to be specified in standard
          Internet dot notation.  This is because when the Annex is


9     Page 1                                         (printed 10/13/98)






     GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))                   AAAANNNNNNNNEEEEXXXX                   GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))



          reading the gateways file, it is still in the process of
          booting, and thus cannot yet do name-to-address
          translations.  Comments can be placed in the ggggaaaatttteeeewwwwaaaayyyyssss
          section and are introduced by a ``#'' character anywhere on
          a line and terminated by the end of that line.  Excess white
          space in the file is ignored.

          If an Annex has syslogging enabled, it will report errors
          encountered while reading the ggggaaaatttteeeewwwwaaaayyyyssss section with an
          extensive selection of syslog messages.  The messages are
          self-descriptive and include the line number of the
          offending line.  Various information useful for only for
          debugging is logged at the the _i_n_f_o and _d_e_b_u_g levels.

          In addition to routing information, there are two other
          types of entries possible in the ggggaaaatttteeeewwwwaaaayyyyssss category.  The
          first is the conditional:
9               aaaannnnnnnneeeexxxx _i_p_a_d_d_r
                ...
               eeeellllsssseeee
                ...
               eeeennnndddd

          The ellipses represent any group of entries normally valid
          in the gateways file.  This conditional causes all the
          entries in the first set of ellipses to be evaluated only on
          the Annex that uses the given Internet address _i_p_a_d_d_r for
          its Ethernet interface.  The optional eeeellllsssseeee clause causes all
          the entries in the second set of ellipses to be evaluated on
          all Annexes, except for the Annex that matched the aaaannnnnnnneeeexxxx
          clause.  This can be used to selectively assign routes to
          hosts, such as only giving a default route to an external
          gateway to certain Annexes.

          The second additional entry is used for adding host name
          entries to the host table of an annex.  The entries are
          similar to entries in the ////eeeettttcccc////hhhhoooosssstttt file, except aliasing is
          not supported.  When the Annex boots, it adds the host name
          entries in the ggggaaaatttteeeewwwwaaaayyyy section of the configuration file to
          its host table.  The format of a host name entry is the
          Internet Address of the host followed by the host name. For
          example:
9               192.9.200.2 snoopy

          Host name entries may be conditional with the use of the
          aaaannnnnnnneeeexxxx and eeeennnndddd statements.  This restricts the loading of the
          host names to particular annexes.

          The following is an example:

               annex 132.245.10.7



     Page 2                                         (printed 10/13/98)






     GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))                   AAAANNNNNNNNEEEEXXXX                   GGGGAAAATTTTEEEEWWWWAAAAYYYYSSSS((((4444))))



                    net 132.245.5.0 gateway 132.245.99.2 metric 1 hardwired
               else
                    net 132.245.5.0 gateway 132.245.10.7 metric 2 hardwired
                    host 132.245.99.2 gateway 132.245.10.7 metric 2 hardwired
               end

               These entries inform _a_n_n_e_x_0_1, ipaddr 132.245.10.7, that
               _h_o_s_t_0_1, ipaddr 132.245.99.2, is a gateway to network
               132.245.5 and informs other Annexes on network
               132.245.10 that _a_n_n_e_x_0_1 is a gateway to either _h_o_s_t_0_1
               or network 132.245.5.

     BBBBUUUUGGGGSSSS
          The current implementation does not allow the aaaannnnnnnneeeexxxx/eeeellllsssseeee/eeeennnndddd
          clause to be nested.  That is, you cannot use another aaaannnnnnnneeeexxxx
          conditional while already in the scope of another aaaannnnnnnneeeexxxx or
          eeeellllsssseeee clause.  While an error message will not be generated
          if they are nested, the results will not be what is
          expected.

     FFFFIIIILLLLEEEESSSS
          /usr/spool/erpcd/bfs/config.annex

     SSSSEEEEEEEE AAAALLLLSSSSOOOO
          erpcd(1M), routed(1M), config.annex(5)
          _A_n_n_e_x _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e





























     Page 3                                         (printed 10/13/98)



