CCNP Route - Path control, part 2: Redistribution with Route-Maps and Distribute Lists

What happens when you match against a non-existent prefix-list? IOS matches all routes. 



Distribute-list  in RIP, EIGRP

distribute-list calls: uses an ACL? uses prefix list? allows the route filters the routewho controls
filtering action?
standard ACL yes no ACL permit deny
ip prefix listnoyesprefix-listpermitdeny
route map yes yes route-map permit deny

Syntax:
distribute-list <acl#> [ in / out ] { interface }
distribute-list prefix <prefix-list name> [ in | out]
distribute-list route-map <route-map name> [ in | out ]
Example:
Router(config)#router eigrp 10
Router(config-router)#distribute-list 1 in          ! incoming global distribute list that refers to access control list (ACL) 1
Router(config-router)#distribute-list 3 in f0/0     ! incoming distribute list for interface f0/0 and refers to ACL 3
!
Router(config-router)#distribute-list 2 out         ! outgoing global distribute list that refers to ACL 2
Router(config-router)#distribute-list 4 out s0/0    ! outgoing distribute list for interface Serial0/0/0 and refers to ACL 4
Router(config-router)#distribute-list 5 out ospf 1 ! Filters updates advertised from OSPF process ID 1 into EIGRP autonomous system 10 according to ACL 5

Verification Commands:
show access-lists
show ip access-lists
show ip prefix-list
show route-map
distribute-list IN
- Applies the access list to incoming routing updates IN RIP/EIGRP toplogy.
 - filters updates going into the interface specified
 - YOU won't know about the route and therefore won't send it to anyone else downstream.

distribute-list OUT
 - applies the access list to outgoing routing updates OUT RIP/EIGRP toplogy. 
 - filters updates going out of the interface or routing protocol specified in the command
 - the next neighbor(s) will not know about the route and therefore won't send it to anyone else downstream.

Examples:
router eigrp 2
 distribute-list 24 in      ! IN EIGRP from RIB    <- routes from EIGRP 2 topology
 distribute-list 25 out    ! OUT of EIGRP to RIB    <- routes from EIGRP 2 topology will be checked with ACL25 before entering RIB

router eigrp 1
 network 172.16.0.0
 distribute-list 7 out Serial0/0/0
!
access-list 7 permit 172.16.0.0 0.0.255.255


OSPF: just remember there is no "in" direction when you filter this way.
OSPF is special, you cannot prevent the exchange of topology information.
You can only prevent the local (on the router where you configure the filter) OSPF process from adding the route to its table.
router ospf 3
 distribute-list 24 in      ! from OSPF IN RIB      <- only filters routes from entering the routing table
 distribute-list 25 out    ! works only on the routes being redistributed by the Autonomous System Boundary Routers (ASBRs) into OSPF.

- It is important to note that routes must be in the routing table for them to be redistributed.
- EIGRP does not automatically summarize redistributed routes even with 'auto-summary'; if they are not already summarized before they are redistributed
then summarization must be configured if it is desired.
 - seed metric - default-metric command, derived from the characteristics of that interface (OSPF -  interface’s bandwidth, EIGRP - interface bandwidth and delay)

IOS can identify the routes that need to be treated differently, whether given different metrics, filtered, and assigned a different external route type.

Route-map can perform the following:
■ Identify the subset of the routes to filter or change based on the route’s prefix/length, plus many other factors.
■ Make filtering choices about which routes are redistributed, and which are not.
■ Set the metric to different values based on information matchable by the route-map.
■ Set the type of External route for different redistributed routes, for example, OSPF Type 1 for some routes, Type 2 for others.
■ Set a route tag, a unitless integer value that can later be matched with a route-map at another redistribution point.

