gated.control 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.control(4)					      gated.control(4)

NAME
       gated.control - Gate daemon configuration file (control statements)

DESCRIPTION
       Control	statements control routes that are imported from routing peers
       and routes that are exported to	these  peers.	These  are  the	 final
       statements  to  be included in the gated.conf file.  The following con‐
       trol statements are supported: Import Statement Export Statement Aggre‐
       gate Statement Generate Statement

Route Filtering
       Routes  are  filtered  by specifying a configuration language that will
       match a certain set of routes by destination,  or  by  destination  and
       mask.   In  addition,  route  filters are used on martians, import, and
       export statements.

       The action that is taken when no match is found depends on the context,
       for  example, import and export route filters assume an all reject ; at
       the end of a list.

       A route matches the most specific filter that applies.  Specifying more
       than  one  filter with the same destination, mask, and modifiers gener‐
       ates an error.

   Route Filtering Syntax
       network [exact | refines | between  num	and  num]  network  mask  mask
       [exact | refines | between num and num] network masklen number [exact |
       refines | between num and num] all default host host

       The preceding shows all the possible formats for a route	 filter.   Not
       all of these formats are available in all places; for example, the host
       and default formats are not valid in the martians statement.

       In most cases, you can specify additional parameters  relevant  to  the
       context	of  the	 filter.   For example, on a martian statement you can
       specify the allow keyword, on an import statement  you  can  specify  a
       preference,  and on an export you can specify a metric.	Route matching
       usually requires both an address and  a	mask,  although	 the  mask  is
       implied in the all, default, and host host forms described in this sec‐
       tion.  These first three forms vary in how the mask is  specified.   In
       the  first form, the mask is implied to be the natural mask of the net‐
       work.  In the second, the mask is explicitly specified.	In the	third,
       the mask is specified by the number of contiguous one bits.

	      If  no additional parameters are specified, any destination that
	      falls in the range given by the network and mask is matched; the
	      mask  of	the  destination  is ignored.  If a natural network is
	      specified, the network, any subnets, and any hosts are  matched.
	      The  following optional modifiers cause the mask of the destina‐
	      tion to be considered also: Specifies that the mask of the  des‐
	      tination	must match the supplied mask exactly.  This is used to
	      match a network, but no subnets or hosts of that network.	 Spec‐
	      ifies  that the mask of the destination must be more specific or
	      longer than the filter mask.  This is used to match  subnets  or
	      hosts  of	 a  network,  but not the network.  Specifies that the
	      mask of the destination must be as or more specific (as long  or
	      longer)  than  the lower limit (lownum) and no more specific (as
	      long or shorter) than the upper limit (highnum). Note that exact
	      and refines are both special cases of between.

	      Instead of using any of the preceding syntax statements, you can
	      use the one of the following: This form matches anything.	 It is
	      equivalent  to  the  following:  0.0.0.0	mask 0.0.0.0 This form
	      matches the default route.  To match, the address	 must  be  the
	      default address and the mask must be all zeros.  This is equiva‐
	      lent to the following: 0.0.0.0  mask  0.0.0.0  exact  This  form
	      matches  the  specific host.  To match, the address must exactly
	      match the specified host and the network mask  must  be  a  host
	      mask  (that  is,	all 1s).  This is equivalent to the following:
	      host mask 255.255.255 exact

