unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

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



gated.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 control statements	are
  supported:

    +  Import Statement

    +  Export Statement

    +  Aggregate 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 state-
  ments.

  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 generates 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 con-
  text 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.

  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]
      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 section.	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 network.  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 net-
      work, any	subnets, and any hosts are matched.  The following optional
      modifiers	cause the mask of the destination to be	considered also:

      exact
	  Specifies that the mask of the destination must match	the supplied
	  mask exactly.	 This is used to match a network, but no subnets or
	  hosts	of that	network.

      refines
	  Specifies 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.

      between lownum and highnum
	  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:

  all This form	matches	anything.  It is equivalent to the following:
	   0.0.0.0 mask	0.0.0.0

  default
      This form	matches	the default route.  To match, the address must be the
      default address and the mask must	be all zeros.  This is equivalent to
      the following:
	   0.0.0.0 mask	0.0.0.0	exact

  host host
      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 destination 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 number
  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 routing pro-
  tocol	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 complete.  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])

  aspath aspath_regexp
      Specifies	that an	AS matching the	aspath_regexp variable with the
      specified	origin is matched.

  origin ( [any	| [igp]	| [egp]	| [incomplete])
      An origin	of igp indicates that the route	was learned from an Intra-
      Domain Routing Protocol and is most likely complete. An origin of	egp
      indicates	that the route was learned from	an Inter-Domain	Routing	Pro-
      tocol that does not support AS paths (for	example, EGP) and that the
      path is most likely not complete.	 When the path information is defin-
      itely 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 fol-
  lowing sections describe AS path terms and AS	path operators.

  AS path terms

  The AS path term syntax can be one of	the following:

  autonomous_system
      Any valid	autonomous system number, from one through 65534, inclusive.

  .   A	wild card that matches any autonomous system number.

  (aspath_regexp)
      Parentheses group	subexpressions--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:

  aspath_term {m,n}
      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.

  aspath_term {m}
      A	regular	expression followed by {m}, where m is a positive integer,
      means exactly m repetitions.

  aspath_term {m,}
      A	regular	expression followed by {m,}, where m is	a positive integer,
      means m or more repetitions.

  aspath_term *
      A	regular	expression followed by * means zero or more repetitions.
      This is shorthand	for {0,}.

  aspath_term +
      A	regular	expression followed by + means one or more repetitions.	 This
      is shorthand for {1,}.

  aspath_term ?
      A	regular	expression followed by ? means zero or one repetition.	This
      is shorthand for {0,1}.

  aspath_term |	aspath_term
      Two regular 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:

  restrict
      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.

  preference preference
      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 specified, 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 autonomous_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 regular
  expressions, which are described in the "Matching AS Paths" section.	Note
  that EGP and BGP versions 2 and 3 only support the propagation of natural
  networks, so the host	and default route filters are meaningless.  BGP	ver-
  sion 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	key-
  word in the routing table with a negative preference.	 A negative prefer-
  ence prevents	a route	from becoming active, which prevents 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 proto-
  col, 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 protocols do
  not save routes that were rejected because they have short update inter-
  vals.

  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 con-
  trolled.  OSPF intra-	and inter-area routes are always imported into the
  gated	routing	table with a preference	of 10.	If a tag is specified, 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 preference.

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 syntax of	the export
  statement is similar to the syntax of	the import statement, and the mean-
  ings of many of the parameters are identical.	 The main difference between
  the two is that while	route importation is controlled	by source informa-
  tion,	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 destina-
  tion protocol	that is	referenced by this export statement.  These values
  are as follows:

  restrict
      Specifies	that nothing is	to be exported.	 If specified on the destina-
      tion portion of the export statement, it specifies that nothing at all
      is to be exported	to this	destination.  If specified on the source por-
      tion, 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.

  metric metric
      Specifies	the metric to be used when exporting to	the specified desti-
      nation.



  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 speci-
  fied filters are exported; 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

  Specifying the destination


  As mentioned previously, the syntax of the export statement varies depend-
  ing 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 metric is known as	the
  Multi-Exit Discriminator (MED).

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

  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 meaningless.
  BGP version 4	supports the propagation of any	destination along with a con-
  tiguous 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 gateway.
  If more than one of these is specified, they are processed from most gen-
  eral (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 setting 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 possi-
  ble 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 pro-
  tocol.

  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 statement.

  OSPF ASE routes also have the	provision to carry a tag, which	is an arbi-
  trary	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 gateway.

  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:

  direct
      The route	is to directly attached	interfaces.

  static
      Static routes specified in a static clause.

  kernel
      On systems with the routing socket, routes learned from the routing
      socket are installed in the gated	routing	table with a protocol of ker-
      nel.  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 fol-
  lows:

  proto	default	| aggregate
      restrict ;
  proto	default	| aggregate
      [metric metric] {
      route_filter [restrict | (metric metric)]	;
  } ;

  The following	protocols can only be referenced by protocol:

  default
      Refers to	routes created by the gendefault option.  Use route genera-
      tion instead.

  aggregate
      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 speci-
  fies 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	autonomous
  system border	to generate a route to a network to be advertised via EGP
  given	the presence of	one or more subnets of that network learned via	RIP.

  Older	versions of gated automatically	performed this function, generating
  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 Class-
  less Inter-Domain Routing (CIDR) it is even more frequently the wrong	thing
  to do, so aggregation	must be	explicitly configured.	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 origi-
  nator	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 net-
  work 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	possible 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 con-
  tributor specified with the lowest (most favorable) preference.  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)] ;
      }	;
  } ;

  preference preference
      Specifies	the preference to assign to the	resulting aggregate route.
      The default preference is	130.

  brief
      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.

  proto	proto
      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.

  as autonomous_system
      Restricts	the selection of routes	to those learned from the specified
      autonomous system.

  tag tag
      Restricts	the selection of routes	to those with the specified tag.

  aspath aspath_regexp
      Restricts	the selection of routes	to those that match the	specified AS
      path.

  restrict
      Indicates	that the routes	are not	to be considered as contributors of
      the specified aggregate.	The specified protocol can be any of the pro-
      tocols supported by gated.

  route_filter
      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 con-
  tributing 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 aggre-
  gate.

  Route	Filters


  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 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 Protocol
  (Version 3), J. Burruss, S. Willis.

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

  RFC 1370, Internet Architecture Board	Applicability Statement	for OSPF

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

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

  RFC 1403, BGP	OSPF Interaction, K. Varadhan.


  RFC 1583, OSPF Version 2, J. Moy.