Controlling Routing Update Traffic
Routing updates compete with user data for bandwidth and router resources, yet routing updates are critical because they carry the information that routers need to make sound routing decisions. To ensure that the network operates efficiently, you must control and tune routing updates. Information about networks must be sent where it is needed and filtered from where it is not needed. No one type of route filter is appropriate for every situation. Therefore, the more techniques you have at your disposal, the better your chance of having a smooth, well-run network.
This section discusses controlling the updates sent and received by dynamic routing protocols and controlling the routes redistributed into routing protocols. In many cases, you do not want to prevent all routing information from being advertised; you might want to block the advertisement of only certain routes. For example, you could use such a solution to prevent routing loops when implementing two-way route redistribution with dual redistribution points. The following are some ways to control or prevent dynamic routing updates from being generated:
-
Passive interface— A passive interface prevents routing updates for the specified protocol from being sent through an interface.
-
Default routes— A default route instructs the router that if it does not have a route for a given destination, it should send the packet to the default route. Therefore, no dynamic routing updates about the remote destinations are necessary.
-
Static routes— A static route allows routes to remote destinations to be manually configured on the router. Therefore, no dynamic routing updates about the remote destinations are necessary.
-
Route maps— Route maps are complex access lists that allow conditions to be tested against a packet or route, and then actions taken to modify attributes of the packet or route.
-
Distribute lists— A distribute list allows an access list to be applied to routing updates.
-
Prefix lists— A prefix list is a specialized access list designed to filter routes.
Passive interfaces were discussed earlier in the “The passive-interface Command” section. Static and default routes were discussed in Chapter 1; specifics related to controlling routing updates are explored in the next section, which is followed by a discussion of route maps, distribute lists, and prefix lists.
Static and Default Routes
Static routes are routes that you manually configure on a router. Static routes are used most often to do the following:
-
Define specific routes to use when two autonomous systems must exchange routing information, rather than having entire routing tables exchanged.
-
Define routes to destinations over a WAN link to eliminate the need for a dynamic routing protocol—that is, when you do not want routing updates to enable or cross the link.
When configuring static routes, keep in mind the following considerations:
-
When using static routes instead of dynamic routing updates, all participating routers must have static routes defined so that they can reach remote networks. Static route entries must be defined for all routes for which a router is responsible. To reduce the number of static route entries, you can define a default static route—for example, ip route 0.0.0.0 0.0.0.0 S0/0/1.
-
If you want a router to advertise a static route in a routing protocol, you might need to redistribute it.
You can configure default routes for routing protocols on Cisco routers. For example, when you create a default route on a router running RIP, the router advertises an address of 0.0.0.0. When a router receives this default route, it forwards any packets destined for a destination that does not appear in its routing table to the default route you configured.
You can also configure a default route by using the ip default-network network-number global configuration command. Figure 4-23, Example 4-13, and Example 4-14 demonstrate the use of this command on a router running RIP. With the ip default-network command, you designate an actual network currently available in the routing table as the default path to use.
R2#show run
R3#show ip route
In Example 4-13, the R2 router has a directly connected interface onto the network specified in the ip default-network network-number command. RIP generates (sources) a default route, which appears as a 0.0.0.0 0.0.0.0 route to its RIP neighbor routers, as shown in Example 4-14 for R3.
The ip default-network command is used to distribute default route information to other routers. For RIP, this command provides no functionality for the router on which it is configured. Other protocols behave differently than RIP with the ip default-network and ip route 0.0.0.0 0.0.0.0 commands.
For example, EIGRP does not redistribute the 0.0.0.0 0.0.0.0 default route by default. However, if the network 0.0.0.0 command is added to the EIGRP configuration, it redistributes a default route as a result of the ip route 0.0.0.0 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 0.0.0.0 address or ip default-network commands). See Chapter 2 and Cisco IOS documentation for further information.
The ip default-network command is used in networks with routers that do not know how to get to the outside world. This command is configured on the router that connects to the outside world and goes through a different major network to reach the outside world. If your environment is all one major network address, you probably would not want to use the ip default-network command, but rather a static route to 0.0.0.0 via a border router.
The ip route 0.0.0.0 0.0.0.0 command is used on routers with IP routing enabled and that point to the outside world, for example for Internet connectivity. This route is advertised as the “gateway of last resort” if running RIP. The router that is directly connected to the border of the outside world is the preferred router, with the static route pointing to 0.0.0.0.
(Note that a command with a similar name, the ip default-gateway command, is used on routers or communication servers that have IP routing turned off. The router or communication server acts just like a host on the network.)
Using Route Maps
Route maps provide another technique to manipulate and control routing protocol updates. Route maps may be used for a variety of purposes. After describing route map applications and operation, this section explores the use of route maps as a tool to filter and manipulate routing updates. All the IP routing protocols can use route maps for redistribution filtering.
Route Map Applications
Network administrators use route maps for a variety of purposes. Several of the more common applications for route maps are as follows:
-
Route filtering during redistribution— Redistribution nearly always requires some amount of route filtering. Although distribute lists can be used for this purpose, route maps offer the added benefit of manipulating routing metrics through the use of set commands.
-
Policy-based routing (PBR)— Route maps can be used to match source and destination addresses, protocol types, and end-user applications. When a match occurs, a set command can be used to define the interface or next-hop address to which the packet should be sent. PBR allows the operator to define routing policy other than basic destination-based routing using the routing table.
-
Network Address Translation (NAT)— Route maps can better control which private addresses are translated to public addresses. Using a route map with NAT also provides more detailed show commands that describe the address-translation process.
-
BGP— Route maps are the primary tools for implementing BGP policy. Network administrators assign route maps to specific BGP sessions (neighbors) to control which routes are allowed to flow in and out of the BGP process. In addition to filtering, route maps provide sophisticated manipulation of BGP path attributes. Route maps for BGP are discussed in Chapter 6, “Implementing a BGP Solution for ISP Connectivity.”
Understanding Route Maps
Route maps are complex access lists that allow some conditions to be tested against the packet or route in question using match commands. If the conditions match, some actions can be taken to modify attributes of the packet or route. These actions are specified by set commands. This is a big difference between route maps and access lists: Route maps can modify the packet or route by using set commands.
A collection of route-map statements that have the same route map name is considered one route map. Within a route map, each route-map statement is numbered and therefore can be edited individually.
The statements in a route map correspond to the lines of an access list. Specifying the match conditions in a route map is similar in concept to specifying the source and destination addresses and masks in an access list.
The route-map map-tag [permit | deny] [sequence-number] global configuration command can be used to define a route map. The parameters of this command are explained in detail in Table 4-14.
Parameter | Description |
---|---|
map-tag | Name of the route map. |
permit | deny | (Optional) A parameter that specifies the action to be taken if the route map match conditions are met. The meaning of permit or deny is dependent on how the route map is used. |
sequence-number | (Optional) A sequence number that indicates the position that a new route-map statement will have in the list of route-map statements already configured with the same name. |
The default for the route-map command is permit, with a sequence-number of 10.
If you leave out the sequence number when configuring all statements for the same route map name, the router will assume that you are editing (and possibly adding to) the first statement, which defaults to sequence number 10. It is important to remember that route map sequence numbers do not automatically increment!
When the sequence-number parameter of the route-map command is not used, the following occurs:
-
If no other entry is already defined with the supplied route-map tag, an entry is created, with the sequence-number set to 10.
-
If only one entry is already defined with the supplied route-map tag, that entry is the default entry for the route-map command, and the sequence-number of the entry is unchanged. (The router assumes you are editing the one entry that is already defined.)
-
If more than one entry is already defined with the supplied route-map tag, an error message is displayed, indicating that the sequence-number is required.
-
If the no route-map map-tag command is specified (without the sequence-number parameter), then the whole route map is deleted.
A route map may be made up of multiple route-map statements (with different sequence numbers). The statements are processed top-down, similar to an access list. The first match found for a route is applied. The sequence number is also used for inserting or deleting specific route-map statements in a specific place in the route map.
The sequence number specifies the order in which conditions are checked. For example, if two statements in a route map are named MYMAP, one with sequence 10 and the other with sequence 20, sequence 10 is checked first. If the match conditions in sequence 10 are not met, sequence 20 is checked.
Like an access list, an implicit deny any appears at the end of a route map. The consequences of this deny depend on how the route map is being used.
The match condition route map configuration commands are used to define the conditions to be checked. The set condition route map configuration commands are used to define the actions to be followed if there is a match and the action to be taken is permit. (The consequences of a deny action depend on how the route map is being used.)
A route-map statement without any match statements will be considered matched.
A single match statement may contain multiple conditions. Only one condition in the same match statement must be true for that match statement to be considered a match (this is a logical OR operation).
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.)
For example, IP standard or extended access lists or prefix lists can be used to establish match criteria using the match ip address {access-list-number | name} [...access-list-number | name] | prefix-list prefix-list-name [..prefix-list-name] route map configuration command. If multiple access lists or prefix lists are specified, matching any one results in a match. A standard IP access list can be used to specify match criteria for a packet’s source address. Extended access lists can be used to specify match criteria based on source and destination addresses, application, protocol type, type of service (ToS), and precedence.
Another way to explain how a route map works is to use a simple example and see how it would be interpreted. Example 4-15 shows a sample route map-like configuration. (Note that on a router, all the conditions and actions shown would be replaced with specific conditions and actions, depending on the exact match and set commands used.)
route-map demo permit 10
match x y z
match a
set b
set c
route-map demo permit 20
match q
set r
route-map demo permit 30
The route map named demo in Example 4-15 is interpreted as follows:
-
If {(x or y or z) and (a) match} then {set b and c}
-
Else
-
If q matches then set r
-
Else
-
Set nothing
Configuring Route Maps to Control Routing Updates
The redistribute commands discussed in the “Configuring Redistribution” section all have a route-map option with a map-tag parameter. This parameter refers to a route map configured with the route-map map-tag [permit | deny] [sequence-number] global configuration command, as described earlier in Table 4-14.
It is important to understand what the permit and deny mean when redistributing. When used with a redistribute command, a route-map statement with permit indicates that the matched route is to be redistributed, while a route-map statement with deny indicates that the matched route is not to be redistributed.
The match condition route map configuration commands are used to define the conditions to be checked. Table 4-15 lists some of the variety of match commands that can be configured. Some of these commands are used for BGP policy, some for PBR, and some for redistribution filtering.
Command | Description |
---|---|
match ip address {access-list-number | name} [...access-list-number | name] | prefix-list prefix-list-name [..prefix-list-name] | Matches any routes that have a network number that is permitted by a standard or extended access list or prefix list. Multiple access lists or prefix lists can be specified; matching any one results in a match. |
match length min max | Matches based on a packet’s Layer 3 length. |
match interface type number | Matches any routes that have the next hop out of one of the interfaces specified. |
match ip next-hop {access-list-number | access-list-name} [...access-list-number | ...access-list-name] | Matches any routes that have a next-hop router address permitted by one of the access lists specified. |
match ip route-source {access-list-number | access-list-name} [...access-list-number | ...access-list-name] | Matches routes that have been advertised by routers and access servers that have an address permitted by one of the access lists specified. |
match metric metric-value | Matches routes that have the metric specified. |
match route-type [external | internal | level-1 | level-2 | local] | Matches routes of the specified type. |
match community {list-number | list-name} | Matches a BGP community. |
match tag tag-value | Matches based on the tag of a route. |
The set condition route map configuration commands change or add characteristics, such as metrics, to any routes that have met a match criterion and the action to be taken is permit. (The consequences of a deny action depend on how the route map is being used.) Table 4-16 lists some of the variety of set commands that are available. Not all the set commands listed here are used for redistribution purposes; the table includes commands for BGP and PBR.
Command | Description |
---|---|
set metric metric-value | Sets the metric value for a routing protocol. |
set metric-type [type-1 | type-2 | internal | external] | Sets the metric type for the destination routing protocol. |
set default interface type number [...type number] | Indicates where to send output packets that pass a match clause of a route map for policy routing and for which the Cisco IOS Software has no explicit route to the destination. |
set interface type number [...type number] | Indicates where to send output packets that pass a match clause of a route map for policy routing. |
set ip default next-hop ip-address [...ip-address] | Indicates where to send output packets that pass a match clause of a route map for policy routing and for which the Cisco IOS Software has no explicit route to the destination. |
set ip default next-hop verify-availability | Forces the router to check the CDP database to determine if an entry is available for the next hop that is specified by the set ip default next-hop command. This command is used to prevent traffic from being “black holed” if the configured next hop becomes unavailable. |
set ip next-hop ip-address [...ip-address] | Indicates where to send output packets that pass a match clause of a route map for policy routing. |
set ip next-hop verify-availability | Forces the router to check the Cisco Discovery Protocol (CDP) database or use object tracking to determine if the next hop that is specified for policy based routing is available. |
set ip vrf | Indicates where to forward packets that pass a match clause of a route map for policy routing when the next hop must be under a specified virtual routing and forwarding (VRF) name. |
set next-hop | Specifies the address of the next hop. |
set level [level-1 | level-2 | stub-area | backbone] | Indicates at what level or type of area to import routes into (for IS-IS and OSPF routes). |
set as-path {tag | prepend as-path-string} | Modifies an autonomous system path for BGP routes. |
set automatic-tag | Automatically computes the BGP tag value. |
set community {community-number [additive] [well-known-community] | none} | Sets the BGP community attribute. |
set local-preference bgp-path-attributes | Specifies a local preference value for the BGP autonomous system path. |
set weight bgp-weight | Specifies the BGP weight value. |
set origin bgp-origin-code | Specifies the BGP origin code. |
set tag | Specifies the tag value for destination routing protocol. |
Configuring Route Maps for Policy Based Routing
PBR is described in detail in Chapter 5, “Implementing Path Control.” This section briefly introduces how route maps are used for PBR.
You might enable policy routing if you want your packets to take a route other than the obvious shortest path. The following should be documented in an implementation plan when planning route map configuration for PBR:
-
Define the route map, including defining the conditions to match (the match statements), and defining the action to be taken when there is a match (the set statements).
-
Define which interface the route map will be attached to. PBR is applied to incoming packets. Enabling PBR causes the router to evaluate all packets incoming on the interface using a route map configured for that purpose.
To define the conditions for policy routing packets, apply the ip policy route-map map-tag interface configuration command. The ip policy route-map MyRouteMap command in Example 4-16 declares that a route map named MyRouteMap is to be used for the policy routing on an interface. The route map has one statement; it is a permit. The match command specifies the match criteria—the conditions under which policy routing is allowed for the interface, based on the destination IP address of the packet. The set command specifies the set actions, which are the particular policy routing actions to perform if the criteria enforced by the match commands are met. In this route map, the route-map MyRouteMap command includes a match command that matches IP address 172.21.16.18, and a set command that sets the next hop to 172.30.3.20 when the condition under match command is met. Packets from 172.21.16.18 will be sent to 172.30.3.20.
Configuring Route Redistribution Using Route Maps
Use route maps when you want detailed control over how routes are redistributed between routing protocols. The route-map map-tag parameter in the redistribute commands specifies the route map used.
The following should be documented in an implementation plan when planning route map configuration for redistribution:
-
Define the route map, including defining the conditions to match (the match statements), and defining the action to be taken when there is a match (the set statements).
-
Define where the route map will be used to control redistribution.
Using Route Maps with Redistribution
Example 4-17 illustrates a route map being used to redistribute RIPv1 into OSPF 10. The route map, called redis-rip, is used in the redistribute rip route-map redis-rip subnets command under the OSPF process.
router ospf 10
redistribute rip route-map redis-rip subnets
route-map redis-rip permit 10
match ip address 23 29
set metric 500
set metric-type type-1
route-map redis-rip deny 20
match ip address 37
route-map redis-rip permit 30
set metric 5000
set metric-type type-2
access-list 23 permit 10.1.0.0 0.0.255.255
access-list 29 permit 172.16.1.0 0.0.0.255
access-list 37 permit 10.0.0.0 0.255.255.255
Sequence number 10 of the route map is looking for an IP address match in access list 23 or access list 29. Routes 10.1.0.0/16 and 172.16.1.0/24 match these lists. If a match is found, the router redistributes the route into OSPF with a cost metric of 500 and sets the new OSPF route to external type 1.
If there is no match to sequence number 10, sequence number 20 is checked. If there is a match in access list 37 (10.0.0.0/8), that route is not redistributed into OSPF, because sequence number 20 specifies deny.
If there is no match to sequence number 20, sequence number 30 is checked. Because sequence number 30 is a permit and there is no match criterion, all remaining routes are redistributed into OSPF with a cost metric of 5000 and an external metric of type 2.
Note that the decision of whether to redistribute a route or not is based on the deny or permit in the route-map command, and not the deny or permit in the ACLs referenced by the route-map command. The ACLs are used only to match routes in the route-map statements.
Using Route Maps to Avoid Route Feedback
As discussed, there is a possibility that routing feedback might cause suboptimal routing or a routing loop when routes are redistributed by more than one router. Figure 4-24 illustrates a network in which two-way multipoint redistribution (redistribution in both directions on both routers) is configured on Routers A and B. To prevent redistribution feedback loops, route maps are configured on both routers.
The potential for routing feedback becomes apparent if you follow the advertisements for a specific network before route maps are configured. For example, RIPv2 on Router C advertises network 192.168.1.0. Routers A and B redistribute the network into OSPF. OSPF then advertises the route to its neighbor OSPF routers as an OSPF external route. The route passes through the OSPF autonomous system and eventually makes its way back to the other edge router. Router B (or A) then redistributes 192.168.1.0 from OSPF back into the original RIPv2 network. This is a routing feedback loop.
To prevent the routing feedback loop, a route map called OSPF_into_RIP has been applied to Routers A and B when redistributing OSPF routes into RIP, as shown in Example 4-18. The route-map statement with sequence number 10 refers to access list 1, which matches the original RIPv2 network 192.168.1.0/16. (The access list should include all networks in the RIPv2 domain.) This route-map statement is a deny, so the 192.168.1.0 route is denied from being redistributed back into RIPv2. If the route does not match sequence number 10, the router then checks sequence number 20, which is an empty permit statement. This statement matches all routes, so all other routes are redistributed into RIP.
access-list 1 permit 192.168.1.0 0.0.0.255
route-map OSPF_into_RIP deny 10
match ip address 1
route-map OSPF_into_RIP permit 20
router rip
redistribute ospf 10 route-map OSPF_into_RIP
router ospf 10
redistribute rip subnets
Using Route Maps with Tags
In Example 4-19, EIGRP 7 is configured on a router. The redistribute rip route-map rip_to_eigrp metric 10000 1000 255 1 1500 command configures redistribution of RIP routes into the EIGRP 7 routing process, with the route map named rip_to_eigrp used to influence the redistribution of RIP routes into EIGRP. The route-map statement 20 matches routes with a tag of 88. These routes are denied from being redistributed into EIGRP 7, because the route-map statement is a deny. Routes without a tag of 88 reach the second route-map statement and are tagged with 77, with the set tag 77 command. These routes are allowed to be distributed into EIGRP 7 because the route-map statement is a permit.
route-map rip_to_eigrp deny 10
match tag 88
route-map rip_to_eigrp permit 20
set tag 77
router eigrp 7
redistribute rip route-map rip_to_eigrp metric 10000 1000 255 1 1500
Using Route Maps with Redistribution and Tags
Figure 4-25 illustrates a network with RIP running in one part and EIGRP running in the other part; multipoint two-way redistribution is configured on Routers R1 and R2. To avoid routing loops, route maps with route tagging are used. The partial configuration for Router R1 is provided in Example 4-20. Router R2 has a similar configuration.
router eigrp 100
redistribute rip metric 10000 100 255 1 1500 route-map intoeigrp
!
router rip
redistribute eigrp 100 metric 3 route-map intorip
!
route-map intoeigrp deny 10
match tag 40
!
route-map intoeigrp permit 20
set tag 20
!
route-map intorip deny 10
match tag 20
!
route-map intorip permit 20
set tag 40
!
In this network, routes redistributed into RIP are tagged with the value 40, and routes redistributed into EIGRP are tagged with the value 20. At the same time, the route map filters tagged updates. Updates with the tag 20 are not allowed to go back into RIP and updates with the tag 40 are not allowed to go back into EIGRP.
The route maps each have two statements. When a route matches the tag in the match command in the first statement, the route is denied (it is not redistributed). All other routes are permitted (they are redistributed) by the second statement, and the set command tags the route appropriately.
Example 4-21 illustrates show ip route output from Routers R1 and R2, for networks 10.0.0.0 and 172.16.0.0. Notice that the route tags do not appear on the routes within the R1 and R2 routers, because these routers learn about all routes from both RIP and EIGRP directly. However, Example 4-22 illustrates show ip route output from Router R3, an internal router in the EIGRP network. Notice that Router R3 does see network 172.16.0.0 with a tag of 20; this tag is carried with the route as R3 advertises it to other routers in the EIGRP network, including R1 and R2. When Routers R1 and R2 see the tag of 20, they do not redistribute the 172.16.0.0 route back into RIP.
R1#show ip route 10.0.0.0
Routing entry for 10.0.0.0/8
Known via "eigrp 100", distance 90, metric 20514560, type internal
Redistributing via rip, eigrp 100
Advertised by rip metric 3 route-map intorip
R2#show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
Known via "rip", distance 120, metric 1
Redistributing via rip, eigrp 100
Advertised by eigrp 100 metric 10000 100 255 1 1500 route-map intoeigrp
R3>show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
Known via "eigrp 100", distance 170, metric 20537600
Tag 20, type external
Using 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.
As mentioned, access lists are usually associated with interfaces and are usually used to control user traffic (data plane traffic) rather than routing protocol traffic (or other control plane traffic). However, routers can have many interfaces, and route information can also be obtained through route redistribution, which does not involve a specific interface. In addition, access lists 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.
Access lists are configured in global configuration mode; the associated distribute list is configured under the routing protocol process. The access list should permit the networks that you want advertised or redistributed and deny the networks that you want to remain hidden. The router then applies the access list to routing updates for that protocol. Options in the distribute-list command allow updates to be filtered based on factors including the following:
Using a distribute list gives the administrator great flexibility in determining just which routes will be permitted and which will be denied.
Figure 4-26 shows the general process that a router uses when filtering routing updates using a distribute list that is based on the incoming or outgoing interface. The process includes the following steps:
-
The router receives a routing update or prepares to send an update about one or more networks.
-
The router looks at the interface involved with the action: the interface on which an incoming update has arrived, or, for an update that must be advertised, the interface out of which it should be advertised.
-
The router determines if a filter (distribute list) is associated with the interface.
-
If a filter (distribute list) is not associated with the interface, the packet is processed normally.
-
If a filter (distribute list) is associated with the interface, the router scans the access list referenced by the distribute list for a match for the given routing update.
-
If there is a match in the access list, the route entry is processed as configured. It is either permitted or denied by the matching access list statement.
-
If no match is found in the access list, the implicit deny any at the end of the access list causes the route entry to be dropped.
Configuring Distribute Lists to Control Routing Updates
You can filter routing update traffic for any protocol by defining an access list and applying it to a specific routing protocol using the distribute-list command. A distribute list enables the filtering of routing updates coming into or out of a specific interface from neighboring routers using the same routing protocol. A distribute list also allows the filtering of routes redistributed from other routing protocols or sources.
Planning a Distribute List Deployment
The following should be documented in an implementation plan when planning to configure distribute lists:
-
Define the traffic filtering requirements that will be used to permit or deny routes, using an access list or a route map.
-
Define a distribute list to use the access list or route map, and whether it will be applied to the inbound or outbound updates.
Configuring a Distribute List
To configure a distribute list, follow this procedure:
Step 1 | Identify the network addresses of the routes you want to filter, and create an access list. |
Step 2 | Determine whether you want to filter traffic on an incoming interface, traffic on an outgoing interface, or routes being redistributed from another routing source. |
Step 3 | Use the distribute-list {access-list-number | name} out [interface-name | routing-process [routing-process parameter]] router configuration command to assign the access list to filter outgoing routing updates. Table 4-17 explains the parameters of this command. |
Parameter | Description |
---|---|
access-list-number | name | Specifies the standard access list number or name |
out | Applies the access list to outgoing routing updates |
interface-name | (Optional) Specifies the name of the interface out of which updates are filtered |
routing-process | (Optional) Specifies the name of the routing process, or the keyword static or connected, that is being redistributed and from which updates are filtered |
routing-process parameter | (Optional) Specifies a routing process parameter, such as the autonomous system number of the routing process |
Note | Because OSPF routers must maintain LSDB synchronization within an area, the 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; in other words, the command can be applied to external type 2 and external type 1 routes, but not to intra-area or interarea routes. |
Step 4 | Alternatively, use the distribute-list [access-list-number | name] | [route-map map-tag] in [interface-type interface-number] router configuration command to assign the access list to filter routing updates coming in through an interface. (This command allows the use of a route map instead of an access list for OSPF and EIGRP.) Table 4-18 explains the parameters of this command. |
Description | |
---|---|
access-list-number | name | Specifies the standard access list number or name. |
map-tag | (Optional) Specifies the name of the route map that defines which networks are to be installed in the routing table and which are to be filtered from the routing table. This argument is supported by OSPF only. |
in | Applies the access list to incoming routing updates. |
interface-type interface-number | (Optional) Specifies the interface type and number from which updates are filtered. |
Note | The distribute-list in command prevents most routing protocols from placing the filtered routes in their database. However, OSPF routes cannot be filtered from entering the OSPF LSDB. Thus, when this command is used with OSPF, the routes are still placed in the LSDB; they are only filtered from entering the routing table. |
It is important to understand the differences between these commands:
-
The distribute-list out command filters updates going out of the interface or routing protocol specified in the command, into the routing process under which it is configured.
-
The distribute-list in command filters updates going into the interface specified in the command, into the routing process under which it is configured.
IP Route Filtering with Distribute List Configuration Example
Figure 4-27 shows the topology of a network in which network 10.0.0.0 must be hidden from the devices in network 192.168.5.0.
Example 4-23 is the configuration of Router B in Figure 4-27. In this example, the distribute-list out command applies access list 7 to packets going out interface Serial 0/0/0. The access list allows only routing information about network 172.16.0.0 to be distributed out Router B’s Serial 0/0/0 interface. The implicit deny any at the end of the access list prevents updates about any other networks from being advertised. As a result, network 10.0.0.0 is hidden.
router eigrp 1
network 172.16.0.0
network 192.168.5.0
distribute-list 7 out Serial0/0/0
!
access-list 7 permit 172.16.0.0 0.0.255.255
Note | Another way to achieve the filtering of network 10.0.0.0 in this example is to deny network 10.0.0.0 and permit any other networks. This method would be particularly efficient if the routing information contained multiple networks but only network 10.0.0.0 needed filtering. |
Controlling Redistribution with Distribute Lists
With mutual redistribution, using a distribute list helps prevent route feedback and routing loops. Route feedback occurs when routes originally learned from one routing protocol are redistributed back into that protocol. Figure 4-28 illustrates an example in which redistribution is configured both ways between RIPv2 and OSPF (two-way redistribution). The configuration on Router B is shown in Example 4-24. (Router D’s configuration would be similar to Router B’s configuration.)
router ospf 1
network 10.0.0.8 0.0.0.3 area 0
redistribute rip subnets
distribute-list 2 out rip
router rip
network 10.0.0.0
version 2
passive-interface Serial0/0/3
redistribute ospf 1 metric 5
distribute-list 3 out ospf 1
access-list 2 deny 10.8.0.0 0.3.255.255
access-list 2 permit any
access-list 3 permit 10.8.0.0 0.3.255.255
Router B redistributes the networks it learns via RIPv2 (in this case, 10.1.0.0 to 10.3.0.0) into OSPF. Without filtering, route feedback could occur if OSPF on Router D, the other redistribution point, redistributes those same networks back into RIP.
Therefore, the configuration in Example 4-24 includes a distribute list configuration that prevents route feedback. Access list 2 denies the routes originating in the OSPF network (10.8.0.0 through 10.11.0.0) and permits all others; the distribute list configured under OSPF refers to this access list. The result is that networks 10.8.0.0 to 10.11.0.0, originated by OSPF, are not redistributed back into OSPF from RIPv2. All other routes are redistributed into OSPF. Redistribution from OSPF into RIPv2 is filtered with access list 3; it permits routes 10.8.0.0 through 10.11.0.0 to be redistributed into RIPv2.
A distribute list hides network information, which could be considered a drawback in some circumstances. For example, in a network with redundant paths, a distribute list might permit routing updates for only specific paths, to avoid routing loops. In this case, other routers in the network might not know about the other ways to reach the filtered networks, so if the primary path goes down, the backup paths are not used because the rest of the network does not know they exist. When redundant paths exist, you should use other techniques.
Using Prefix Lists
As described in the previous section, to restrict the routing information that the Cisco IOS Software learns or advertises, you can filter routing updates to and from particular neighbors by defining either an access list with a distribute list, or a prefix list, and then apply it to the updates.
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.
The following sections detail the characteristics of prefix lists and how to filter with them. The configuration and verification of prefix lists is also covered.
Prefix List Characteristics
As discussed, access lists were originally designed to do packet filtering. 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 no command 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; the router uses this number to sort the entries in the list. If you initially sequence the lines with some gaps between the sequence numbers, you can easily insert lines later. You can also remove individual lines without removing the entire list.
Note -
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. For example, routers match network numbers in a routing update against the prefix list using as many bits as indicated. For example, you can specify a prefix list to match 10.0.0.0/16, which will match 10.0.0.0 routes but not 10.1.0.0 routes. Optionally, the prefix list can also 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.
Filtering with Prefix Lists
Filtering by prefix list involves matching the prefixes of routes with those listed in the prefix list, similar to using access lists.
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.
Configuring Prefix Lists
The ip prefix-list {list-name | list-number} [seq seq-value] {deny | permit} network/length [ge ge-value] [le le-value] global configuration command is used to create a prefix list, as described in Table 4-19.
Description | |
---|---|
list-name | The name of the prefix list that will be created (case sensitive). |
list-number | The number of the prefix list that will be created. |
seq seq-value | A 32-bit sequence number of the prefix-list statement, used to determine the order in which the statements are processed when filtering. Default sequence numbers are in increments of 5 (5, 10, 15, and so on). |
deny | permit | The action taken when a match is found. |
network/length | The prefix to be matched and the length of the prefix. The network is a 32-bit address. The length is a decimal number. |
ge ge-value | The range of the prefix length to be matched for prefixes that are more specific than network/length. The range is assumed to be from ge-value to 32 if only the ge attribute is specified. |
le le-value | The range of the prefix length to be matched for prefixes that are more specific than network/length. The range is assumed to be from length to le-value if only the le attribute is specified. |
The ge and le keywords are optional. They can be used to specify the range of the prefix length to be matched for prefixes that are more specific than network/length. The value range is as follows
length < ge-value < le-value <= 32
An exact match is assumed when neither ge nor le is specified.
Prefix list entries can be reconfigured incrementally. In other words, an entry can be deleted or added individually.
The use of the ge and le options in the ip prefix-list command can be confusing. The following are results of some testing done to understand these keywords.
Three routers were used in this testing: Router B, Router A, and its neighbor 10.1.1.1, as illustrated in Figure 4-29.
Before configuring the prefix list, Router A learns the following routes (from Router B):
172.16.0.0 subnetted:
172.16.10.0/24
172.16.11.0/24
In these scenarios some BGP commands, as described in Chapter 6, are used. At this point the workings of these commands is not important. The important facts for this testing are that Router A initially has two /24 routes and is aggregating (summarizing) those routes to 172.16.0.0/16 so that the summary /16 route and the two /24 routes are available to be advertised. The prefix list determines which routes neighbor 10.1.1.1 learns from Router A.
-
Scenario 1— In this scenario, the following is configured on Router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.16.10.0/8 le 24When you view the router’s configuration with the show run command, you see that the router automatically changes the last line of this configuration to the following:
ip prefix-list tenonly permit 172.0.0.0/8 le 24This is because only the first 8 bits in the address are considered significant when a prefix length of /8 is used. In this case, neighbor 10.1.1.1 learns about 172.16.0.0/16, 172.16.10.0/24, and 172.16.11.0/24. These are the routes that match the first 8 bits of 172.0.0.0 and have a prefix length between 8 and 24.
-
Scenario 2— In this scenario, the following is configured on Router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.0.0.0/8 le 16Neighbor 10.1.1.1 learns only about 172.16.0.0/16. This is the only route that matches the first 8 bits of 172.0.0.0 and has a prefix length between 8 and 16.
-
Scenario 3— In this scenario, the following is configured on Router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.0.0.0/8 ge 17Neighbor 10.1.1.1 learns only about 172.16.10.0/24 and 172.16.11.0/24. (In other words, Router A ignores the /8 parameter and treats the command as if it has the parameters ge 17 le 32.)
-
Scenario 4— In this scenario, the following is configured on Router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.0.0.0/8 ge 16 le 24Neighbor 10.1.1.1 learns about 172.16.0.0/16, 172.16.10.0/24, and 172.16.11.0/24. (In other words, Router A ignores the /8 parameter and treats the command as if it has the parameters ge 16 le 24.)
-
Scenario 5— In this scenario, the following is configured on router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.0.0.0/8 ge 17 le 24
Neighbor 10.1.1.1 learns about 172.16.10.0/24 and 172.16.11.0/24. (In other words, Router A ignores the /8 parameter and treats the command as if it has the parameters ge 17 le 24.)
The no ip prefix-list list-name global configuration command, where list-name is the name of a prefix list, is used to delete a prefix list.
The [no] ip prefix-list list-name description text global configuration command can be used to add or delete a text description for a prefix list.
Prefix List Sequence Numbers
Prefix list sequence numbers are generated automatically, unless you disable this automatic generation. If you do so, you must specify the sequence number for each entry using the seq-value argument of the ip prefix-list command.
A prefix list is an ordered list. The sequence number is significant when a given prefix is matched by multiple entries of a prefix list, in which case the one with the smallest sequence number is considered the real match.
The evaluation of a prefix list starts with the lowest sequence number and continues down the list until a match is found. When an IP address match is found, the permit or deny statement is applied to that network and the remainder of the list is not evaluated.
Regardless of whether you use the default sequence numbers to configure a prefix list, you do not need to specify a sequence number when removing a configuration entry.
By default, a prefix list’s entries have sequence values of 5, 10, 15, and so on. In the absence of a specified sequence value, a new entry is assigned a sequence number equal to the current maximum sequence number plus 5. For example, if the first configured sequence number is 3, subsequent entries will be 8, 13, and 18.
Prefix list show commands include the sequence numbers in their output.
The no ip prefix-list sequence-number global configuration command is used to disable the automatic generation of sequence numbers of prefix list entries. Use the ip prefix-list sequence-number global configuration command to reenable the automatic generation of sequence numbers.
Prefix List Examples
Consider the prefix list: ip prefix-list MyList permit 192.168.0.0/16. Which of the following routes would this prefix list match: 192.168.0.0/16, 192.168.0.0/20, 192.168.2.0/24?
Only the first route, 192.168.0.0/16, would match because that is the only one that matches both the address and the mask.
For the next example, consider the two prefix lists:
-
ip prefix-list List1 permit 192.168.0.0/16 le 20
-
ip prefix-list List2 permit 192.168.0.0/16 ge 18
Which of the following routes would these prefix lists match: 192.168.0.0/16, 192.168.0.0/20, 192.168.2.0/24?
The following routes match List 1: 192.168.0.0/16, 192.168.0.0/20. The route 192.168.2.0/24 is not matched because, even though the IP address falls within the specified address range, the subnet mask is too long.
The following routes match List 2: 192.168.0.0/20, 192.168.2.0/24. The route 192.168.0.0/16 is not matched because the subnet mask is too short.
Another example is ip prefix-list NextList1 0.0.0.0/0. The all-0s prefix means match all prefixes. In this case, without any le or ge parameter, the /0 mask must also be matched. Only a default route matches this prefix list.
A modification of the above is ip prefix-list NextList20.0.0.0/0 ge 32. In this case any route with a /32 prefix matches this list.
A similar example is ip prefix-list NextList3 0.0.0.0/0 le 32. The le 32 parameter means that any prefix length between 0 and 32, inclusive, matches. Thus, this prefix list matches all routes.
Another similar example is ip prefix-list NextList4 0.0.0.0/1 le 24. Any route with a prefix between /1 and /24 matches this list.
For the next example, consider Figure 4-30 and Example 4-25. Two prefix lists are configured, each one used in a route map.
router ospf 1
network 10.0.0.8 0.0.0.0 area 0
redistribute rip route-map intoOSPF subnets
router rip
network 10.0.0.0
version 2
passive-interface s0/0/0
redistribute ospf 1 route-map intoRIP metric 5
route-map intoOSPF permit 10
match ip address prefix-list PFX1
route-map intoRIP permit 10
match ip address prefix-list PFX2
ip prefix-list PFX1 permit 10.0.0.0/14
ip prefix-list PFX2 permit 10.8.0.0/14
The intoOSPF route map uses prefix list PFX1. This permits 10.0.0.0/14, which includes 10.0.0.0 through 10.3.0.0. These routes are redistributed from RIP into OSPF. All other networks are not permitted by prefix list PFX1 and are therefore denied (not redistributed).
The intoRIP route map uses prefix list PFX2. This permits 10.8.0.0/14, which includes 10.8.0.0 through 10.11.0.0, some of the routes originated by OSPF. These routes are redistributed from OSPF into RIP. All other networks are not permitted by prefix list PFX2 and are therefore denied (not redistributed).
Note that the decision of whether to redistribute a route or not is based on the deny or permit in the route-map command, and not the deny or permit in the prefix list referenced by the route-map command. The prefix list is used only to match routes in the route-map statements.
In a network with redundant paths, the goal of using a prefix lists and route maps may be to prevent routing loops. As with distribute lists, prefix lists permit routing updates that enable only the desired paths to be advertised. Therefore, other routers in the network do not know about the other ways to reach the filtered networks.
Verifying Prefix Lists
The EXEC commands related to prefix lists are described in Table 4-20. Use the show ip prefix-list? command to see all the show commands available for prefix lists.
Command | Description |
---|---|
show ip prefix-list [detail | summary] | Displays information on all prefix lists. Specifying the detail keyword includes the description and the hit count (the number of times the entry matches a route) in the display. |
show ip prefix-list [detail | summary] prefix-list-name | Displays a table showing the entries in a specific prefix list. |
show ip prefix-list prefix-list-name [network/length] | Displays the policy associated with a specific network/length in a prefix list. |
show ip prefix-list prefix-list-name [seq sequence-number] | Displays the prefix list entry with a given sequence number. |
show ip prefix-list prefix-list-name [network/length] longer | Displays all entries of a prefix list that are more specific than the given network and length. |
show ip prefix-list prefix-list-name [network/length] first-match | Displays the entry of a prefix list that matches the network and length of the given prefix. |
clear ip prefix-list prefix-list-name [network/length] | Resets the hit count shown on prefix list entries. |
In the sample output of the show ip prefix-list detail command shown in Example 4-26, Router A has a prefix list called superonly that has only one entry (sequence number 5). The hit count of 0 means that no routes match this entry.
RtrA #show ip prefix-list detail
Prefix-list with the last deletion/insertion: superonly ip prefix-list superonly:
Description: only permit supernet
count: 1, range entries: 0, sequences: 5 - 5, refcount: 1
seq 5 permit 172.0.0.0/8 (hit count: 0, refcount: 1)
Using Multiple Methods to Control Routing Updates
You can apply a combination of prefix lists, distribute lists, and route maps to incoming or outgoing information, or both, as illustrated in Figure 4-31. The incoming prefix list, the incoming distribute list, and the incoming route map must all permit the routes that are received from a neighbor before they will be accepted into the IP routing table. Similarly, outgoing routes must pass the outgoing distribute list, the outgoing prefix list, and the outgoing route map before they will be transmitted to the neighbor.
Comprehensive Example of Controlling Routing Updates
This section provides a comprehensive example of how routing updates can be controlled, using multiple methods. Figure 4-32 shows the network used in this example. Both R1 and R2 are redistributing OSPF into EIGRP and EIGRP into OSPF. Notice that two links exist between R1 and R2, one in OSPF and one in EIGRP.
R3’s loopback interface addresses are 192.168.254.1 and 192.168.253.1. These interfaces are not running EIGRP. R3 is injecting these routes into the EIGRP network. Router R1 translates those EIGRP advertisements into OSPF, with a specified seed metric. These OSPF advertisements are translated back into EIGRP by Router R2. However, as we shall see, the resulting metric is better than the one advertised by R3, so R1 determines that the best path to R3’s loopback address is via R2. We shall also see that there is a routing loop in this network.
In this example, prefix lists, route tagging, and route filtering are used to fix the routing loop issue, and the administrative distance is changed to fix the suboptimal routing issue.
A prefix lists is used to identify specific prefixes. As discussed, other tools could be used to identify routes, but prefix lists are flexible and allow both the prefix and mask to be matched.
When Router R3 injects 192.168.254.0 and 192.168.253.0 into EIGRP, all routers in the EIGRP network learn the routes. In R1, the routes are redistributed into OSPF and will be tagged. When R2 is redistributing routes from OSPF into EIGRP, it will examine the routes for the tag; if the route is tagged, it will not be redistributed into EIGRP because the tag indicates that it originated in EIGRP. Routes being redistributed by R2 into OSPF and then by R1 into EIGRP will be handled in a similar manner.
This example goes through the following steps:
Step 1 | Verify the scenario. |
Step 2 | Identify specific routes with prefix lists. |
Step 3 | Configure route maps to set tags according to the prefix list. |
Step 4 | Add the route map to the redistribute command. |
Step 5 | Verify the configuration. |
Step 6 | Display routing table changes and trace to key destinations to verify operations. |
First, the scenario is verified. The focus is on the 192.168.254.0 route, but the results for the 192.168.253.0 route are similar. Example 4-27 shows R1’s routing table entry for the 192.168.254.0 route.
R1#show ip route 192.168.254.0
Routing entry for 192.168.254.0 255.255.255.0
Known via "eigrp 1", distance 170, metric 28160, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 metric 4 subnets
Last update from 10.3.7.2 on FastEthernet0/1.2, 01:38:46 ago
Routing Descriptor Blocks:
* 10.3.7.2, from 10.3.7.2, 01:38:46 ago, via FastEthernet0/1.2
Route metric is 28160, traffic share count is 1
Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 500 bytes
Loading 1/255, Hops 1
R1#
Notice in Example 4-27 that Router R1 is learning about this route from Router R2, 10.3.7.2, instead of directly from Router R3. This is suboptimal routing.
Example 4-28 illustrates the results of a trace to 192.168.254.1, Router R3’s loopback interface, on Router R1. Notice the routing loop between R1 and R2. Thus, this network has a routing loop and suboptimal routing.
R1#trace 192.168.254.1 ttl 0 255
Type escape sequence to abort.
Tracing the route to 192.168.254.1
0 10.3.7.2 0 msec 0 msec 4 msec
1 10.3.7.2 0 msec 0 msec 4 msec
2 10.2.7.1 0 msec 0 msec 0 msec
3 10.3.7.2 4 msec 0 msec 4 msec
4 10.2.7.1 0 msec 0 msec 0 msec
5 10.3.7.2 0 msec 0 msec 4 msec
6 10.2.7.1 0 msec 0 msec 4 msec
7 10.3.7.2 0 msec 0 msec 4 msec
8 10.2.7.1 0 msec 0 msec 4 msec
9 10.3.7.2 0 msec 0 msec 0 msec
10 10.2.7.1 0 msec 4 msec 0 msec
250 10.2.7.1 8 msec 12 msec 8 msec
251 10.3.7.2 8 msec 12 msec 8 msec
252 10.2.7.1 12 msec 8 msec 12 msec
253 10.3.7.2 8 msec 12 msec 8 msec
254 10.2.7.1 8 msec 12 msec 8 msec
255 10.3.7.2 12 msec 8 msec 12 msec
R1#
While investigating the cause of these issues, some output on the routers is examined. Example 4-29 illustrates output from the show ip protocols command on Router R1, confirming that Router R1 is redistributing OSPF into EIGRP and redistributing EIGRP into OSPF.
R1#show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1, ospf 1
EIGRP NSF-aware route hold timer is 240s
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.0.7.1
It is an autonomous system boundary router
Redistributing External Routes from,
eigrp 1 with metric mapped to 4, includes subnets in redistribution
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.2.0.0 0.0.255.255 area 0
172.31.8.0 0.0.0.255 area 0
R1’s EIGRP topology table is examined next, and the results are displayed in Example 4-30. Notice the metric for the first path (28160), via R2, is much lower than the metric for the second path (2297856), via R3. This is why R1 chooses the path via R2 instead of via R3. However, the path via R2 is the redistributed route from OSPF, and the route was redistributed into OSPF by R1. The result is the routing loop and suboptimal routing.
R1#show ip eigrp topology 192.168.254.0
IP-EIGRP (AS-1): Topology entry for 192.168.254.0 255.255.255.0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
Routing Descriptor Blocks:
10.3.7.2 (FastEthernet0/1.2), from 10.3.7.2, Send flag is 0x0
Composite metric is (28160/256), Route is External
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 500
Hop count is 1
External data:
Originating router is 10.0.7.2
AS number of route is 1
External protocol is OSPF, external metric is 4
Administrator tag is 0 (0x00000000)
192.168.2.2 (Serial0/0/0), from 192.168.2.2, Send flag is 0x0
Composite metric is (2297856/128256), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Hop count is 1
External data:
This is confirmed by examining R2’s routing table entry for 192.168.254.0. The results are shown in Example 4-31. Notice that this route is known by OSPF. Also notice that this route is being redistributed into EIGRP, and a seed metric of 10000000 0 255 1 500 is specified. It seems that R1 views this seed metric as better than R3’s metric for the 192.168.254.0 network.
R2#show ip route 192.168.254.0
Routing entry for 192.168.254.0 255.255.255.0
Known via "ospf 1", distance 110, metric 4, type extern 2, forward metric 1
Redistributing via eigrp 1
Advertised by eigrp 1 metric 10000000 0 255 1 500 match external 1 & 2
Last update from 10.2.7.1 on Fast Ethernet0/1.1, 00:46:19 ago
Routing Descriptor Blocks:
* 10.2.7.1, from 10.0.8.1, 00:46:19 ago, via FastEthernet0/1.1
Route metric is 4, traffic share count is 1
R2#
To fix these problems, a prefix list is first configured, as shown in Example 4-32 for R1 (a similar configuration is used on R2). In the prefix list, le 32 is used to identify any mask with a length less than or equal to 32 bits, which includes the prefix and any smaller subnet of the prefix. The prefix list is two lines, one for each network we want to identify.
R1(config)#ip prefix-list EXTERNAL seq 5 permit 192.168.253.0/24 le 32
R1(config)#ip prefix-list EXTERNAL seq 10 permit 192.168.254.0/24 le 32
R1(config)#
Route maps are configured next, as shown in Example 4-33. These route maps will be used to control redistribution. The first route map, SETTAG, uses the prefix list to match routes. Routes that match the prefix list are tagged with a value of 1000. The first statement in this route map is a permit; it permits routes that match the prefix list and sets the tag to 1000. All other routes, those that don’t match the prefix list, fall to the second statement, which simply permits the routes (to be redistributed).
The second route map, MATCHTAG, also has two statements. Routes that have a tag that matches 1000 are denied (from being redistributed). These routes are the ones that were previously redistributed, so we do not want them to be redistributed again. All other routes, those that do not have a tag that matches 1000, fall to the second statement, which simply permits the routes (to be redistributed).
R1(config)#route-map SETTAG permit 10
R1(config-route-map)#match ip address prefix-list EXTERNAL
R1(config-route-map)#set tag 1000
R1(config-route-map)#exit
R1(config)#route-map SETTAG permit 20
R1(config-route-map)#exit
R1(config)#route-map MATCHTAG deny 10
R1(config-route-map)#match tag 1000
R1(config-route-map)#!
R1(config-route-map)#route-map MATCHTAG permit 20
R1(config-route-map)#
Next redistribution is configured to use the route maps, as shown in Example 4-34. The SETTAG route map is used when redistributing into OSPF. The MATCHTAG route map is used when redistributing into EIGRP.
R1(config-router)#router ospf 1
R1(config-router)#redistribute eigrp 1 metric 4 subnets route-map SETTAG
R1(config-router)#router eigrp 1
R1(config-router)#redistribute ospf 1 metric 100 100 125 125 1500 match external
1 external 2 route-map MATCHTAG
R1(config-router)#
Example 4-35 illustrates the similar configuration of R2.
R2(config)#ip prefix-list EXTERNAL seq 5 permit 192.168.253.0/24 le 32
R2(config)#ip prefix-list EXTERNAL seq 10 permit 192.168.254.0/24 le 32
R2(config)#
R2(config)#route-map SETTAG permit 10
R2(config-route-map)# match ip address prefix-list EXTERNAL
R2(config-route-map)# set tag 1000
R2(config-route-map)#route-map SETTAG permit 20
R2(config-route-map)#
R2(config-route-map)#route-map MATCHTAG deny 10
R2(config-route-map)#match tag 1000
R2(config-route-map)#route-map MATCHTAG permit 20
R2(config-route-map)#
R2(config-route-map)#router ospf 1
R2(config-router)#redistribute eigrp 1 metric 4 subnets route-map SETTAG
R2(config-router)#
R2(config-router)#router eigrp 1
R2(config-router)#redistribute ospf 1 metric 10000000 0 255 1 500 match external 1
external 2 route-map MATCHTAG
R2(config-router)#
The next step is to verify that traffic is now going the best way, and that the routing loop is no longer there. Example 4-36 illustrates output from the show ip route command on R1, illustrating that 192.168.254.0 is now reachable via EIGRP, from R3 (192.168.2.2). This output also shows that this route is being advertised into OSPF and that the route map SETTAG is used. (Note that displaying a specific entry in the routing table such as in this example is the only way to see that a route map is being used for redistribution.)
R1#show ip route 192.168.254.0
Routing entry for 192.168.254.0 255.255.255.0
Known via "eigrp 1", distance 170, metric 2297856, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 metric 4 subnets route-map SETTAG
Last update from 192.168.2.2 on Serial0/0/0, 00:03:18 ago
Routing Descriptor Blocks:
* 192.168.2.2, from 192.168.2.2, 00:03:18 ago, via Serial0/0/0
Route metric is 2297856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability is 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R1#
Example 4-37 illustrates the result of a trace to 192.168.254.1, confirming that the routing loop is no longer there.
R1#trace 192.168.254.1
Type escape sequence to abort.
Tracing the route to 192.168.254.1
1 192.168.2.2 12 msec * 12 msec
R1#
Other commands can also be used to verify this configuration. Example 4-38 verifies R1’s route to 192.168.254.0 is via R3.
R1#show ip route | section 254
D EX 192.168.254.0 255.255.255.0
[170/2297856] via 192.168.2.2, 00:07:05, Serial0/0/0
R1#
Note | The section keyword causes only those lines that match a given expression (such as the text “254”), and any lines associated with that expression, to be displayed in the command output. |
Example 4-39 illustrates R1’s EIGRP topology table. From this output we can see that R1 now learns about this route from only R3. The route from R2 is no longer there.
R1#show ip eigrp topology 192.168.254.0
IP-EIGRP (AS 1): Topology entry for 192.168.254.0 255.255.255.0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
192.168.2.2 (Serial0/0/0), from 192.168.2.2, Send flag is 0x0
Composite metric is (2297856/128256), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 3.3.3.3
AS number of route is 0
External protocol is Connected, external metric is 0
Administrator tag is 0 (0x00000000)
R1#
Examining the OSPF tables verifies that the tagged route is being learned in the OSPF network. Example 4-40 illustrates a portion of R1’s OSPF database, using the show ip ospf database external command. Notice that R1 is learning the 192.168.254.0 route via OSPF, and that this route is tagged with a value of 1000.
R1#show ip ospf database external 192.168.254.0
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-5 AS External Link States
LS age: 539
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.254.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x1642
Length: 36
Network Mask: 255.255.255.0
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 4
Forward Address: 0.0.0.0
External Route Tag: 1000
R1#
To verify that the route map is really tagging the traffic, we might try the show route-map command. This command does show the route maps configured on the router. However, the match counters in this command only work when the route map is used for policy based routing, not when it is used for redistribution.
The show ip prefix-list detail command, illustrated in Example 4-41 is more useful in this case. Notice the hit counts for each sequence number in the prefix list in the command output, indicating how many times the prefix list matched the networks.
R1#show ip prefix-list detail EXTERNAL
ip prefix-list EXTERNAL
count: 2, range entries: 2, sequences: 5 – 10, refcount: 3
seq 5 permit 192.168.253.0/24 le 32 (hit count: 2, refcount: 2)
seq 10 permit 192.168.254.0/24 le 32 (hit count: 2, refcount: 1)
R1#
To test the prefix list counters, the OSPF process is first cleared, forcing it to restart. After the OSPF neighbor relationship goes down and then back up, the router recalculates and retags the routes. Example 4-42 shows the clearing process and the resulting prefix list detail. Notice that the hit count on both networks has increased by 1, indicating a match. This prefix list match is used by the route map to set the route tag.
Caution | Clearing the OSPF process is not recommended in production networks unless absolutely necessary, because it resets all OSPF relationships. |
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R1#
4d21h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1.1 from FULL to
DOWN, Neighbor Down: Interface down or detached
R1#
R1#
4d21h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1.1 from LOADING to
FULL, Loading Done
R1#
R1#show ip prefix-list detail EXTERNAL
ip prefix-list EXTERNAL
count: 2, range entries: 2, sequences: 5 – 10, refcount: 3
seq 5 permit 192.168.253.0/24 le 32 (hit count: 3, refcount: 2)
seq 10 permit 192.168.254.0/24 le 32 (hit count: 3, refcount: 1)
R1#
An alternative, simpler, configuration for the R1 and R2 routers is illustrated in Example 4-43. This configuration uses only one route map, TAGS, applied to both OSPF and EIGRP redistribution. The route map denies (does not redistribute) routes that are tagged, and it permits (redistributes) all other routes after setting their tag.
route-map TAGS deny 10
match tag 1000
route-map TAGS permit 20
set tag 1000
router ospf 1
redistribute eigrp 1 metric 4 route-map TAGS
router eigrp 1
redistribute ospf 1 metric 1000000 0 255 1 800 route-map TAGS
The routing loop problem is solved. However suboptimal routing still exists in this network, as shown in Example 4-44, illustrating R2’s routing table. Notice that R2 is using the OSPF route, via R1 to reach R3’s external networks. The trace output shown in Example 4-45 confirms the route R2 is taking.
R2#show ip route 192.168.254.0
Routing entry for 192.168.254.0 255.255.255.0
Known via "ospf 1", distance 110, metric 4
Tag 1000, type extern 2, forward metric 1
Redistributing via eigrp 1
Last update from 10.2.7.1 on FastEthernet0/1.1, 00:23:52 ago
Routing Descriptor Blocks:
* 10.2.7.1, from 10.0.7.1, 00:23:52 ago, via FastEthernet0/1.1
Route metric is 4, traffic share count is 1
Route tag 1000
R2#
R2#trace 192.168.254.1
Type escape sequence to abort.
Tracing the route to 192.168.254.1
1 10.2.7.1 4 msec 0 msec 0 msec
2 192.168.2.2 16 msec * 12 msec
R2#
Example 4-46 compares R1’s and R2’s routing table entry for the route to the R3 loopback network. Notice the administrative distance of the routes. R2 is learns the route from R1 with an administrative distance of 110 (from OSPF). R2 also learns the route from R3, just as R1 does, with an administrative distance of 170 (from external EIGRP). R2 chooses the route with the lowest administrative distance, and therefore chooses the route via R1. This process is illustrated in Figure 4-33.
R1#show ip route | section 254
D EX 192.168.254.0 255.255.255.0
[170/2297856] via 192.168.2.2, 00:18:07, Serial0/0/0
R1#
R2#show ip route | section 254
O E2 192.168.254.0 255.255.255.0
[110/4] via 10.2.7.1, 00:17:32, FastEthernet0/1.1
R2#
To fix this suboptimal routing, the administrative distance of the external routes in the OSPF network is changed to something higher than the administrative distance of EIGRP external routes (170); 171 is used here. R2’s configuration is changed first, and before changing the configuration, debugging is enabled so that the process used by the router can be examined. Example 4-47 illustrates the resulting output when the change is made on R2. Notice the routes being deleted and then be added again because of the smaller administrative distance.
R2#debug ip routing
IP routing debugging is on
R2#
R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router ospf 1
R2(config-router)#distance ospf external 171
R2(config-router)#
lw2d: RT: delete route to 10.1.1.0 255.255.255.0
lw2d: RT: NET-RED 10.1.1.0 255.255.255.0
lw2d: RT: delete route to 10.0.7.1 255.255.255.255
lw2d: RT: NET-RED 10.0.7.1 255.255.255.255
lw2d: RT: delete route to 192.168.254.0 255.255.255.0
lw2d: RT: NET-RED 192.168.254.0 255.255.255.0
lw2d: RT: delete route to 192.168.253.0 255.255.255.0
lw2d: RT: NET-RED 192.168.253.0 255.255.255.0
lw2d: RT: SET_LAST_RDB for 10.0.7.1 255.255.255.255
NEW rdb: via 10.2.7.1
lw2d: RT: add 10.0.7.1 255.255.255.255 via 10.2.7.1, ospf metric [110/2]
lw2d: RT: NET-RED 10.0.7.1 255.255.255.255
lw2d: RT: SET_LAST_RDB for 10.1.1.0 255.255.255.0
NEW rdb: via 10.2.7.1
lw2d: RT: add 10.1.1.0 255.255.255.0 via 10.2.7.1, ospf metric [171/4]
lw2d: RT: NET-RED 10.1.1.0 255.255.255.0
lw2d: RT: SET_LAST_RDB for 192.168.253.0 255.255.255.0
NEW rdb: via 10.2.7.1
lw2d: RT: add 192.168.253.0 255.255.255.0 via 10.2.7.1, ospf metric [171/4]
lw2d: RT: NET-RED 192.168.253.0 255.255.255.0
lw2d: RT: SET_LAST_RDB for 192.168.254.0 255.255.255.0
NEW rdb: via 10.2.7.1
lw2d: RT: add 192.168.254.0 255.255.255.0 via 10.2.7.1, ospf metric [171/4]
lw2d: RT: NET-RED 192.168.253.0 255.255.255.0
lw2d: RT: closer admin distance for 192.168.254.0, flushing 1 routes
lw2d: RT: NET-RED 192.168.254.0 255.255.255.0
lw2d: RT: SET_LAST_RDB for 192.168.254.0 255.255.255.0
NEW rdb: via 192.168.1.2
Example 4-48 illustrates the resulting routing table entry on R2; R2 is now learning directly from R3. This is confirmed by the trace output shown in Example 4-49.
R2(config-router)#do show ip route | section 254
D EX 192.168.254.0 255.255.255.0
[170/2297856] via 192.168.1.2, 00:00:51, Serial0/0/0
R2(config-router)#
R2(config-router)#do trace 192.168.254.1
Type escape sequence to abort.
Tracing the route to 192.168.254.1
1 192.168.1.2 12 msec * 12 msec
R2(config-router)#
Figure 4-34 shows the resulting traffic flow.
The same configuration is also needed on R1. The configuration and resulting trace output is shown in Example 4-50.
R1(config)#router ospf 1
R1(config-router)#distance ospf external 171
R1(config-router)#do trace 192.168.254.1
Type escape sequence to abort.
Tracing the route to 192.168.254.1
1 192.168.2.2 16 msec * 12 msec
R1(config-router)#
This comprehensive example illustrated how routing updates can be controlled, using multiple methods, including prefix lists, route tagging, route filtering, and changing the administrative distance.
Summary
In this chapter, you learned about manipulating routing updates. The chapter focused on the following topics:
-
Network performance issues, including excessive routing updates, the presence of any route maps or filters, and the number of routing protocols running in the same autonomous system. Solutions to these issues include design changes, using passive interfaces, and route filtering (access lists, route maps, distribute lists, and prefix lists).
-
Reasons for using more than one routing protocol (migration, host system needs, mixed-vendor environment, political and geographical borders, MPLS VPNs), how routing information can be exchanged between them (referred to as redistribution), and how Cisco routers operate in a multiple routing protocol environment.
-
How route redistribution is always performed outbound. The router doing redistribution does not change its routing table.
-
Issues arising when redistributing routes, including routing loops, incompatible routing information, and inconsistent convergence times.
-
The roles that the administrative distance and the routing metric play in route selection. Lower administrative distances are considered more believable (better). Lower metrics are considered better, within the same routing protocol. When redistributing, a router assigns a seed metric to redistributed routes, using the default-metric router configuration command, or specified as part of the redistribute command either with the metric option or by using a route map.
-
The redistribution techniques, one-point and multipoint:
-
The two methods of one-point route redistribution: one way and two way. Suboptimal routing is a possible issue with these techniques.
-
The two methods of multipoint route redistribution: one way and two way. Multipoint redistribution is likely to introduce potential routing loops.
-
To prevent routing issues use one of the following options: Redistribute a default route from the core autonomous system into the edge autonomous system, and redistribute routes from the edge routing protocols into the core routing protocol; redistribute multiple static routes about the core autonomous system networks into the edge autonomous system, and redistribute routes from the edge routing protocols into the core routing protocol; redistribute routes from the core autonomous system into the edge autonomous system with filtering to block out inappropriate routes; redistribute all routes from the core autonomous system into the edge autonomous system, and from the edge autonomous system into the core autonomous system, and then modify the administrative distance associated with redistributed routes so that they are not the selected routes when multiple routes exist for the same destination.
-
-
Configuration of redistribution between various IP routing protocols:
-
To redistribute into RIP, use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command.
-
To redistribute into OSPF, use the redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value] router configuration command.
-
To redistribute into EIGRP, use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command.
-
-
Using the passive-interface type number [default] router configuration command to prevent a routing protocol’s routing updates from being sent through the specified router interface.
-
How to manipulate the administrative distance of routes to influence the route-selection process:
-
Use the distance administrative-distance [address wildcard-mask [ip-standard- list] [ip-extended-list]] router configuration command for all protocols.
-
Alternatively, for EIGRP, use the distance eigrp internal-distance external-distance router configuration command.
-
Alternatively for OSPF, use the distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]} router configuration command.
-
Alternatively, for BGP, use the distance bgp external-distance internal-distance local-distance router configuration command.
-
-
Using the show ip route [ip-address] and traceroute [ip-address] commands to verify route redistribution.
-
Using the ip route 0.0.0.0 0.0.0.0 interface or ip default-network network-number global configuration command to configure default routes.
-
Using route maps for route filtering during redistribution, PBR, NAT, and BGP.
-
The characteristics of route maps, configured using the route-map map-tag [permit | deny] [sequence-number] global configuration command:
-
Route maps allow some conditions to be tested against the packet or route in question using match commands. If the conditions match, some actions can be taken to modify attributes of the packet or route; these actions are specified by set commands.
-
A collection of route-map statements that have the same route map name is considered one route map.
-
Within a route map, each route-map statement is numbered and therefore can be edited individually.
-
The default for the route-map command is permit, with a sequence-number of 10.
-
Only one condition listed on the same match statement must match for the entire statement to be considered a match. However, all match statements within a route-map statement must match for the route map to be considered matched.
-
When used with a redistribute command, a route-map statement with permit indicates that the matched route is to be redistributed, while a route-map statement with deny indicates that the matched route is not to be redistributed.
-
-
Configuring route maps for PBR, using the ip policy route-map map-tag interface configuration command.
-
Table 4-15 lists some of the variety of match criteria that can be defined. Table 4-16 lists some of the variety of set commands that are available.
-
Distribute lists, allowing an access list to be applied to routing updates:
-
The distribute-list {access-list-number | name} out [interface-name | routing-process [routing-process parameter]] router configuration command assigns the access list to filter outgoing routing updates. This command filters updates going out of the interface or routing protocol specified in the command, into the routing process under which it is configured.
-
The distribute-list {access-list-number | name} [route-map map-tag] in [interface-type interface-number] router configuration command assigns the access list to filter routing updates coming in through an interface. This command filters updates going into the interface specified in the command, into the routing process under which it is configured.
-
-
Prefix lists, an alternative to distribute lists, with improvements in performance, support for incremental modifications, a more user-friendly command-line interface, and greater flexibility. Prefix lists are configured with the ip prefix-list {list-name | list-number} [seq seq-value] {deny | permit} network/length [ge ge-value] [le le-value] global configuration command. The ge-value and le-value range is length < ge-value < le-value <= 32. An exact match is assumed when neither ge nor le is specified.
-
Whether a prefix in a prefix list 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.
-
-
Prefix list sequence numbers:
-
Sequence numbers are generated automatically, unless you disable this automatic generation.
-
A prefix list is an ordered list. The sequence number is significant when a given prefix is matched by multiple entries of a prefix list, in which case the one with the smallest sequence number is considered the real match.
-
The evaluation of a prefix list starts with the lowest sequence number and continues down the list until a match is found, in which case the permit or deny statement is applied to that network and the remainder of the list is not evaluated.
-
-
Verifying prefix lists can involve commands listed in Table 4-20.
-
How multiple methods can be combined to effectively control routing updates.
0 comments
Post a Comment