NOTES:
 - EIGRP filters routes using the distribute-list command, which refers to either an ACL, prefix list, or route map.

 - Routes are classified either as permitted (sent or received) in an EIGRP update or denied (filtered).
 - When using a prefix-list, the route's prefix must be within the range of addresses implied by the prefix-list command's prefix/prefix-length parameters.
  - When using an ACL, in order to find the range of addresses matched by the ACLs address and wildcard mask, use the address field as the low end of the range and simply add the wildcard mask to the address to find the high end of the range.

 - When using a prefix-list, the route's prefix length must match the range of prefixes implied by the prefix-list command's prefix-length, ge, and le parameters.
 - Cisco IOS requires that the configured prefix-length, ge-value, and le-value meet the following requirements: prefix-length <= ge-value <= le-value. Otherwise, Cisco IOS rejects the ip prefix-list command.

 - When using a route-map command with the permit option, the route will either 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.
 - When using a route-map command with the deny option, the route will either be filtered (if matched by the match command) or remain in the list of routes to be examined by the next route-map 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 filtered. Instead, it means the route does not match the match command logic, resulting in the Cisco IOS to consider 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.





Overview of Using route-maps with Redistribution
The redistribute command has two mechanisms that allow filtering of routes:
■ The match{internal| external 1| external 2| nssa-external}parameters
■ The route-map <map-name>

When redistributing from OSPF, matches routes solely based on the types of routes listed (match{internal| external 1| external 2| nssa-external}
The route-map <map-name> command has many options for identifying routes by matching various facts about the route.

Route-maps use the match subcommand. The match command can refer to ACLs and prefix-lists to match anything matchable by those tools, plus match other facts more directly.
A route-map statement may contain multiple match statements.
All match statements within a route-map statement must be considered true for the route-map statement to be considered matched. (This is a logical AND operation.)
! Looks at outgoing interface of routes
match interface <interface-type> <interface-number> [... interface-type interface-number]
!
! Examines route destination prefix and prefix length
* match ip address {[<access-list-number> | <access-list-name>] | prefix-list <prefix-list-name>}
!
! Examines route’s next-hop address
* match ip next-hop {<access-list-number> | <access-list-name>}
!
! Matches advertising router’s IP address
* match ip route-source {<access-list-number> | <access-list-name>}
!
! Matches route’s metric, or a range (plus/minus the configured deviation)
match metric <metric-value> [+-deviation]
!
! Matches route type
match route-type {internal| external[type–1|type–2] | level–1 | level–2}
!
! Matches the route tag, which requires that another router has earlier set the tag
match tag <tag-value> [...tag-value]
!
! *- Can reference multiple numbered and named ACLs on a single match command.
A route-map referenced by the redistribute command always attempts to filter routes.
If the route-map matches a particular route with a particular route-map clause, and the action in that clause is permit, then the route is redistributed. 
However, if the first route-map clause matched by a packet has a deny action, the packet is filtered–in other words, not redistributed.

Additionally, for routes not filtered by the route-map, the route-map can set other values (like the route’s metric) using the apply-named set command.
!  Sets the route’s metric for OSPF, RIP, and IS-IS
set metric <metric-value>
!
!  Sets the EIGRP route’s metric values
set metric <bandwidth delay reliability loading mtu>
!
! Sets type of route for OSPF
set metric-type {type–1| type–2}
!
! Sets the unitless tag value in the route
set tag <tag-value>

Filtering Redistributed Routes with Route Maps
The general style of the two options, both of which work, is as follows:
1) match deny / permit no match
 Begin with a match of the routes to be filtered, using extended IP ACLs, with a deny action so the routes are filtered. Then use a permit clause with no match command at all, matching and allowing through all remaining routes.
2) match permit / implicit deny at the end
Begin with a match of the routes to be allowed, matching with prefix lists, with a permit action. Then use the implicit deny all at the end of the route-map to filter unwanted routes.
!         DEFINE ACLs/PREFIXEs/     
ip access-list extended match-101
     permit ip host 172.16.101.0 host 255.255.255.0
