 |
Index for
Section 4 |
|
 |
Alphabetical
listing for G |
|
 |
Bottom of
page |
|
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
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
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.
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
network, 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
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
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
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
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:
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
protocols. The default preferences are configured by the individual
protocols.
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
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
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
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 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
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:
restrict
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.
metric metric
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 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
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 metric 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 meaningless.
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 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
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
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
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:
default
Refers to routes created by the gendefault option. Use route
generation 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
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 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
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
protocols 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
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 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.
|
Index for
Section 4 |
|
|
Alphabetical
listing for G |
|
 |
Top of
page |
|