|
|
gated.control(4)
Contents
|
gated.control - Gate daemon configuration file (control
statements)
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
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 generates an error.
Route Filtering Syntax [Toc] [Back]
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 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 network, any subnets, and any hosts are
matched. The following optional modifiers cause
the mask of the destination to be considered also:
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. 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. 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 equivalent 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
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 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 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 [Toc] [Back]
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 specified origin is matched. 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 InterDomain
Routing Protocol that does not support AS paths
(for example, 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 [Toc] [Back]
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 [Toc] [Back]
The AS path term syntax can be one of the following: Any
valid autonomous system number, from one through 65534,
inclusive. A wild card that matches any autonomous system
number. Parentheses group subexpressions--an operator,
such as * or ?, works on a single element or on a regular
expression enclosed in parentheses.
AS path operators [Toc] [Back]
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
expression followed by * means zero or more repetitions.
This is shorthand for {0,}. A regular expression
followed by + means one or more repetitions. This is
shorthand for {1,}. A regular expression followed by ?
means zero or one repetition. This is shorthand for
{0,1}. Two regular expressions separated by a vertical
bar means match either As term
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 [Toc] [Back]
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
protocols. The default preferences are configured by the
individual protocols.
Route Filters [Toc] [Back]
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 [Toc] [Back]
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 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 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 [Toc] [Back]
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 protocols do not save routes that
were rejected because they have short update intervals.
Importing routes from OSPF [Toc] [Back]
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 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 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 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 [Toc] [Back]
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 [Toc] [Back]
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 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 [Toc] [Back]
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 [Toc] [Back]
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 MultiExit
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 meaningless. BGP version 4 supports the
propagation of any destination along with a contiguous
network mask.
Exporting to RIP [Toc] [Back]
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 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 setting a default
metric for RIP is not sufficient. This is a safeguard to
verify that the announcement is intended.
Exporting to OSPF [Toc] [Back]
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 statement.
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 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 Classless 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 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 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 contributor
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 [Toc] [Back]
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 aggregate 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 aggregate. 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 [Toc] [Back]
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
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. delim off
gated.control(4)
[ Back ] |
