Specifications
Implementing EIGRP on Cisco IOS XR Software
Information About Implementing EIGRP on Cisco IOS XR Software
RC-144
Cisco IOS XR Routing Configuration Guide
The stub routing feature by itself does not prevent routes from being advertised to the remote router. In
the example in Figure 13, the remote router can access the corporate network and the Internet through
the distribution router only. Having a full route table on the remote router, in this example, would serve
no functional purpose because the path to the corporate network and the Internet would always be
through the distribution router. The larger route table would only reduce the amount of memory required
by the remote router. Bandwidth and memory can be conserved by summarizing and filtering routes in
the distribution router. The remote router need not receive routes that have been learned from other
networks because the remote router must send all nonlocal traffic, regardless of destination, to the
distribution router. If a true stub network is desired, the distribution router should be configured to send
only a default route to the remote router. The EIGRP Stub Routing feature does not automatically enable
summarization on the distribution router. In most cases, the network administrator needs to configure
summarization on the distribution routers.
Without the stub feature, even after the routes that are sent from the distribution router to the remote
router have been filtered or summarized, a problem might occur. If a route is lost somewhere in the
corporate network, EIGRP could send a query to the distribution router, which in turn sends a query to
the remote router even if routes are being summarized. If there is a problem communicating over the
WAN link between the distribution router and the remote router, an EIGRP stuck in active (SIA)
condition could occur and cause instability elsewhere in the network. The EIGRP Stub Routing feature
allows a network administrator to prevent queries from being sent to the remote router.
Route Policy Options for an EIGRP Process
Route policies comprise series of statements and expressions that are bracketed with the route-policy
and end-policy keywords. Rather than a collection of individual commands (one for each line), the
statements within a route policy have context relative to each other. Thus, instead of each line being an
individual command, each policy or set is an independent configuration object that can be used, entered,
and manipulated as a unit.
Each line of a policy configuration is a logical subunit. At least one new line must follow the then, else,
and end-policy keywords. A new line must also follow the closing parenthesis of a parameter list and
the name string in a reference to an AS path set, community set, extended community set, or prefix set
(in the EIGRP context). At least one new line must precede the definition of a route policy or prefix set.
A new line must appear at the end of a logical unit of policy expression and may not appear anywhere
else.
This is the command to set the EIGRP metric in a route policy:
RP/0/RP0/CPU0:router(config-rpl)# set eigrp-metric
bandwidth
delay
reliability
loading
mtu
This is the command to provide EIGRP offset list functionality in a route policy:
RP/0/RP0/CPU0:router(config-rpl)# add eigrp-metric
bandwidth delay reliability loading mtu
A route policy can be used in EIGRP only if all the statements are applicable to the particular EIGRP
attach point. The following commands accept a route policy:
• default-information allowed—Match statements are allowed for destination. No set statements are
allowed.
• route-policy—Match statements are allowed for destination, next hop, and tag. Set statements are
allowed for eigrp-metric and tag.
• redistribute—Match statements are allowed for destination, next hop, source-protocol, tag and
route-type. Set statements are allowed for eigrp-metric and tag.
The range for setting a tag is 0 to 255 for internal routes and 0 to 4294967295 for external routes.