!
ip access-list extended match-104-105
     permit ip host 172.16.104.0 host 255.255.255.224
     permit ip host 172.16.105.0 host 255.255.255.240
!
ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30
ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30
!
ip prefix-list match-area3-permit seq 5 permit 172.16.102.0/23 ge 25 le 26
!
!         OPTION-1   DENY-PERMIT     
route-map option1 deny 10
   match ip address match-101
route-map option1 deny 20
     match ip address match-104-105
route-map option1 permit 100
!
!         OPTION-2   PERMIT-DENY     
route-map option2 permit 10
     match ip address prefix-list match-area3-permit
!
route-map option2 permit 20
     match ip address prefix-list match-area0-permit
!
!         APPLY ROUTER CONFIG     
router eigrp 1
  redistribute ospf 2 route-map option1

Verifying Redistribution Filtering Operations
show ip eigrp topology | include 172[.]16
tell IOS to treat the period as a literal, searching for the text “172.16” in the command output, instead of treating the period as a wildcard in an IOS regular expression.
show access-list
show ip prefix-list detail match-area-0-permit
  ip prefix-list match-area0-permit:
    count: 5, range entries: 0, sequences: 5 - 25, refcount: 3
    seq 5 permit 172.16.14.0/30 (hit count: 6, refcount: 1)
    seq 10 permit 172.16.18.0/30 (hit count: 5, refcount: 1)
Route-map to Set Metrics
ip prefix-list match-102-103 seq 5 permit 172.16.102.0/23 ge 25 le 26

route-map set-metric permit 10
 match ip address prefix-list match-area0-permit
!
route-map set-metric permit 20
match ip address prefix-list match-102-103
set metric 1000 44 255 1 1500
!
route-map set-metric permit 30
match ip address prefix-list match-106-107
set metric 100 4444 255 1 1500
!
router eigrp 1
   default-metric 1500 10 255 1 1500
   redistribute ospf 2 route-map set-metric
Verify
D1#show ip eigrp topology 172.16.104.0/25
% IP-EIGRP (AS 1): Route not in topology table
RD1#show ip eigrp topo 172.16.106.0/29
Minimum bandwidth is 100 Kbit
Total delay is 44440 microseconds
RD1#show ip prefix-list detail match-102-103
seq 5 permit 172.16.102.0/23 ge 25 le 26 (hit count: 14, refcount: 1)

Setting the External Route Type
When redistributing into OSPF, IOS automatically sets the external route type to external Type 2 (E2).
When redistributing into OSPF, IOS can set the type to E1 or E2 by using the set metric-type {type-1 | type-2} route-map subcommand.

Distribute Lists
Another way to control routing updates is to use a distribute list. A distribute list allows an access list to be applied to routing updates.
ACLs are usually associated with interfaces (and user traffic -data plane), rather than routing protocol traffic (or other control plane traffic).
Route information can be obtained through route redistribution, which does not involve a specific interface.
In addition, ACLs do not affect traffic originated by the router, so applying one on an interface has no effect on outgoing routing advertisements.
However, when you configure an access list and use it with a distribute list, routing updates can be controlled, no matter what their source is.

 - ACLs are configured in global configuration mode; the associated distribute list is configured under the routing protocol process.
 - ACL should permit the networks that you want advertised or redistributed and deny the networks that you want to remain hidden.
 - distribute-list command allow updates to be filtered based on factors including the following:
   ■ Incoming/Outgoing interface
   ■ Redistribution from another routing protocol
router <routing protocol>
! filter outgoing routing updates
distribute-list {access-list-number| name} out [interface-name|routing-process [routing-process parameter]]
      [interface-name|routing-process [routing-process parameter]] - are optional

! filter routing updates coming
distribute-list [access-list-number| name] | [route-map map-tag] in [interface-type interface-number]

