Tải bản đầy đủ
[Appendix B] B.10 Control Statements

[Appendix B] B.10 Control Statements

Tải bản đầy đủ

[Appendix B] B.10 Control Statements

address [mask mask | masklen number] [exact | refines]
Defines a range of addresses using an address and an address mask. The address mask can be
defined with the keyword mask and a mask written in dotted decimal notation or with the
keyword masklen and a numeric prefix length. If no mask is defined the natural mask of the
network is used. Two options can be used:
exact
Matches a network, but no subnets or hosts of that network.
refines
Matches subnets and/or hosts of a network, but not the network itself.
all
Matches every possible address.
default
Matches only the default route.
host address
Matches an individual host address.
A routing filter that matches everything on network number 192.168.12.0 and the individual host
10.104.19.12 contains:
192.168.12.0 masklen 24 ;
host 10.104.19.12 ;
When no route filtering is specified in an import or export statement, all routes from the specfied
source will match that statement. If any filters are specified, only routes that match the specified filters
are imported or exported.
Border Gateway Protocol (BGP) is designed to support policy-based routing. A key feature of BGP is
that it is a path-vector protocol. Import and export statements allow you to use the AS path vector to
enforce your routing policy.
An AS path lists the autonomous systems end-to-end for a route, and provides an indication of the
completeness of the path. Each autonomous system that a route passes through prepends its AS
number to the beginning of the AS path.
The "origin" of the path indicates its completeness. 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
file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (2 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

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. All of these
origins can be specified in the import and export statements, and therefore used in your routing
policy. The keyword any is used when the policy applies to all origins.
The AS path can also be used in the control statements by defining an AS path regular expression. [3]
The AS path regular expression provides a pattern-matching syntax used to filter routes based on the
autonomous system numbers in the AS paths associated with those routes.
[3] AS path regular expressions are defined in RFC 1164.
An AS path regular expression is a regular expression composed of autonomous system numbers and
special operators. Table 13.1 lists the AS path operators. The AS path operator operates on an AS path
term, which is an autonomous system number, a dot (.), which matches any autonomous system
number, or a parentheses-enclosed subexpression.
Table B.1: AS Path Operators
Symbol
Meaning
{m,n}
At least m and at most n repetitions.
{m}
Exactly m repetitions.
{m,}
m or more repetitions.
*
0 or more repetitions.
+
1 or more repetitions.
?
0 or 1 repetition.
aspath_term | aspath_term Matches either the AS term on the left, or the AS term on the
right.
A simple AS path regular expression might be:
import proto bgp aspath 164+ origin any restrict ;
This restricts all routes that have one or more occurrences of autonomous system number 164 in their
path vector.

B.10.1 The import Statement
The format of an import statement varies depending on the source protocol. The format of the import
statements for the exterior gateway protocols is:
import proto bgp | egp autonomoussystem as_number
file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (3 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

[restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
};
import proto bgp aspath aspath_regexp origin any | igp | egp | incomplete
[restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
};
BGP and EGP importation may be controlled by autonomous system number. BGP also can control
importation using AS path regular expressions. Routes that are rejected by the routing policy are
stored in the routing table with a negative preference. A negative preference prevents a route from
being installed in the forwarding table or exported to other protocols. Handling rejected routes in this
manner alleviates the need to break and re-establish a session if routing policy changes during a
reconfiguration.
The format of the import statements for the RIP, HELLO, and redirect protocols is:
import proto rip | hello | redirect
[interface interface_list | gateway gateway_list]
[restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
};
This statement controls what routes are imported based on the source protocol, interface and gateway.
The order of precedence is from the most general (protocol) to the most specific (gateway). Unlike
BGP and EGP, these protocols do not save routes that were rejected because these protocols have
short update intervals.
The preference option is not used with RIP or HELLO. RIP and HELLO don't use preference to
choose between routes of the same protocol. They use the protocol metrics.
The format of the import statement for the OSPF protocol is:
import proto ospfase [tag ospf_tag] [restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
};
Due to the nature of OSPF, only the importation of ASE routes can be controlled. Furthermore, it is
only possible to restrict the importation of OSPF ASE routes when functioning as an AS border
router. This requires you to specify an export ospfase statement in addition to the import ospfase
file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (4 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

statement. Specify an empty export statement to control importation of ASEs when no ASEs are
being exported. (See the following section, "The export Statement.") If a tag is specified, the import
statement only applies to routes with the tag. OSPF ASE routes that are rejected by policy are stored
in the table with a negative preference.
OSPF routes are imported into the gated routing table with a preference of 10. Preference is not used
to choose between OSPF ASE routes. OSPF costs are used for that purpose.

B.10.2 The export Statement
The syntax of the export statement is similar to the syntax of the import statement and the meaning
of many of the parameters is identical. An important difference between the two statements is that
while route importation is controlled by source information, route exportation is controlled by both
source and destination. Thus export statements define where the routes will be sent and where they
originated. The destination of the route advertisement is defined by the proto clause at the beginning
of the export statement. The source of the routes is defined in the export list.
Each export statement varies slightly for each protocol. To advertise routes via EGP and BGP, use this
syntax:
export proto bgp | egp as as_number
[restrict] |
[[metric metric] {
export_list ;
}] ;
Routes are exported via EGP and BGP to the specified autonomous system. restrict blocks exports to
the AS. Valid BGP or EGP metrics can be specified. If no export list is defined, only the direct routes
of the attached interfaces are exported. If an export list is used, it must explicitly specify everything
that should be exported.
To advertise routes via RIP and HELLO, use this syntax:
export proto rip | hello
[interface interface_list | gateway gateway_list]
[restrict] |
[[metric metric] {
export_list ;
}] ;
Routes exported by RIP and HELLO are sent via the specified protocol and can be sent through a
specifc interface or to a specific gateway. Set metric if you plan to export static or internally
generated default routes. The metric option is only used when exporting non-RIP routes via RIP or
non-HELLO routes via HELLO.

file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (5 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

If no export list is specified, RIP exports direct routes and RIP routes, and HELLO exports direct
routes and HELLO routes. If an export list is used it must explicitly specify everything that should be
exported.
To advertise routes via OSPF, use this syntax:
export proto osfpase [type 1 | 2] [tag ospf_tag]
[restrict] |
[[metric metric] {
export_list ;
}] ;
Only OSPF ASE routes can be exported by gated. There are two types of OSPF ASE routes, type 1
and type 2. They are described in Chapter 7 and earlier in this appendix. The default type is specified
in the ospf protocol statement, but it can be overridden here. The ospf_tag is an arbitrary 32-bit
number used to filter routing information. The default tag value is specified in the ospf protocol
statement but it can be overridden here.
The source of the routes advertised by a protocol is defined by the export list. Each of the commands
listed above contains an export list option. Just like those commands, the export list syntax varies
depending on the source protocol of the routes. The commands described above define the protocols
that are used to advertise the routes. The export lists shown below describe the protocols from which
the routes are obtained. The biggest confusion caused by the export list syntax is that it is almost
identical to the syntax shown above. In both cases we define protocols, autonomous systems,
interfaces, gateways, and so on. In the first case we are defining the protocols, interfaces, etc., to
which routes are sent, and in this case we define the protocols, interfaces, etc., from which routes are
recieved.
To export routes learned from BGP and EGP, use this export list syntax:
export proto bgp | egp autonomoussystem as_number
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
This defines routes learned via BGP or EGP from a specific autonomous system. Routes can be
restricted, or have a metric applied, based on matching the source AS number or the route filter.
When BGP is configured, gated assigns all routes an AS path. For interior routes, the AS path
specifies igp as the origin and no autonomous systems in the AS path (the current AS is added when
the route is exported). For EGP routes, the AS path specifies egp as the origin and the source AS as
the AS path. For BGP routes, the AS path learned from BGP is used. If you run BGP, the export of all
routes may be controlled by the AS path using this syntax:

file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (6 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

proto proto | all
aspath aspath_regexp origin any | igp | egp | incomplete
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
The source of the routes can be any one protocol (proto) or all (all) protocols. The importation of
routes can be controlled by matching their AS paths against the AS path regular expression
(aspath_regexp) or by matching their addresses against the route_filter. Route filters and
AS path regular expressions are explained above.
To export routes learned from RIP and HELLO, use this export list syntax:
proto rip | hello
[interface interface_list | gateway gateway_list]
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
The export of RIP and HELLO routes may be controlled by protocol, source interface, source
gateway, or route filter.
To export routes learned from OSPF, use this export list syntax:
proto ospf | ospfase
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
The export of OSPF and OSPF ASE routes may be controlled by protocol and route filter. Exporting
OSPF routes can also be controlled by tag using the syntax shown below:
proto proto | all tag tag
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
OSPF and RIP version 2 provide a tag field. For all other protocols, the tag is always 0. Routes may
be selected based on the contents of the tag field.
There are other sources of routes that are not true routing protocols, and export lists can be defined for
file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (7 of 8) [2001-10-15 09:19:19]

[Appendix B] B.10 Control Statements

these sources. The two export lists for these sources are:
proto direct | static | kernel
[interface interface_list]
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
The export of these routes can be controlled based on the source "protocol" and the source interface.
The "protocols" in this case are routes to direct interfaces, static routes, or routes learned from the
kernel.
proto default | aggregate
[restrict] |
[[metric metric] {
route_filter [restrict | metric metric] ;
}] ;
The export of these routes may only be controlled based on source "protocol." default refers to routes
created by the gendefault option. aggregate refers to routes created by the aggregate statements, the
topic of the next section.

Previous: B.9 static
Statements
B.9 static Statements

TCP/IP Network
Administration
Book Index

Next: B.11 The Aggregate
Statements
B.11 The Aggregate
Statements

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (8 of 8) [2001-10-15 09:19:19]

[Appendix B] B.11 The Aggregate Statements

Previous: B.10 Control
Statements

Appendix B
A gated Reference

Next: C. A named
Reference

B.11 The Aggregate Statements
Route aggregation is used by regional and national networks to reduce the number of routes
advertised. With careful planning, large network providers can announce a few aggregate routes
instead of hundreds of client network routes. Enabling aggregation is the main reason that CIDR
blocks are allocated as contiguous address blocks.
Most of us don't have hundreds of routes to advertise. But we may have a classless address composed
of a few class C address and we may need to tell gated how to handle it. Older versions of gated
automatically generated an aggregate route to a natural network using the old Class A, B, and C
concept; i.e., interface address 192.168.16.1 created a route to 192.168.16.0. With the advent of
classless interdomain routing, this can be the wrong thing to do. gated does not aggregate routes
unless it is explicitly configured with the aggregate statement:
aggregate default | address [mask mask | masklen number]
[preference preference] [brief] {
proto proto
[as as_number | tag tag | aspath aspath_regexp]
[restrict] |
[[preference preference] {
route_filter [restrict | (preference preference)]] ;
};
Several options are available for the aggregate statement:
preference preference;
Defines the preference of the resulting aggregate route. The default is 130.
brief
Specifies that the AS path of the agregate route should be the longest common AS path. The
default is to build an AS path consisting of all contributing AS paths.
proto proto

file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (1 of 3) [2001-10-15 09:19:19]

[Appendix B] B.11 The Aggregate Statements

Only aggregate routes learned from the specified protocol. The value of proto may be any
currently configured protocol. This includes the "protocols" direct, static, and kernel,
discussed in the previous section; all for all possible protocols; and aggregate for other route
aggregations.
as as_number
Only aggregate routes learned from the specified autonomous system.
tag tag
Only aggregate routes with the specified tag.
aspath aspath_regexp
Only aggregate routes that match the specified AS path.
restrict
Indicates routes that are not to be aggregated.
Routes that match the route filters may contribute to the aggregate route. A route may only contribute
to an aggregate route that is more general than itself. Any given route may only contribute to one
aggregate route, but an aggregate route may contribute to a more general aggregate.
A slight variation of aggregation is the generation of a route based on the existence of certain
conditions. The most common usage for this is to create a default based on the presence of a route
from a peer on a neighboring backbone. This is done with the generate statement.
generate default | address [mask mask | masklen number]
[preference preference] {
proto proto
[as as_number | tag tag | aspath aspath_regexp]
[restrict] |
[[preference preference] {
route_filter [restrict | preference preference]] ;
};
};
The generate statement uses many of the same options as the aggregate statement. These options are
described earlier in this appendix.

Previous: B.10 Control
Statements
B.10 Control Statements

TCP/IP Network
Administration
Book Index

file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (2 of 3) [2001-10-15 09:19:19]

Next: C. A named
Reference
C. A named Reference