Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Does a router in a branch office need to be able to forward packets to hosts in another
branch office? Does a router in the sales division need to be able to forward packets to
hosts in the manufacturing division? These questions are just a sampling of design questions
for which route filtering can be part of the solution.
Route filtering allows the engineer to filter which routes are advertised in an EIGRP update.
If routers in a branch do not need to learn routes about subnets in other branches,
routers can filter that routing information. This filtering reduces the size of routing tables,
saving memory, possibly improving routing performance, and makes the internetwork
more secure by limiting the flow of packets.
EIGRP enables route filtering using the distribute-list router subcommand. The concept is
relatively straightforward: The distribute list refers to either an access control list (ACL),
prefix list, or route map. These three tools classify whether a route should be permitted to
be sent/received in an EIGRP Update or be denied (filtered). The distribute-list command
also specifies the direction–outbound updates or inbound updates–and optionally, the
specific interface on which to filter updates.
For example, Figure 4-1 shows an expanded version of the internetwork used frequently
in the previous two chapters. The figure adds several links between the WAN routers and
some core Layer 3 switches. It also notes the address ranges for all data centers
(10.16.0.0/16) and the range of addresses used for subnets in the manufacturing division
(10.17.32.0/19).
The design engineer could make many choices about what routes to filter, for example:
■ Filter routes to WAN subnets so that the core and manufacturing do not learn those
routes, because these subnets should not be the destination of any user traffic.
■ Filter manufacturing routes from being advertised to the branches, because the
branches are in the sales division.
■ Filter routes for the subnets sitting between the Layer 3 switches in the core, preventing
them from being advertised to either manufacturing or the sales branches, because
no users in these divisions should be sending packets to these subnets.
The examples in this chapter focus on the first of these design options.
Filtering the subnets that exist between Layer 3 devices, as is suggested in the second and
third items in the list, have both pros and cons. For example, the second design goal filters
the WAN subnets, because no end users need to be able to send packets to those subnets.
This meets the goal of having smaller routing tables. However, operations personnel may
have a larger challenge when monitoring and troubleshooting, because when a ping or
traceroute fails, they also need to figure out whether the command failed by design due
to the purposefully filtered routes, or whether a problem has occurred.
Filtering by Referencing IP Prefix Lists
The IOS IP prefix-list feature gives the network engineer another tool for matching routes
when performing route filtering. IP prefix lists can examine both the prefix and the prefix
length, and a range of prefixes or a range of prefix lengths. The command then sets either
a deny or permit action for each matched prefix/length. To use the prefix-list, the configuration
simply refers to the prefix-list with the same distribute-list command seen earlier.
Using IP prefix lists for route filtering has several advantages. First, IP prefix lists allow
matching of the prefix length, whereas the ACLs used by the EIGRP distribute-list command
cannot. (Some other route filtering configurations can match both the prefix and
prefix length using extended ACLs.) Many people find IP prefix lists more intuitive for
configuring route filtering. Finally, the internal processing of the IP prefix lists uses an internal
tree structure that results in faster matching of routes as compared with ACLs.
This section begins by examining IP prefix lists as an end to itself, followed by an example
of filtering EIGRP routes using a prefix list.
IP Prefix List Concepts
IP prefix lists provide mechanisms to match two components of an IP route:
■ The route prefix (the subnet number)
■ The prefix length (the subnet mask)
Each single IP prefix list has similar characteristics to a single ACL, with subtle similarities
to both numbered and named ACLs. The IP prefix list consists of one or more global configuration
commands (like numbered ACLs), with commands using the same name being
in the same list (like named ACLs). As with named ACLs, each ip prefix-list command has
a sequence number to allow later deletion of individual commands and insertion of commands
into a particular sequence position. Each command has a permit or deny action—
but because it is used only for matching routes, and not for packet filtering, the permit or
deny keyword just implies whether a route is matched (permit) or not (deny).
www.CareerCert.info
106 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
Table 4-3 LE and GE Parameters on IP Prefix List, and the Implied Range of Prefix
Lengths
Prefix List Parameter Range of Prefix Length
Neither conf-length must = route-length
Both ge and le ge-value <= route-length <= le-value
Only le conf-length <= route-length <= le-value
Only ge ge-value <= route-length <= 32
The generic command syntax is as follows:
ip prefix-list list-name [seq seq-value] {deny | permit prefix/prefixlength}[
ge ge-value] [le le-value]
The following statements summarize the logic:
Step 1. The route’s prefix must be within the range of addresses implied by the prefixlist
command’s prefix/prefix-length parameters.
Step 2. The route’s prefix length must match the range of prefixes implied by the
prefix-list command’s prefix-length, ge, and le parameters.
The matching of the prefix works much like the ACL matching logic. The configured prefix/
prefix-length implies a range of IP addresses. For example, an ip prefix-list barney
deny 10.0.0.0/8... implies any number whose first 8 bits (per the /8) match 10.0.0.0–in
other words, all IPv4 addresses that begin with 10. Any route whose prefix is in this
range–for example, 10.0.0.0, 10.1.1.0, and 10.5.255.128—would be considered to match this
part of the logic.
However, IP prefix lists always examine the prefix length as well. To perform the logic of
matching a route’s prefix length, IOS considers the following parts of the ip prefix-list
command:
■ The required prefix-length parameter
■ The optional ge-value, which stand for greater-than-or-equal-to
■ The optional le-value, which stand for less-than-or-equal-to
For a given ip prefix-list command, one of four configuration combinations affect the
logic of matching prefix lengths, as listed in Table 4-3. The text following the table provides
a more detailed explanation as compared with the summarized information in the table.
The first case in the table occurs when neither ge nor le is configured. In that case, an exact
match of prefix-length must occur between the configured prefix length and a route’s
prefix length. For example, the command ip prefix-list fred deny 10.0.0.0/8 matches
route 10.0.0.0/8, but not 10.0.0.0/20.
The second case in the table occurs when both ge and le are configured. In that case, the
route’s prefix length must be between the configured ge and le values, inclusive. For in-
Key
Topic
www.CareerCert.info
Chapter 4: EIGRP Route Summarization and Filtering 107
stance, ip prefix-list fred deny 10.0.0.0/8 ge 20 le 22 matches route 10.0.0.0/20, but not
10.0.0.0/8, because the prefix length must either be 20, 21, or 22.
The cases in which either ge or le is configured, but not both, requires a little more
thought. A visual representation can help, as shown in Figure 4-3.
In short, with only ge configured, the command matches prefix-length ranges from the gevalue
up to 32 (the longest IPv4 prefix length), inclusive. With only le configured, the
command matches prefix-length ranges between the prefix-length parameter and the levalue,
inclusive.
Note: IOS requires that the configured prefix-length, ge-value, and le-value meet the following
requirement: prefix-length <= ge-value <= le-value. Otherwise, IOS rejects the ip
prefix-list command.
Samples of Prefix List Matching
Several examples can really help nail down prefix list logic. The following routes will be
examined by a variety of prefix lists, with the routes numbered for easier reference:
Step 1. 10.0.0.0/8
Step 2. 10.128.0.0/9
Step 3. 10.1.1.0/24
Step 4. 10.1.2.0/24
Step 5. 10.128.10.4/30
Step 6. 10.128.10.8/30
Next, Table 4-4 shows the results of seven different one-line prefix lists applied to these
six example routes. The table lists the matching parameters in the prefix-list commands,
0 32
ip prefix-list prefix / prefix-length ge ge-value le le-value
neither ge
nor le configured
(exact)
Both ge and
le Configured
Only ge Configured
Only le Configured
Figure 4-3 Representation of Prefix Length Ranges for ip prefix-list Command
www.CareerCert.info
108 CCNP ROUTE 642-902 Official Certification Guide
Table 4-4 Example Prefix Lists Applied to the List of Routes
prefix-list
Command
Parameter
Routes Matched from
previous list of prefixes
Result
10.0.0.0/8 1 Without ge or le configured, both the
prefix (10.0.0.0) and length (8) must be
an exact match.
10.128.0.0/9 2 Without ge or le configured, the prefix
(10.128.0.0) and length (9) must be an
exact match.
10.0.0.0/8 ge 9 2–6 The 10.0.0.0/8 means “all routes whose
first octet is 10.” The prefix length must
be between 9 and 32, inclusive.
10.0.0.0/8 ge 24 le
24
3, 4 The 10.0.0.0/8 means “all routes whose
first octet is 10,” and the prefix range is
24 to 24—meaning only routes with
prefix length 24.
10.0.0.0/8 le 28 1–4 The prefix length needs to be between
8 and 28, inclusive.
0.0.0.0/0 None 0.0.0.0/0 means “match all prefixes.”
However, because no le nor ge parameter
is configured, the /0 also means that
the prefix length must be 0. So, it would
match all routes’ prefixes, but none of
their prefix lengths. Only a default
route would match this prefix list.
0.0.0.0/0 le 32 All The range implied by 0.0.0.0/0 is all IPv4
addresses. The le 32 combined with
prefix length 0 implies any prefix length
between 0 and 32, inclusive. This is the
syntax for “match all” prefix list logic.
omitting the first part of the commands. The table explains which of the six routes would
match the listed prefix list, and why.
Note: Pay particular attention to the match all logic of the final entry in the table.
www.CareerCert.info
Chapter 4: EIGRP Route Summarization and Filtering 109
Using IP Prefix Lists to Filter EIGRP Routes
After you master the logic behind IP prefix lists, using them with the distribute-list command
requires minimal extra effort. For example, to refer to a prefix list name Fred, you
could configure the distribute-list prefix Fred... command, instead of distribute-list 2...
to refer to ACL 2. (Note that the prefix list names are case-sensitive.)
For example, using the internetwork of Figure 4-1 and Figure 4-2 again, consider the following
revised design requirements for route filtering:
■ Of the routes from manufacturing, filter only those routes that begin with 10.17.35
and 10.17.36.
■ Of the routes for subnets on the WAN link, filter routes to prevent the core routers
and branch routers from learning routes whose prefix length is /30.
Although the first of the preceding two requirements mainly exists to demonstrate the ip
prefix-list command, the second goal may be more useful for real networks. Often, routes
with a /30 prefix length are routes used between two routers, either on WAN links or over
LANs between Layer 3-enabled devices. Users should not need to send packets to addresses
in these subnets. So, the only need to have routes to these subnets is for network
management (ping tests, for instance).
Example 4-2 shows the configuration on WAN1; the equivalent configuration has been
added on WAN2 as well.
The configuration on WAN1 includes a four-line prefix list. The first line (sequence number
5) matches 10.17.35.0/25 and 10.17.35.128/25, in part because it asks for a range of prefix
lengths from 25 to 25–meaning an exact length of 25. Similarly, the second statement
(sequence number 10) matches routes 10.17.36.0/26 and 10.17.36.64/26. The third statement
(sequence number 15) uses wildcard logic (0.0.0.0/0) to match all prefixes, but only
those with prefix length 30 (ge 30 le 30). The last command matches all prefixes, with
prefix lengths from 0 to 32 (all prefix lengths).
The resulting IP routing table on branch Router B1 shows only a small number of routes.
B1 has a route to the other example branch’s subnet (10.12.1.0), and another in the range of
addresses for the data centers (10.16.1.0/24). It has the two routes leaked from manufacturing.
Note that the only two /30 routes known on B1 are two connected routes, so the
distribute-list is filtering all the /30 routes.
Filtering by Using Route Maps
Route maps, the third EIGRP route filtering tool that can be referenced with the
distribute-list command, provides programming logic similar to the If/Then/Else logic
seen in programming languages. A single route map has one or more route-map commands
in it, and routers process route-map commands in sequential order based on sequence
numbers. Each route-map command has underlying matching parameters,
configured with the aptly named match command. (To match all packets, the route-map
clause simply omits the match command.)
www.CareerCert.info
Chapter 4: EIGRP Route Summarization and Filtering 111
Route maps can be used for many functions besides being used to filter routes for a single
routing protocol like EIGRP. Route maps can be used to filter routes during the route redistribution
process, and to set BGP Path Attributes (PAs) for the purpose of influencing
the choice of the best routes in an internetwork.
When used for filtering EIGRP routes, route maps do provide a few additional features beyond
what can be configured using ACLs and prefix lists. However, route maps can be
tricky to understand and sometimes counterintuitive. This section begins with an examination
of the concepts behind IOS route maps, followed by some examples of their use
for filtering EIGRP routes.
Route Map Concepts
Route maps have many similarities when compared to ACLs and prefix lists. A single route
map has several route-map commands, with the commands in the same route map all having
the same text name. When referenced by the distribute-list command, IOS processes
the commands in the route map sequentially, based on the sequence numbers in the commands.
Like ACLs and prefix lists, IOS adds the sequence numbers automatically if omitted
when configuring the route-map commands. And once a particular route has been
matched and determined to be either filtered (deny) or allowed to pass (permit), even if
more route-map commands exist later in the list, IOS stops processing the route-map for
that route.
Each route-map command includes the name of the route map, an action (permit or
deny), and possibly a sequence number (optional). After typing this command, the CLI
user is in route-map configuration mode for that route-map clause. Any match commands
configured in that mode apply to that single route-map command. For instance, Example
4-3 shows the configuration of a sample route map on router WAN1.
Example 4-3 Pseudocode for Route Map Used as EIGRP Route Filter
route-map sample-rm deny 8
match (1st set of criteria)
route-map sample-rm permit 17
match (2nd set of criteria)
route-map sample-rm deny 30
match (3rd set of criteria)
route-map sample-rm permit 35
!
router eigrp 1
distribute-list route-map sample-rm out
Example 4-3 shows pseudocode, ignoring the specifics of what is matched with the match
commands. Focus on the actions in the route-map command (permit or deny), and the
overall logic, as listed here:
■ Seq #8: The action is deny, so discard or filter all routes matched by the match command
(1st set of criteria).
www.CareerCert.info
112 CCNP ROUTE 642-902 Official Certification Guide
■ Seq #17: The action is permit, so allow through all routes matched by the match
command (2nd set of criteria).
■ Seq #30: The action is deny, so discard or filter all routes matched by the match
command (3rd set of criteria).
■ Seq #35: The action is permit. The absence of a match command means “match all,”
so allow through all remaining routes.
The match command can reference an ACL or prefix list, but doing so does introduce the
possibility of confusion. The confusing part is that the decision to filter a route or allow
the route through is based on the deny or permit in the route-map command, and not the
deny or permit in the ACL or prefix list. When referencing an ACL or prefix list from a
route map, the ACL or prefix list simply matches all routes permitted by the ACL or prefix
list. Routes that are denied by the ACL or prefix list simply do not match that match command’s
logic, making IOS then consider the next route-map command.
The following list summarizes the key points about route map logic when used for redistribution:
■ route-map commands with the permit option either cause a route to be allowed
through (if matched by the match command) or remain in the list of routes to be examined
by the next route-map clause.
■ route-map commands with the deny option either filter the route (if matched by the
match command) or remain in the list of routes to be examined by the next routemap
clause.
■ If a clause’s match commands refer to an ACL or prefix list, and the ACL or prefix list
matches a route with the deny action, the route is not necessarily filtered. Instead, it
just means that route does not match that particular match command and can then be
considered by the next route-map clause.
■ The route-map command includes an implied deny all clause at the end; to configure
a permit all, use the route-map command, with a permit action, but without a match
command.
Route maps have several more options on the match command as compared to what can
be examined by ACLs and IP prefix lists. However, for the purposes of EIGRP route filtering,
the items that may be matched do not provide significant help in filtering routes.
However, when redistributing routes from other routing protocols, as is covered in
Chapter 9, “Basic IGP Redistribution,” and Chapter 10, “Advanced IGP Redistribution,”
some of the match command’s other options can be very helpful.
Using Route Maps to Filter EIGRP Routes
The mechanics of the configuration works much like the other two filtering features. The
distribute-list command refers to the feature that matches the packets, in this case a
route-map command option. The distribute-list command again lists a direction (in or
out), and optionally an interface.
Example 4-4 shows the configuration results in an excerpt from the show running-config
command, along with the output of the show route-map command. The configuration im-
Key
Topic
www.CareerCert.info
Chapter 4: EIGRP Route Summarization and Filtering 113
plements the same logic as used in Example 4-2 earlier in this chapter, under the heading
“Using IP Prefix Lists to Filter EIGRP Routes.” The design criteria are the same as with
that earlier example:
■ Of the routes from manufacturing, filter only those routes that begin with 10.17.35
and 10.17.36.
■ Filter WAN routers from advertising any /30 routes in the Layer 3 core.
Example 4-4 Filtering All Routes with a /30 Prefix Length, Plus Some Routes from
Manufacturing
! On Router WAN1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WAN2#show running-config
! lines omitted for brevity
router eigrp 1
network 10.0.0.0
distribute-list route-map filter-man-slash30 out
auto-summary
!
ip prefix-list manufacturing seq 5 permit 10.17.35.0/24 ge 25 le 25
ip prefix-list manufacturing seq 10 permit 10.17.36.0/24 ge 26 le 26
!
ip prefix-list slash30 seq 5 permit 0.0.0.0/0 ge 30 le 30
!
route-map filter-man-slash30 deny 8
match ip address prefix-list manufacturing
!
route-map filter-man-slash30 deny 15
match ip address prefix-list slash30
!
route-map filter-man-slash30 permit 23
! Notice – no match commands, so the above clause matches all remaining routes
!
! lines omitted for brevity
WAN2#show route-map
route-map filter-man-slash30, deny, sequence 8
Match clauses:
ip address prefix-lists: manufacturing
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-man-slash30, deny, sequence 15
Match clauses:
ip address prefix-lists: slash30
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-man-slash30, permit, sequence 23
www.CareerCert.info
114 CCNP ROUTE 642-902 Official Certification Guide
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
In particular, note that the first two route-map commands list a deny action, meaning that
all routes matched in these two clauses will be filtered. The IP prefix lists referenced in the
match commands, called manufacturing and slash30, respectively, each match (permit)
the routes listed in one of the two design goals. Note that the logic of both prefix lists
could have easily been configured into a single prefix list, reducing the length of the
route-map command as well. Finally, note that the last route-map command has a permit
action, with no match command, meaning that the default action is to allow the route to
be advertised.
Also, it can be useful to take a moment and review Example 4-2 as a point of comparison
for the use of the IP prefix lists in each case. In the route-map of Example 4-4, the prefix
list needs to match the routes with a permit clause so that the route-map deny action
causes the routes to be filtered. Earlier, Example 4-2 shows the same basic logic in the prefix
list, but with an action of deny. The reasoning is that when the distribute-list prefixlist...
command refers directly to an IP prefix list, IOS then filters routes denied by the
prefix list.
No comments:
Post a Comment