It is important to understand the differences between these commands:
■ The distribute-list out filters updates going out of the interface or routing protocol specified in the command,into the routing process under which it is configured.
distribute-list ACL out [interface] - apply filter exitinig interfaces
distribute-list ACL out eigrp 1 = distribute-list ACL from eigrp 1   (apply filtering on updates coming IN from eigrp 1)

■ The distribute-list in command filters updates going into the interface specified in the command, into the routing process under which it is configured.

EIGRP (and RIP) IN
EIGRP process 1 is configured to accept two networks—network 0.0.0.0 and network 10.108.0.0:
access-list 1 permit 0.0.0.0
access-list 1 permit 10.108.0.0
access-list 1 deny 0.0.0.0 255.255.255.255
router eigrp 1
 network 10.108.0.0
 distribute-list 1 in        <-  check routes comings to EIGRP topology, from RIB, with ACL nr. '1'
EIGRP (RIP) OUT
Only one network to be advertised by a RIP routing process, network 10.108.0.0
access-list 1 permit 10.108.0.0
access-list 1 deny 0.0.0.0 255.255.255.255
router rip
 network 10.108.0.0
 distribute-list 1 out


OSPF IN
The distribute-list in command only filters routes from entering the routing table
All OSPF external prefixes that have the tag value of 777 are filtered (prevented from being installed in the routing table).
The permit statement with sequence number 20 has no match conditions, and there are no other route-map statements after sequence number 20, so all other conditions are permitted.
route-map tag-filter deny 10
 match tag 777
route-map tag-filter permit 20
!
router ospf 1
 distribute-list route-map tag-filter in
OSPF OUT
OSPF routes cannot be filtered from entering the OSPF database.
OSPF distribute-list out only works on the routes being redistributed by ASBR into OSPF.
It can be applied to external type 2 and type 1 routes, but not to intra-area and interarea routes..
R3# show ip route | inc O
O E2       10.2.2.0  [110/20]  via 10.1.23.2, 00:50:01, Serial 0/0
O E2       11.1.1.0  [110/20]  via 10.1.23.2, 00:50:01, Serial 0/0
!
access-list 11 deny 11.1.1.10
access-list 11 permit any
router ospf 2
distribute-list 11 out
!
R3# show ip route | inc O
O E2       10.2.2.0  [110/20]  via 10.1.23.2, 00:50:01, Serial 0/0
O E2       11.1.1.0  [110/20]  via 10.1.23.2, 00:50:01, Serial 0/0
!



Because OSPF routers within the same area must have the same LSDB, LSA filtering for OSPF can be done only between areas.
Distribute-list out command cannot be used with OSPF to block outbound LSAs on an interface.
For OSPF, this command works only on the routes being redistributed by ASBRs into OSPF (can be applied only to O E1/E2, but not to O/O_IA).

distribute-list in command prevents most routing protocols from placing the filtered routes in their database. 
OSPF routes cannot be filtered from entering the OSPF LSDB (the routes are still placed in the LSDB; they are only filtered from entering the routing table.)

Using distribute lists as route filters has several drawbacks, including the following:
■ A subnet mask cannot be easily matched.
■ Access lists are evaluated sequentially for every IP prefix in the routing update.
■ An extended access list can be cumbersome to configure.

Redistribution Filtering with the distribute-list Command
IOS supports a second style of route filtering configuration using the distribute-list command.
Command must use the out direction, and it must refer to the routing process from which routes are redistributed.
- show ip access-list
- show ip prefix-list detail

Prefix Lists
Prefix lists can be used as an alternative to access lists in many route filtering commands.
The advantages of using prefix lists include the following:
■  A significant performance improvement over access lists in loading and route lookup of large lists. The router transforms the prefix list into a tree structure, with each branch of the tree representing a test, allowing the Cisco IOS Software to determine whether to permit or deny much faster.
■ Support for incremental modifications. Compared to a traditional access list in which one nocommand erases the whole access list, prefix list entries can be modified incrementally. You can assign a sequence number to each line of a prefix list; You can also remove individual lines without removing the entire list.
A more user-friendly command-line interface. The command-line interface for using extended access lists to filter updates is difficult to understand and use.
■ Greater flexibility.Prefix list can specify the size of the subnet mask, or that the subnet mask must be in a specified range.