Matching AS paths
       An AS path is a list of autonomous systems that routing information has
       passed  through	to  get to this router. This information indicates the
       origin of the AS path, and can be used to prefer one path to a destina‐
       tion  network  over  another.   The  primary method for doing this with
       gated is to specify a list of patterns to be applied to AS  paths  when
       importing and exporting routes.

       Each autonomous system that a route passed through prepends its AS num‐
       ber to the beginning of the AS path.

       The origin information details the completeness of AS path information.
       An origin of igp indicates the route was learned from an interior rout‐
       ing protocol and is most likely complete.  An origin of	egp  indicates
       the  route  was learned from an exterior routing protocol that does not
       support AS paths (EGP for example) and the path is most likely not com‐
       plete.  When the path information is definitely not complete, an origin
       of incomplete is used.

       AS path regular expressions are defined in RFC 1164 section 4.2.

   AS Path Matching Syntax
       An AS path is matched using the following syntax: aspath	 aspath_regexp
       origin ( [any | [igp] | [egp] | [incomplete])

       Specifies that an AS matching the aspath_regexp variable with the spec‐
       ified origin is matched.	 An origin of igp indicates that the route was
       learned	from  an Intra-Domain Routing Protocol and is most likely com‐
       plete. An origin of egp indicates that the route was  learned  from  an
       Inter-Domain Routing Protocol that does not support AS paths (for exam‐
       ple, EGP) and that the path is most likely not complete.	 When the path
       information  is	definitely  not	 complete,  an origin of incomplete is
       used.  An origin of any can be used for any origin.

   AS path regular expressions
       An AS path regular expression is composed of one or more AS path	 terms
       and  path  operators,  and  uses the alphabet as the set of AS numbers.
       The following sections describe AS path terms and AS path operators.

       AS path terms

       The AS path term syntax can be one of the following: Any valid  autono‐
       mous  system  number,  from  one through 65534, inclusive.  A wild card
       that matches any autonomous system number.   Parentheses	 group	subex‐
       pressions--an operator, such as * or ?, works on a single element or on
       a regular expression enclosed in parentheses.

       AS path operators

       The AS path operator syntax can be one  of  the	following:  A  regular
       expression  followed  by {m,n}, where m and n are non-negative integers
       and m <= n, means at least m and at  most  n  repetitions.   A  regular
       expression  followed  by	 {m},  where  m	 is  a positive integer, means
       exactly m repetitions.  A regular expression followed by {m,}, where  m
       is  a positive integer, means m or more repetitions.  A regular expres‐
       sion followed by * means zero or more repetitions.  This	 is  shorthand
       for {0,}.  A regular expression followed by + means one or more repeti‐
       tions.  This is shorthand for {1,}.  A regular expression followed by ?
       means  zero or one repetition.  This is shorthand for {0,1}.  Two regu‐
       lar expressions separated by a vertical bar means match either As term

The Import Statement
       The importation of routes from routing protocols and  the  installation
       of  the	routes	in  gated's  routing  database is controlled by import
       statements.  The format of an import statement varies depending on  the
       source protocol.

   Specifying preferences
       The following keywords control how routes compete with other protocols:
       Specifies that the routes are not desired in  the  routing  table.   In
       some cases, this means that the routes are not installed in the routing
       table.  In others, it means that they are  installed  with  a  negative
       preference;  this  prevents  them  from becoming active so they are not
       installed in the forwarding  table  or  exported	 to  other  protocols.
       Specifies  the preference value used when comparing this route to other
       routes from other protocols.  The  route	 with  the  lowest  preference
       available  at any given route becomes the active route, is installed in
       the forwarding table, and is eligible to be exported  to	 other	proto‐
       cols.   The default preferences are configured by the individual proto‐
       cols.

   Route Filters
       All import statement formats allow the following	 route	filters.   See
       the  Route  Filtering  section  for  a detailed explanation of how they
       work.  When no route filtering is specified (that is, when the restrict
       keyword is specified on the first line of a statement), all routes from
       the specified source match that statement.  If any filters  are	speci‐
       fied,  only  routes that match the specified filters are imported; that
       is, if any filters are specified, an all restrict ; is assumed  at  the
       end  of the list.  network [exact | refines] network mask mask [exact |
       refines] network masklen number [exact | refines] default host host

   Importing routes from BGP and EGP
       The format for importing routes from BGP and EGP is as follows:	import
       proto bgp | egp autonomoussystem autonomous_system
	   [aspath-opt] restrict ; import proto bgp | egp autonomoussystem au‐
       tonomous_system
	   [aspath-opt] [preference preference ] {
	   route_filter [restrict | (preference	 preference)]  ;  }  ;	import
       proto bgp aspath aspath_regexp
	   origin any | ([igp] [egp] [incomplete])
	   [aspath-opt] restrict ; import proto bgp aspath aspath_regexp
	   origin any | ( [igp] [egp] [incomplete])
	   [aspath-opt] [preference preference] {
	   route_filter [restrict | (preference preference)] ; } ;

       EGP  importation	 can be controlled by specifying an autonomous system.
       BGP also supports controlling propagation by the use of an AS path reg‐
       ular  expressions,  which are described in the "Matching AS Paths" sec‐
       tion.  Note that EGP and BGP versions 2 and 3 only support the propaga‐
       tion  of	 natural  networks,  so the host and default route filters are
       meaningless.  BGP version 4 supports the propagation of any destination
       along with a contiguous network mask.

       The  aspath-opt	option allows the specification of import policy based
       on the path attributes found in the BGP	update.	 (The  option  is  not
       usable with EGP.)  If multiple communities are specified in the aspath-
       opt option, only updates carrying all of the specified communities will
       be  matched.   If none is specified, only updates lacking the community
       attribute will be matched.

       Note that it is quite possible for several BGP import clauses to	 match
       a  given	 update.   If more than one clause matches, the first matching
       clause will be used; all later matching clauses will be	ignored.   For
       this  reason,  it  is  generally desirable to order import clauses from
       most to least specific.	An import clause without an aspath-opt	option
       will match any update with any (or no) communities.

       EGP  and BGP both store any routes that were rejected either implicitly
       by not being mentioned  in  a  route  filter  or	 explicitly  with  the
       restrict	 keyword  in  the routing table with a negative preference.  A
       negative preference prevents a route from becoming active,  which  pre‐
       vents  it  from	being installed in the forwarding table or exported to
       other protocols.	 This alleviates the need to break and	reestablish  a
       session upon reconfiguration if importation policy is changed.

   Importing routes from RIP and Redirects
       The  format  for importing routes from RIP and redirects is as follows:
       import proto rip | redirect
	   [(interface interface_list) | (gateway gateway_list)]
	   restrict ; import proto rip | redirect
	   [(interface interface_list) | (gateway gateway_list)]
	   [preference preference] {
	   route_filter [restrict | (preference preference)] ; } ;

       The importation of RIP and Redirect routes can  be  controlled  by  any
       protocol,  source  interface,  and source gateway.  If more than one of
       these is specified, they are processed from most general (protocol)  to
       most specific (gateway).

       RIP  does not support the use of preference to choose between routes of
       the same protocol.  That is left to the protocol metrics.  These proto‐
       cols  do	 not  save  routes  that were rejected because they have short
       update intervals.

   Importing routes from OSPF
       The format for importing routes from OSPF is as follows:	 import	 proto
       ospfase [tag ospf_tag] restrict ; import proto ospfase [tag ospf_tag]
	   [preference preference] {
	   route_filter [restrict | (preference preference)] ; } ;

       Due  to	the  nature of OSPF, only the importation of ASE routes can be
       controlled.  OSPF intra- and inter-area routes are always imported into
       the  gated  routing  table with a preference of 10.  If a tag is speci‐
       fied, the import clause applies only to routes with the specified tag.

       It is only possible to restrict the importation of OSPF ASE routes when
       the system is functioning as an AS border router.  This is accomplished
       by specifying an export ospfase	clause.	  Specification	 of  an	 empty
       export  clause may be used to restrict importation of ASEs when no ASEs
       are being exported.

       Like the other interior protocols, preference cannot be used to	choose
       between	OSPF  ASE routes; that is done by the OSPF costs.  Routes that
       are rejected by policy are stored in the table with a negative  prefer‐
       ence.

The Export Statement
       The  import statement controls which routes received from other systems
       are used by gated.  The export  statement  controls  which  routes  are
       advertised  by  gated to other systems.	Like the import statement, the
       syntax of the export statement varies slightly per protocol.  The  syn‐
       tax  of	the  export  statement	is similar to the syntax of the import
       statement, and the meanings of many of the  parameters  are  identical.
       The  main difference between the two is that while route importation is
       controlled by source information, route exportation  is	controlled  by
       both the destination and the source.

       The  outer  portion of an export statement specifies the destination of
       the routing  information	 you  are  controlling.	  The  middle  portion
       restricts  the  sources	of importation that you want to consider.  The
       innermost portion is a route filter that selects individual routes.

   Specifying Metrics
       The most specific specification of a metric is the one applied  to  the
       route  being exported.  The allowable values for a metric depend on the
       destination protocol that  is  referenced  by  this  export  statement.
       These  values are as follows: Specifies that nothing is to be exported.
       If specified on the destination portion of  the	export	statement,  it
       specifies  that	nothing	 at all is to be exported to this destination.
       If specified on the source portion, it specifies that nothing from this
       source  is to be exported to this destination.  If specified as part of
       a route filter, it specifies that the routes matching that  filter  are
       not  to be exported.  Specifies the metric to be used when exporting to
       the specified destination.

   Route Filters
       All the export statement formats allow route filters.  See  the	"Route
       Filtering"  section for an explanation of how they work.	 When no route
       filtering is specified (that is, when  restrict	is  specified  on  the
       first  line of a statement), all routes from the specified source match
       that statement.	If any filters are specified, only routes  that	 match
       the  specified filters are exported; that is, if any filters are speci‐
       fied, an all restrict ; is assumed at the end  of  the  list.   network
       [exact  |  refines] network mask mask [exact | refines] network masklen
       number [exact | refines] default host host

   Specifying the destination
       As mentioned previously, the syntax  of	the  export  statement	varies
       depending on the protocol to which it is being applied.	One thing that
       applies in all cases is the specification of a metric.	All  protocols
       define  a  default metric to be used for routes being exported, in most
       cases this can be overridden at several levels of the export statement.

       For information on the source of the routing information being exported
       (the export_list), see the "Specifying the Source" section.

       Exporting to EGP and BGP

       The  formats  for exporting to EGP and BGP are as follows: export proto
       bgp | egp as autonomous system
	   restrict ; export proto bgp | egp as autonomous system [aspath-opt]
	   [metric metric] {
	   export_list ; } ;

       Exportation to EGP and BGP is controlled by autonomous system; the same
       policy  is  applied to all routers in the AS.  EGP metrics range from 0
       to 255, inclusive, with 0 being the most attractive.  BGP  metrics  are
       16-bit  unsigned quantities, ranging from 0 to 65535, inclusive, with 0
       being the most attractive.   While  BGP	version	 4  actually  supports
       32-bit unsigned quantities, gated does not.  In BGP version 4, the met‐
       ric is known as the Multi-Exit Discriminator (MED).

       In BGP, you can use the aspath-opt option to  send  the	BGP  community
       attribute.   Any	 communities  specified with the aspath-opt option are
       sent in addition to any received with the route	or  specified  in  the
       group statement.

       If  no  export  policy is specified, only routes to attached interfaces
       are exported.  If a policy is specified, the defaults  are  overridden;
       it  is  necessary  to  explicitly  specify  everything  that  is	 to be
       exported.

       Note that EGP and BGP versions 2 and 3 only support the propagation  of
       natural	networks,  so  the host and default route filters are meaning‐
       less.  BGP version 4 supports the propagation of any destination	 along
       with a contiguous network mask.

       Exporting to RIP

       The formats for exporting to RIP is as follows: export proto rip
	   [(interface interface_list) | (gateway gateway_list)]
	   restrict ; export proto rip
	   [(interface interface_list) | (gateway gateway_list)]
	   [metric metric] {
	   export_list ; } ;

       Exportation  to	RIP is controlled by any protocol, interface, or gate‐
       way.  If more than one of these is specified, they are  processed  from
       most general (protocol) to most specific (gateway).

       It impossible to set metrics for exporting RIP routes into RIP.	If you
       try to do this, the attempt is ignored.

       If no export policy is specified, RIP and interface routes are exported
       into  RIP.  If any policy is specified, the defaults are overridden; it
       is necessary to explicitly specify everything that you want exported.

       When exporting routes from other protocols, you must specify  a	metric
       on  the	export	statement or in the route filters.  If you do not, the
       value specified in  defaultmetric  is  used.   If  not  specified,  the
       defaultmetric value is 16 (unreachable).	 It is likely that this is not
       the desired result.

       RIP version 1 assumes that all subnets of the shared network  have  the
       same  subnet  mask  so  they are only able to propagate subnets of that
       network.	 RIP version 2 removes that  restriction  and  is  capable  of
       propagating all routes when not sending version 1 compatible updates.

       To  announce  routes  that specify a next hop of the loopback interface
       (that is, static and internally generated default routes) via RIP , you
       must  specify the metric at some level in the export clause.  Just set‐
       ting a default metric for RIP is not sufficient.	 This is  a  safeguard
       to verify that the announcement is intended.

       Exporting to OSPF

       The  formats for exporting to OSPF are as follows: export proto osfpase
       [type 1 | 2] [tag ospf_tag]
	   restrict ; export proto osfpase [type 1 | 2] [tag ospf_tag]
	   [metric metric] {
	   export_list ; } ;

       It is not possible to create OSPF intra-area or	inter-area  routes  by
       exporting  routes  from	the gated routing table into OSPF.  It is only
       possible to export from the gated routing table into OSPF  ASE  routes.
       It  is  also  not  possible  to	control the propagation of OSPF routes
       within the OSPF protocol.

       There are two types of OSPF  ASE	 routes:  type	1  and	type  2.   See
       gated.proto(4)  for  a  detailed	 explanation  of  the  two types.  The
       default type, which is specified by the defaults subclause of the  ospf
       clause,	 and can be overridden by a specification on the export state‐
       ment.

       OSPF ASE routes also have the provision to carry a  tag,	 which	is  an
       arbitrary  32-bit  number  that	can  be used on OSPF routers to filter
       routing information.  See gated.proto(4) for  detailed  information  on
       OSPF  tags.   The default tag specified by the ospf defaults clause can
       be overridden by a tag specified on the export statement.

   Specifying the source
       The export list specifies an export action based on  the	 origin	 of  a
       route.  The syntax varies depending on the source.

       Exporting BGP and EGP routes

       The  formats  for exporting routes to BGP and EGP are as follows: proto
       bgp | egp autonomoussystem autonomous_system
	   restrict ; proto bgp | egp autonomoussystem autonomous_system
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       BGP and EGP routes are specified	 by  source  autonomous	 system.   All
       routes may be exported by as path, see the sections on "Exporting by AS
       path" for more information.

       Exporting RIP routes

       The formats for exporting routes to RIP are as follows: proto rip
	   [(interface interface_list) | (gateway gateway_list)]
	   restrict ; proto rip
	   [(interface interface_list) | (gateway gateway_list)]
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       RIP routes are exported by protocol, source interface, or source	 gate‐
       way.

       Exporting OSPF routes

       The  formats  for exporting routes to OSPF are as follows: proto ospf |
       ospfase restrict ; proto ospf | ospfase [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       Both OSPF and OSPF ASE routes can be  exported  into  other  protocols.
       See the sections on "Exporting by tag" for more information.

       Exporting routes from non-routing protocols

       The  formats  for  exporting  routes  from  a non-routing protocol with
       interface are as follows: proto direct | static | kernel
	   [(interface interface_list)]
	   restrict ; proto direct | static | kernel
	   [(interface interface_list)]
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       The following protocols can be exported by protocol or by the interface
       of  the next hop: The route is to directly attached interfaces.	Static
       routes specified in a static  clause.   On  systems  with  the  routing
       socket,	routes	learned	 from  the routing socket are installed in the
       gated routing table with a protocol of kernel.	These  routes  can  be
       exported by referencing this protocol.  This is useful when you want to
       have a script install routes with the route command and propagate  them
       to other routing protocols.

       The  formats  for  exporting  routes from a non-routing protocol are as
       follows: proto default | aggregate
	   restrict ; proto default | aggregate
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       The following protocols can only be referenced by protocol:  Refers  to
       routes created by the gendefault option.	 Use route generation instead.
       Refers to routes synthesized from other routes when the	aggregate  and
       generate	 statements  are used.	See the section on "Route Aggregation"
       for more information.

   Exporting by AS path
       The formats for exporting routes by AS path are as follows: proto proto
       | all aspath aspath_regexp
	   origin any | ([igp] [egp] [incomplete])
	   restrict ; proto proto | all aspath aspath_regexp
	   origin any | ([igp] [egp] [incomplete])
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       When  BGP  is  configured, all routes are assigned an AS path when they
       are added to the routing table.	For all interior routes, this AS  path
       specifies  IGP as the origin and no ASes in the AS path (the current AS
       is added when the route is exported).  For EGP  routes,	this  AS  path
       specifies  EGP as the origin and the source AS as the AS path.  For BGP
       routes, the AS path is stored as learned from BGP.

       AS path regular expressions are described in the section	 on  "Matching
       AS paths".

   Exporting by route Tag
       The  formats  for  exporting  routes by route tag are as follows: proto
       proto | all tag tag restrict ; proto proto | all tag tag
	   [metric metric] {
	   route_filter [restrict | (metric metric)] ; } ;

       Both OSPF and RIP version 2 currently support tags; all other protocols
       always  have  a	tag  of	 zero.	 The  source of exported routes can be
       selected based on this tag.  This is useful when routes are  classified
       by tag when they are exported into a given routing protocol.

Route Aggregation
       Route  aggregation is a method of generating a more general route given
       the presence of a specific route.  It is used, for example, at  an  au‐
       tonomous	 system	 border	 to generate a route to a network to be adver‐
       tised via EGP given the presence of one or more subnets of that network
       learned via RIP.

       Older versions of gated automatically performed this function, generat‐
       ing an aggregate route to a natural network (using the old Class A,  B,
       and  C concept) given an interface to a subnet of that natural network.
       However, that was not always the correct thing  to  do,	and  with  the
       advent  of  Classless  Inter-Domain Routing (CIDR) it is even more fre‐
       quently the wrong thing to do, so aggregation must be  explicitly  con‐
       figured.	 No aggregation is performed unless explicitly requested in an
       aggregate statement.

       Route aggregation is also used by regional  and	national  networks  to
       reduce  the  amount of routing information passed around.  With careful
       allocation of network addresses to clients, regional networks can  just
       announce one route to regional networks instead of hundreds.

       Aggregate  routes  are  not  actually used for packet forwarding by the
       originator of the aggregate route, only by the receiver (if it wishes).
       A  router  receiving  a packet that does not match one of the component
       routes that led to the generation of an aggregate route is supposed  to
       respond	with  an ICMP network unreachable message.  This is to prevent
       packets for unknown component routes from  following  a	default	 route
       into  another  network where they would be forwarded back to the border
       router - around and around -  until  their  TTL	expires.   Sending  an
       unreachable  message for a missing piece of an aggregate is only possi‐
       ble on systems that support reject routes.

       A slight variation of aggregation is the generation of a route based on
       the  existence  of  certain conditions.	This is sometimes known as the
       route of last resort.  This route inherits the next hops	 and  AS  path
       from the contributor specified with the lowest (most favorable) prefer‐
       ence.  The most common use for this is to generate a default  based  on
       the presence of a route from a peer on a neighboring backbone.

   Aggregation and Generation Syntax
       aggregate (default
	   | (network [(mask mask) | (masklen number)]))
	   [preference preference] [brief] {
	   proto [all | direct | static | kernel | aggregate | proto]
	       [(as autonomous system) | (tag tag)
		   | (aspath aspath_regexp)]
	       restrict ;
	   proto [all | direct | static | kernel | aggregate | proto]
	       [(as autonomous system) | (tag tag)
		   | (aspath aspath_regexp)]
	       [preference preference] {
	       route_filter [restrict | (preference preference)] ;
	   } ; } ; generate default
	   | (network [(mask mask) | (masklen number)])
	   [preference preference]
	   [brief] {
	   proto [all | direct | static | kernel | aggregate | proto]
	       [(as autonomous system) | (tag tag)
		   | (aspath aspath_regexp)]
	       restrict ;
	   proto [all | direct | static | kernel | aggregate | proto]
	       [(as autonomous system) | (tag tag)
		   | (aspath aspath_regexp)]
	       [preference preference] {
	       route_filter [restrict | (preference preference)] ;
	   }  ; } ; Specifies the preference to assign to the resulting aggre‐
       gate route.  The default preference is 130.  Specifies that the AS path
       be truncated to the longest common AS path.  The default is to build an
       AS path consisting of SETs and SEQUENCEs of all contributing AS	paths.
       In addition to the special protocol keywords, the contributing protocol
       can be chosen from among any of the ones supported  by  (and  currently
       configured  into)  gated.   Restricts  the selection of routes to those
       learned from the specified autonomous system.  Restricts the  selection
       of  routes to those with the specified tag.  Restricts the selection of
       routes to those that match the specified AS path.  Indicates  that  the
       routes are not to be considered as contributors of the specified aggre‐
       gate.  The specified protocol can be any of the protocols supported  by
       gated.  See the "Route Filters" section.

       Routes  that  match  the	 route filters are called contributing routes.
       The order of contributing routes is based on the aggregation preference
       that  applies  to them.	If there are more than one contributing routes
       with the same aggregating preference, the route's own  preferences  are
       used  to	 order the routes.  The preference of the aggregate route will
       be that of the contributing route with the lowest aggregate preference.

       A route may only contribute to an aggregate route that is more  general
       than  itself;  it  must	match the aggregate under its mask.  Any given
       route may only contribute to one aggregate route,  which	 will  be  the
       most  specific  configured,  but an aggregate route may contribute to a
       more general aggregate.

   Route Filters
       When no route filtering is specified (that is, when restrict is	speci‐
       fied  on	 the first line of a statement), all routes from the specified
       source match that statement.  If any filters are specified, only routes
       that  match  the specified filters are considered as contributors; that
       is, if any filters are specified, an all restrict ; is assumed  at  the
       end  of	the  list.   The following route filter forms are valid in all
       route aggregation forms.	 See the  "Route  Filtering"  section  for  an
       explanation of how they work.  network [ exact | refines ] network mask
       mask [exact | refines ] network masklen number  [  exact	 |  refines  ]
       default host host

RELATED INFORMATION
       Daemons: gated(8).

       Files: gated.conf(4), gated.proto(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.control(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