Prefix lists have several similarities to access lists:
 - A prefix list can consist of any number of lines, each of which indicates a test and a result.
 - When a router evaluates a route against the prefix list, the first line that matches results in either a permit or deny.
 - If none of the lines in the list match, the result is “implicitly deny,” just as it is in an access list.

Whether a prefix is permitted or denied is based on the following rules:
■ An empty prefix list permits all prefixes.
■ If a prefix is permitted, the route is used. If a prefix is denied, the route is not used.
■ Prefix lists consist of statements with sequence numbers. The router begins the search for a match at the top of the prefix list, which is the statement with the lowest sequence number.
■ When a match occurs, the router does not need to go through the rest of the prefix list. For efficiency, you might want to put the most common matches (permits or
denies) near the top of the list by specifying a lower sequence number.
■ An implicit deny is assumed if a given prefix does not match any entries in a prefix list.
ip prefix-list {list-name| list-number} [seq <seq-value>] {deny| permit} network/length[ge <ge-value>] [le <le-value>]
Default sequence numbers are in increments of 5 (5, 10, 15, and so on).
The network is a 32-bit address. The length is a decimal number.
length < ge-value < le-value <= 32
An exact match is assumed when neither ge nor le is specified.

no ip prefix-list <list-name>
no ip prefix-list <list-name> description <text>

ip prefix-list FILTER172ALLOW permit 172.0.0.0/8 ge 17 le 24
 For best performance, the most frequently processed prefix list statements should be configured with the lowest sequence numbers.
ip prefix-list DEFAULT ONLY 0.0.0.0/0 - means match all prefixes. Only a default route matches this prefix list.
ip prefix-list ANY32-ROUTE 0.0.0.0/0 ge 32 - any route with a /32 prefix matches this list
ip prefix-list ANY-ROUTE 0.0.0.0/0 le 32 - any prefix length between 0 and 32, inclusive, matches. Thus, this prefix list matches all routes.
ip prefix-list INET 0.0.0.0/1 le 24 - any route with a prefix between /1 and /24 matches this list.

Commands Used to Verify Prefix Lists
show ip prefix-list [detail | summary]
show ip prefix-list [detail | summary] <prefix-list-name>
show ip prefix-list [detail | summary] <prefix-list-name> [network/length]
show ip prefix-list [detail | summary] <prefix-list-name> [network/length]  longer
show ip prefix-list [detail | summary] <prefix-list-name> [network/length]  first-match
show ip prefix-list [detail | summary] <prefix-list-name> [seq <sequence-number>]
clearip prefix-list [detail | summary] <prefix-list-name> [network/length]      - clear counters


Issues with Multiple Redistribution Points
The redistributing with a single router could simply fail, or interfaces or links on that router could fail.
To avoid that single point of failure, most redistribution designs call for a minimum of two routers performing redistribution

The existence of two or more redistribution points between the same two routing domains introduces some complexity and caveats.

"Domain loop" - Routing loop, caused by redistribution

The problem occurs when the twice-redistributed route for subnet X is redistributed back into the original domain with a relatively low metric.
 “domain loop” problem appears when using multiple redistribution points (with different routing protocols, eg OSPF and RIP).

Preventing Routing Domain Loops
1) Preventing Routing Domain Loops - with Higher Metrics (on redistribution points).
Note that OSPF actually defeats the domain loop problem without using the higher metrics.
OSPF always prefers internal routes over E1 routes, and E1 routes over E2 routes, before even considering the metrics.

2) Preventing Routing Domain Loops with Administrative Distance
When a router must consider multiple routes from different sources for the exact same prefix/length, the first item considered by the router is not the metric, but rather the AD. The lower the AD, the better the route.

Default Administrative Distances
Route Type            Administrative Distance
Connected               0
Static                  1
EIGRP summary route     5
eBGP                    20
EIGRP (internal)        90
IGRP                    100
OSPF                    110
IS-IS                   115
RIP                     120
On-Demand Routing (ODR) 160
EIGRP (external)        170
iBGP                    200
Unreachable             255

EIGRP Default AD Defeats Loop from EIGRP to OSPF to EIGRP
Same prefix will have:
- lower AD with internal EIGRP (AD=90)
- higher AD (110), redistributed EIGRP in OSPF, and than again from OSPF to EIGRP.
- with lower AD route in routing table, the higher AD route will NOT be added to routing table, preventing route loops.

A route must be in the routing table before it can be redistributed.

EIGRP Default AD Defeats Loop from OSPF to EIGRP to OSPF

OSPF, advertised into EIGRP, and then advertised back into OSPF.
 When comparing EIGRP’s and OSPF’s defaults, both of the generic criteria are met:
■ EIGRP internal AD 90 < OSPF external AD 110
■ OSPF internal AD 110 < EIGRP external AD 170

Likewise, when redistributing between EIGRP and RIP:
■ EIGRP internal AD 90 < RIP external AD 120
■ RIP internal AD 120 < EIGRP external AD 170

When redistributing between OSPF and RIP, the default AD settings do not defeat the domain loop problem.
However, IOS supports the definition of different AD settings for all routing protocols.
RIP, which does not have a concept of internal and external routes, can only be set with a single AD value.

Routing Protocol     Command
RIP               distance ad-value
EIGRP             distance eigrp internal-ad external-ad
OSPF              distance ospf {external ad-value} {intra-area ad-value} {inter-area ad-value}
To defeat the OSPF-RIP domain loop problem by setting AD:
■ RIP internal AD 120 < OSPF external AD 130
■ OSPF internal AD 110 < RIP external AD 120

Domain Loop Problems with More than Two Routing Domains

Setting metrics and AD values does not always solve the domain loop problem.
 R4 (black label) may have a better EIGRP metric through RD2, depending on the metrics used at redistribution

1) Using Per-route Administrative Distance Settings
distance <distance> ip-adv-router wc-mask [acl-number-or-name]
! example
distance 171  1.1.1.1    0.0.0.0    match-172-20
!
ip access-list standard match-172-20
  permit host 172.20.0.0
A complete solution requires all redistributing routers to perform this kind of configuration, for all such routes from the third routing domain.

2) Preventing Domain Loops by Filtering on Subnet While Redistributing
The next tool prevents domain loops by filtering the routes based on prefix.
Setting the AD for OSPF external routes to something larger than EIGRP’s external AD of 170 would prevent this particular problem as well.

3) Preventing Domain Loops by Filtering on route-tag Using Distribute Lists
Route tags - has a much broader use than just preventing redistribution problems.

A route tag is a unitless 32-bit integer that most routing protocols can assign to any given route. That tag follows the route advertisement, even through the redistribution process. At some later point in the flooding of routing information, other IOS tools, typically other route-maps, can match routes with a given route tag to make a decision.

To use route tags to prevent domain loop problems, you can use the following strategy:
■ Choose and set a tag value that identifies routes taken from domain X and advertised into domain Y.
■ When redistributing in the opposite direction (from domain Y into domain X), match the tag value and filter routes with that tag.

!   ROUTES ENTRY AND TAGGED
router ospf 2
  router-id 3.3.3.3
  log-adjacency-changes
  redistribute eigrp 1 subnets route-map set-tag-11
route-map set-tag-11 permit 10
  set tag 11
!
!    ROUTES EXIT WITH TAG  BLOCKING
router eigrp 1
   redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-11
   network 172.16.0.0
   no auto-summary
!
route-map stop-tag-11 deny 10
  match tag 11
!
route-map stop-tag-11 permit 20
!