UNDERSTANDING ROUTE-MAPS

Route Maps

Route maps are a network tool used to carry out pattern matching against network traffic and take specified actions to traffic that matches specified criteria or traffic that does not match. If the conditions match, actions can be taken to modify attributes of the packet. These actions are specified by the route-map's 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 are similar to the statements in an access control list.

Route map actions can be either permit or deny. Route map statements are processed sequentially from top to bottom with a first-match processing; just like an access list. The first statement that is matched in the route map ends the processing of the route map. This default behaviour can be modified by using the keyword continue. Route-maps have an implicit deny statement at the end.

Configuration

1. Define the route map: a route map is defined by specifying the route map name, processing action and sequence number. The command used is route-map <route-map-name> [permit | deny] <sequence-number> where:
   • permit | deny (Optional): Define the action to be taken if the route map match conditions are met i.e., what do we do with matched traffic? Processing actions consist of permit or deny. The meaning of permit or deny is dependent on how the route-map is used. The default action of a route-map command is permit. If a route-map references an ACL or prefix-list, the ACL and prefix-list permit statement means match this prefix. The deny statement means do not match the prefix.

     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.

   • sequence-number (Optional): 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. This is much like the sequence numbers of an access control list(ACL). The sequence number determines the order of processing of the route map. The first route map statement has a sequence number of 10 by default. Route-maps do not automatically increment the sequence number like ACLs. If no sequence number is entered, subsequent statements overwrite the first statement.
   If the permit / deny statement is not configured, and the sequence number is not configured, then the default action will be permit with a sequence number of 10.
2. Define the matching conditions using the match command and the optional action to be taken when each condition is matched using the set command. What characteristics of the traffic should be checked. If match statement is not configured, the default action is to match all addresses.
3. Action: Modifying characteristics of packets or traffic flow patterns. This is done using the set command.
4. Apply the route map.

Route Map Rules

The following are some important guidelines to consider when configuring a route map:

• When adding a new route map statement:
  • Route map sequence numbers do not increment automatically.
  • If no other entry is already defined with the supplied route-map name, an entry is created with the sequence number 10.
  • If only one entry is already defined with the configured route map name, that entry is the default entry for the route-map command, and the sequence number of the entry is unchanged.
  • If more than one entry is already defined with the configured route map name, an error message is displayed, indicating that the sequence number is required.
• The match statement is used to define the characteristics that traffic should match against.
• The set condition command is used to define the actions to be followed if there is a match and the action to be taken is permit.
• A route-map statement without any match statements will be considered matched.
• If deleting a route-map using the command no route-map <route-map-name> without specifying the sequence number, the whole route-map is deleted.
• Like an access-list, an implicit deny any statement appears at the end of a route-map. The conseqeunces of this "deny any" depends on how the where the route map is applied.
• If more than one condition is configured under the same match statement, then it acts as a logical OR function.
• If more than one match statement aears nder the same sequence number, then t acts as an AND logic statement.
• If more than one route map statement is configured, then route map acts as an If-Else-If statement block.
• To match all packets, the route-map clase mts the match command.
• If a sequence number is not included in the configuration of the first statement, the default sequence number or first sequence number is set to 10. Successive route map statements without sequence numbers overwrite the existing first route map statement with sequence number 10.
• When processing statements, the first match ends the processing of the route map even when there are more un-processed entries in the route map.

Matching Conditions

When configuring a route-map, the first action should be a match statement. Route-maps use the following features to match routes:

• Access control lists
• Prefix-lists
• Route-type
• Metric
• Metric type
• Next hop
• BGP attributes

Route maps use ACLs or prefix-lists match the prefixes. The route-map tells what to do with the matched routes using permit or deny. A permit action in the ACL or prefix list means match the prefix and a deny action means do not match the prefix. All ACLs types are supported i.e., named or numbered standard and extended ACLs. It is important to note that when matching prefixes, IPv4 and IPv6 prefixes cannot be matched in the same route map. Different separate route maps are required to match each protocol separately.

Route maps provide more flexibility when matching various characteristics of the traffic. Route maps map against IP addresses by referencing access-lists or prefix-lists. Additionally, the provide the ability to match against route-type, metric, metric-type, next-hop, BGP attributes etc.

Matching is done using the following commands:

Command	Action
match ip address [1-199 | 1300 - 1699 | acl-name]	Matches based on a referenced named or numbered access control list. 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 ip address prefix-list <prefix-list-name>	Matches based on a referenced prefix list.
match as-path <ASN-acl-number>	Matches prefixes based on a regular expression query to isolate the Autonomous System Number (ASN) in the BGP path attribute AS path. The AS path ACLs are numbered 1 - 500. This command allows for multiple match variables.
match length <min> <max>	matches based on a packet's Layer 3 length
match route-type [external | internal | level-1 | level-2 | local]	Matches packets of the specified type.
match interface <interface-id>	matches any routes that have the next hop out of one of the interfaces specified.
match ip next-hop <acl-1 acl-2 acl3>	matches any routes that have a next-hop router address permitted by one of the access-lists specified
match ip route-source <acl-1 acl-2 acl-3>	matches routes that have been advertised by routers and acccess servers that have an address permitted by one of the access lists specified.
match metric [<1-4294967295> | external <1-4294967295>] [+-deviation]	matches routes have the metric specified, a range, or within acceptable deviation.
match route-tpe [external | internal | level-1 | level-2 | local]	matches routes of the specified type.
match community <list-name | list-num>	matches a BGP community
match tag <0-4294967295>	matches based on the tag of a route that was set by another router. This command allows for multiple match variables.
match local-preference <local-preference>	Matches prefixes based on the BGP attribute local preference. This command allows for multiple match variables.

A route-map without the match statement is equivalent to match any.

When processing a route-map, the processing starts at the top with the lowest sequence number and progress sequentially. The first successful match ends the execution of the prefix-list except if the continue statement is used. A deny statement in the ACL/Prefix list that is referenced by a permit statement in the route map results in no match and execution of the route map moves to the next route map sequence number.

When matching prefixes, it is possible to chain ACLs or prefixes using the match ip address <acl-1> <acl-2> <acl-2> command. This represents an OR function where matching is done successfully if any of the ACLs is matched.

A deny statement in an ACL, prefix list or AS-Path ACL excludes the route from being matched. When matching using an ACL or prefix list, take note of the following:

ACL/Prefix-list Action	Route-map Action	Result
deny	permit

Set Actions

Specify the action to be carried out on matched routes (Optional): This is implemented using the set command. Supported features include the following:

Command	Action
set metric [+value | -value | <value>]	sets the metric value for a route or modifies the existing metric. Allowable values are in the range 0 - 4294967295.
set metric-type [type-1 | type-2 | internal | external]	sets the metric type for the destination routing protocol.
set default interface <interface-id>	Sets the output interface for packets that pass a match clause of a route map if there is no explicit route to the destination. If a list of interfaces is configured and the first interface is down, the next interface in the list is utilized.
set interface <interface-id>	sets the exit interface for packets that pass a match clause of a route map for policy routing.
set ip default next-hop <ip-address>	sets the next hop for 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 "blackholed" if the configured next hop becomes unavailable.
set ip next-hop <ip-address-1 ip-address-2 ip-address-3 | peer-address | self>	sets the next hop for packets that pass a match clause of a route map for policy routing. BGP dynamic manipulation uses the peer-address or self keywords.
set ip next-hop verify-availability	Forces the router to check the 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 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 | last-as 1-10>]	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-attribute>	Specifies a local preference value for the BGP autonomous system path.
set weight <0-65535>	Specifies the BGP weight value.
set origin [igp | incomplete]	Specifies the BGP origin code.
set tag	Specifies the tag value for the destination routing protocol.

continue command

Processing of route-maps starts with the lowest sequence number and proceeds sequentially, until a match statement thereafter, processing then stops. However, if a route-map statement has the continue keyword, processing continues in spite of the match statement. The continue keyword is used in route-map statements when logical "AND" processing is needed. the continue command causes the processing to continue processing the next match statements in the route-map.

Example Configuration

route-map DEMO permt 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 DMEO is interpreted as follows:

1. If ((X or Y or Z) and (A) match) then (set B and C)
2. Else
3. If Q matches then set R
4. Else
5. Set nothing

A route map without a match or set command such as route-map DEMO permit 40, matches all prefixes and permits all other prefixes. If this is the last sequence in a route map, it disables the implicit deny all command at the end of the route map.

Applications

Where route maps are applied depends on what they will be used for:

The flexibility of route maps means that they can be utilized in many routing scenarios such as the following:

• Route filtering such as between areas in OSPF, in any arbitrary location in EIGRP and BGP.
• Route filtering during Redistribution: Route maps offer the benefit of manipulating route metrics through the set commands. The route maps applied using the redistribute command.
• 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 determine the interface or next-hop address which the packet should be sent. The route-map is applied to an interface using the command: policy route-map interface configuration command.
• Traffic Engineering in BGP: in addition to filtering, route-maps provide traffic engineering opportunities such as manipulation of BGP path attributes such as the next hop, AS PATH, local preference, weight etc. on a neighbor-by-neighbor basis. The route-map is applied using the BGP neighbor router configuration command.

Filtering

When configuring filtering using prefix lists, only one prefix list can be used for filtering per direction(ingress or egress). However, when filtering using route maps, a route map can be configured with many statements each using different prefix lists.

When using a route map for filtering, the "permit" or "deny" within the ACL or prefix-list does not mean that route will be filtered or not. The permit and deny keywords are used to indicate that the prefix should be matched or not matched respectively. A permit statement in an ACL/prefix-list means take action in the route-map. A deny means move to the next route map statement. Different ACLs or prefix-lists can be called by the same route-map.

Given the following access-lists: access-list 50 permit 172.16.0.0 0.0.255.255
access-list 60 permit 192.168.0.0 0.0.255.255
access-list 60 deny 192.168.10.0 0.0.0.255
access-list 60 permit any

route-map TEST deny 10
match address 50
route-map TEST permit 20
match address 60


The route-map sequence number 10 means the route-map is permitted to deny traffc from 172.16.0.0 0.0.255.255

Redistribution

Uses the command redistribute route-map <route-map-name>.

Prefix Advertisement: Filtering of prefixes when during advertisement using a routing protocol uses the command distribute-list route-map <route-map-name>

Attribute Manipulation

use the command neighbor <ip-address> route-map <route-map-name>

Path Control

To utilise the route map, it has to be applied to an interface. When applying a route-map, it should be applied in the ingress interface. Applying a route-map to the egress interface has no effect. To associate the route-map, use the command: policy route-map <route-map-name>

To utilise the route map, it has to be applied to an interface (policy based routing) or a routing protocol.

When applying a route-map, it should be applied n the inbound interface. Applying a route-map in the outgoing interface has no effect. T0 associate the route-map, use the command: ip policy route-map <route-map-name>.

use the ip policy route-map <route-map-name> command under the interface. Details of how route maps are used for path control are explained here: HERE

Redistribution Caveats

Redistribution of routing information adds to the complexity of a network and increases the potential for routing confusion, so you should use it only when necessary. The key issues that arise when you are using redistribution are as follows:

• Routing loops
• Incompatible routing information
• Inconsistent convergence time

Verification

show route-map <route-map-name>

Verify what was configured. This displays all route maps configured. The specific route map name can be added show route-map <-route-map-name>

ROUTE REDISTRIBUTION

Overview

Redistribution is the process of taking routes from the routing table and injecting them into a routing protocol. The source of the injected routes could be any of: connected routes, static routes or routes from another routing protocol that are in the routing table (RIB). Sourcing routes from the RIB implies that;

1. the best routes are redistributed.
2. Loop-free routes are redistributed.

The routing device performing the redistribution participates in the routing domain of the source and destination of the redistributed routes; for instance, if redistributing routes from OSPF into BGP, the redistributing device participates in the OSPF routing domain as well as the BGP routing domain.

Reasons for Redistribution

An enterprise may implement redistribution for one or more of the following reasons:

1. A company merger where the networks of both companies run different routing protocols.
2. Different organizational department networks are under different network administrative control perhaps based on geography.
3. An organization inter-connecting with partner networks
4. Hardware constraints such routing devices with low memory, CPU.
5. During conversion or migration from one routing protocol to another.
6. Mixed vendor environment.
7. Support for legacy equipment in the network.
8. Application-specific protocols support.
9. IGP routes may need to be advertised into BGP.
10. Some BGP routes may need to be advertised into an IGP.
11. Political boundaries.

Types of Redistribution

Redistribution can be implemented in two ways:

• Unidirectional Redistribution (one-way redistribution): routes are redistributed from the source to the destination protocol on a single routing device in one direction. Conceptually, this type of redistribution is similar to multipoint one-way redistribution where redistribution is implemented on more than one routing device but in the same direction i.e. from source X to destination Y.

  Creation of routing loops in one-way redistribution is not possible. Usually one way redistribution occurs when redistributing from a source that is not a routing protocol such as default routes or static routes. Rarely is one-way redistribution implemented with the source being a routing protocol.

• Mutual Redistribution (two-way redistribution): Mutual redistribution occurs when routes from routing protocol X are injected into routing protocol Y and routes sourced from routing protocol Y are injected into routing protocol X on the same routing device. Mutual redistribution can be thought of as a form of route connversion. Mutual redistribution can be implemented on a single routing device in the network (single-point two-way redistribution) or on two or more routing devices (multipoint two-way redistribution).

  Multipoint mutual redistribution has a high-potential for introducing routing loops. These routing loops can be prevented from occuring using: access-lists or prefix-lists referenced by route-maps. One of the most scalable solutions for preventing routing loops introduced by route redistribution is through the use of route-tags.

Mutual multipoint redistribution provides the benefit of fault-tolerence where the failure of a redistributing device at one point does not affect traffic across both routing domains.

Sources of Routes

Route Source	Description
Connected	Any interface in an "Up" state that is not associated with the destination protocol. Secondary IP addresses are also redistributed.
Static	Any static route that is present in the RIB. Static routes can only be a source i.e. mutual redistribution can not be implemented with static routes.
OSPF	Any routes in the RIB sourced from OSPF. If redistributing from OSPF to BGP, by default, OSPF external routes are not redistributed into BGP unless the match external option is used.
EIGRP	Any routes in the RIB sourced from EIGRP including connected interfaces. Any route that is in the topology table will be redistributed.
BGP	Any routes in the RIB sourced from BGP. By default, routes learned from iBGP peers are not redistributed into IGP protocols unless the command redistribute internal is configured.
IS-IS	Any routes in the RIB sourced from IS-IS. Only routes from the L2 link-state database are selected. Directly connected networks are not included during redistribution.

Redistribution Rules

1. Redistribution is not transitive: Routes that have been redistributed into a routing protocol can not be further redistributed into a third routing protocol on the same routing device. To resolve this, mutual redistribution should be configured between routing protocol A and B, B and C and A with C.
2. Sequential redistribution is allowed when it is spread across multiple routers: Redistributed routes from protocol A into Protocol B on Router R1. These routes can be redistributed into protocol C on router R2.
3. Routes to be redistributed must be in the routing table.

Seed Metric

During redistribution, metric information of the redistributed routes is lost because the different routing protocols calculate route metrics using different methods. Route metrics are only maintained when redistribution occurs from one routing process or autonomous system to another with the same routing protocol.

Seed metric is assigned, by default, to redistributed routes, when no metric is manually configured. The redistribution metric of redistributed routes can be configured in the following ways:

• Using the metric keyword of the redistribution command.
• Configuration of a default metric where all redistributed routes into the destination routing protocol receive the configured default seed metric. This can be implemented using the command default-metric.
• Using a route-map with the metric command.

The recommended best practice from Cisco is to set a default metric when redistributing routes.

The following table shows the seed metric of routes when redistributing from one routing protocol to another.

	DESTINATION
SOURCE	RIP	EIGRP	OSPF	IS-IS	BGP
RIP	Metric maintained	Infinity	20	0	RIP Metric*
EIGRP	Infinity	Metric maintained	20	0	EIGRP Metric*
OSPF	Infinity	Infinity	Metric maintained	0	OSPF Metric*
BGP	Infinity	Infinity	1	0	Path attributes maintained

* The IGP metric becomes the MED path attribute of the prefix.

Routes with the default redistribution metric of infinity are installed into the Link-state database (OSPF), BGP table (BGP) or similar data structures of the destination routing protocol. These routes are not inserted into the routing table because they are considered unreachable due to their metric of infinity. EIGRP does not add routes with infinity metric to its topology table.

When redistributing between two same routing protocols but different processes or autonomous systems, the metric remains unchanged because the destination protocol understands the metric of the source protocol. For example OSPF process 1 to OSPF process 2, the metric of the redistributed routes remains the same.

When redistributing connected networks (on local interfaces),

Configuration of Redistribution

When redistributing routes into a routing protocol from another routing domain, there are many controls that can be implemented that the redistribution point such as tagging, metric configuration, filtering of redistributed routes.

When configuring redistribution, redistribution commmands are entered into the router configuration mode of the destination routing protocol. In a way, the redistribution configuration command says: "Redistribute routes from the specified routing source into this routing source."

EIGRP

Any route that is in the EIGRP topology table is a candidate for redistribution. Routes redistributed into EIGRP are given a default seed metric of infinity. This prevents the routes from being installed into the EIGRP topology table. The exception to this is when redistributing routes from one EIGRP autonomous system to another. In such a scenario, the path metric is maintained.

In IOS, routes redistributed into EIGRP have an administrative distance of 170. This administrative distance is the same regardless of the source routing protocol i.e. even if the source of the prefixes was another EIGRP autonomous system.

Redistribution is configured under the EIGRP router command:

redistribute <source> <metric> <bandwidth> <delay> <reliability> <load> <mtu> route-map <route-map_name>

where <source> is the source of the redistributed routes.

In EIGRP named mode, redistribution is configured under topology base configuration mode as shown below:

R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast autonomous-system 1
R2(config-router-af-topology)#redistribute ospf 1


In EIGRP classic mode, redistribution is configured under EIGRP router configuration mode as shown below:

R2(config)#router eigrp 1
R2(config-router)#redistribute ospf 1


When configuring the EIGRP redistribution seed metric, delay value is in tens of microseconds.

When redistributing BGP routes into EIGRP, the administrative tag is set to the autonomous system number of the BGP device that sent the prefixes.

EIGRP requires the configuration of a seed metric during redistribution. If the seed metric is not included in the redistribution, EIGRP will give the route a metric of infinity.

In IPv4, by default, connected routes that are associated with EIGRP will have their configured network addresses included in a redistribution. However, with IPv6, by default, they are not included redistributed. Some connected interfaces may not necessarily be destination networks for network traffic such as transit networks. However, during redistribution, it may be a good idea to redistribute these networks as well as it may sometimes result in traffic blackholing. This is especially likely when utilising some tunneling techniques such as MPLS tunneling.

Redistribution of routers into EIGRP can be implemented using the following EIGRP routing device command: redistribute <source> metric <bandwidth delay reliability load mtu>

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number.

OSPF

In OSPF, the routing device that redistributes external routes into OSPF is referred to as an autonomous system boundary router (ASBR).

When redistributing routes into OSPF, redistributed routes are given an administrative distance of 110 and are flagged as OSPF external routes. The AD is similar to the administrative distance of intra-area and inter-area routes. When making forwarding decisions for routes from multiple sources, OSPF's prefix selection process gives preference in the following order:

1. intra-area routes
2. inter-area routes
3. external routes
1. external type 1 routes
2. external type 2 routes

The metric for OSPF external type 1 routes equals the redistribution metric plus the total path metric to the autonomous system boundary router. The metric for OSPF external type 2 metric equals only the redistribution metric. If two type 2 routes have the same metric, then the one with the lower forwarding cost is preferred. This is the default external metric type used by OSPF.

When configuring redistribution into OSPF, the OSPF router mode command redistribute is used.

redistribute <source> subnets metric <metric> metric-type (<1 | 2>) tag <0 - 4294967295> route-map <route-map-name>

Where:

• source: the source of routes
• metric: seed metric of the redistributed routes
• route-map: filtering can be applied using the route-map or route path information

In older IOS versions, if the optional subnets command is excluded, only classful routes are advertised. In newer IOS versions, the subnets keyword is automatically added by the IOS into the running configuration.

Redistributing routes between OSPF processes will preserve the path metric during redistribution regardless of the metric type.

To inject EIGRP sourced routes into OSPF:

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 1 subnets

OSPF Forwarding Address

By default, packets destined for external destinations are routed through the advertising autonomous system boundary router (ASBR). Scenarios like this are not optimal in certain circumstances. By default, OSPF sets the forwarding address value to 0.0.0.0. The forward address can be viewed using the command show ip ospf database external.

OSPF will change the forwarding address from 0.0.0.0 to the next-hop IP address in the source routing protocol when:

• OSPF is enabled on the ASBR's interface that points to the next-hop IP address of the redistributed routes.
• The interface is not set to passive.
• The OSPF interface type is set to a broadcast or non-broadcast type.

Enabling OSPF on R2's interface facing towards R1 (10.123.1.1) changes the forwarding address from 0.0.0.0 to the interface pointed towards R1. The forwarding-address changes on R3 irrespective of whether redistribution is configured on R3.

When redistributing OSPF prefixes into another routing protocol, IOS provides the option to match internal, external or NSSA-external routes. This can be useful in preventing the redistribution of external OSPF routes into another routing protocol.

When redistributing into OSPF, the optional subnets keyword results in subnets being included in the redistribution. In newer IOS versions the subnets keyword is automatically included by default if the keyword was not configured.

OSPF External Route Types

OSPF classifies redistributed routes as external type 1 and external type 2 routes. By default, OSPF classifies routes as external type 2 routes.

OSPF issues redistributed routes with a default metric of 20. OSPF external type 1 routes are redistributed with the default metric of 20 and maintain this same metric throughout the OSPF autonomous system. OSPF external type 2 routes have a default metric of 20 or configured redistribution metric. However, as the routes are distributed within the OSPF domain, the metric does not increase.

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number. When redistributing BGP into OSPF, the subnets keyword is automatically added to the redistribution command.
EIGRP	redistribute eigrp

BGP

Redistributing routes into BGP does not require a seed metric because it is a path vector protocol. Redistributed routes have the following BGP attributes set:

• Origin is set to incomplete
• Next-hop address is set to the next-hop IP address identified in the source protocol.
• The weight is set to 32,768.
• The MED is set to the path metric of the source protocol.

Redistributing routes from OSPF to BGP does not include OSPF external routes by default. The optional match external (1 | 2) keyword is required to redistribute OSPF external routes. The type of OSPF external routes can be configured using 1 or 2 to redistribute type-1 or type-2 routes only.

Protocol	Command
OSPF	redistribute ospf <process> where <process> is the OSPF process ID. When redistributing OSPF routes into BGP, by default, only internal OSPF routes are redistributed into BGP. To redistribute external and nssa-external OSPF routes into BGP, list route type after the redistribute match keyword. With the match keyword external type 1 and/or type 2 routes can be matched. Additionally, the route match can be configured in a route-map.

Formation of Loops

If redistribution happens at one point (one routing device) or two points in one direction, the possibility of a routing loop does not exist. If mutual redistribution at more than one point occurs, then the possibility of loop formation exists.

Route feedback occurs when a redistributed route is advertised back into the original source routing protocol. Route feedback is likely to occur in networks where mutual redistribution is implemented in more than one device i.e. multipoint mutual redistribution. Route feedback causes:

• Sub-optimal routing
• Routing loops
• Invalid routing tables

Types of Loops

Loops exist in two categories:

• Control-plane: exist when routing information is looping. Control-plane loops are detected using the debug ip routing command. This command is largely silent. However, it will display when a route is added or removed from the routing table. If this happens repeatedly, then we can be certain that we are dealing with a loop. Redistribution should be done after observing the debug ip routing output for a while.
• Data-plane: occur when data packets are looping. The best way to detect data-plane loops is to use the ping and traceroute commands. If traffic is being dropped, then a black hole exists. Looped packets may include packets for known networks (in RIB) or unknown networks (default route). With mutual multipoint redistribution, it is also likely that the default route may be looped.

Troubleshooting Loops

Mutual multipoint route redistribution usually forms routing loops. The following techniques can be used to prevent the formation of routing loops during redistribution:

1. Filtering of network prefixes during redistribution.
2. Filtering by route tag during redistribution
3. Increasing the seed metric
4. Modifying the administrative distance.
5. Route summarization

When troubleshooting routing loops:

• Multiple techniques can be combined.
• Document the physical and logical topology to include the routing protocols and desired traffic flows.
• Focus on keeping the source routing domain loop-free.

The underlying principle in preventing the formation of loops in a multipoint mutual redistribution network, at each redistribution point, routes from a source protocol need to be allowed into the destination protocol and these routes prevented from returning from the destination routing protocol back to the source protocol.

Prefix Filtering

Prefixe filtering can be implemented during the redistribution with some prefixes filtered (preventing from being redistributed) on one redistribution device and permitted to be redistributed on another device. This can be used for controlled path manipulation.

Route filtering can be implemented during redistribution through the configuration of a route-map. The prefixes to be filtered are identified through the use of a prefix-list or access control list (ACL).

Filtering Connected Networks

Explicit configuration always overrides implicit configuration. When redistributing the networks assigned to connected interfaces, the use of the network command advertises the networks of the connected interfaces. However, when filtering, if a filter excludes these networks, the networks configured on these interfaces will not be advertised. This affects all IGP protocols that use interfaces to form neighborships such as OSPF, EIGRP. BGP behaves a little different as it is enabled on a per neighbor- basis and not per interface basis. If a route-map references an access list or prefix-list to identify interfaces to be filtered (not redistributed), these interfaces should be identified using the permit ACL keyword.

Route Tagging

A route tag is associated with routes during redistribution. A route-tag is a numeric value associated with a route. Use of the AD of the source protocol for the route-tag is a good technique.

The use of route-tags is a more scalable solution. In the case of prefix-lists and ACLs, everytime a new prefix is added, the prefix-list or ACL needs to be updated to reflect this new addition. When creating route-tags, a recommended best practice is to tag routes using the administrative distance of the routing protocol. This way, it is easier to tell the origin of the route.

Increase Seed Metric

Increase the seed metric to a value higher and less preferred to locally originated routes.This can be done through any of the seed metric configuration methods.

Configuring different seed metric values for different prefixes helps with preventing sub-optimal routing through traffic shaping. The redistribution metric on one redistributing device can be made lower so that to reach these prefixes, traffic transits through a specific path.

The seed metric can be modified through a route-map using the set metric command.

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 12 msec 16 msec 20 msec
  2 10.0.24.2 28 msec 64 msec 44 msec
  3 10.0.49.2 52 msec 16 msec 72 msec
  4 10.0.59.1 48 msec 68 msec 60 msec
  5 10.0.35.1 88 msec 28 msec 36 msec

R3(config)#ip access-list standard ACL_10.3
R3(config-std-nacl)#permit 10.0.35.0 0.0.0.3
R3(config-std-nacl)#20 permit 10.3.0.0 0.0.255.255
R3(config-std-nacl)#30 permit 10.0.59.0 0.0.0.3
R3(config-std-nacl)#40 permit 10.5.0.0 0.0.255.255
R3(config-std-nacl)#exit
R3(config)#route-map O2E permit 10
R3(config-route-map)#match ip address ACL_10.3
R3(config-route-map)#set metric 1000000 1 255 1 1500
R3(config-route-map)#set tag 110
R3(config)#router eigrp 1
R3(config-router)#redistribute ospf 1 route-map O2E

R1#show ip eigrp topology 10.0.35.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.1.13.1) for 10.0.35.0/30
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1966080, RIB is 15360
  Descriptor Blocks:
  10.0.13.2 (GigabitEthernet1/0), from 10.0.13.2, Send flag is 0x0
      Composite metric is (1966080/1310720), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 3.3.3.3
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0
        Administrator tag is 110 (0x0000006E)
  10.0.12.2 (GigabitEthernet0/0), from 10.0.12.2, Send flag is 0x0
      Composite metric is (7864320/7208960), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 110000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.2.13.1
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 4
        Administrator tag is 0 (0x00000000)
R1#

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.13.2 8 msec 44 msec 16 msec
R1#


Administrative Distance

Increase the administrative distance for external routes on routing protocols that support it. Alternatively, the AD can be modified for preferred routes.

External Route Summarization

Summarizing routes as they are redistributed into the second domain if they are re-inserted back to primary routing domain. They are less specific and not taken.

Route-Maps

Route-maps can be used to prevent the formation of routing loops. Tools to match the traffic include: access-lists, prefix-lists, route-tags, communities (BGP), administrative distance, distribute-lists(ACLs, prefix-lists), offset-lists(ACLs, prefix-lists).

In redistribution of EIGRP to OSPF, using route-tags, the tag for EIGRP is permitted on one mutually redistributing routing device and denied on another redistributing routing device.

For two protocols mutual redistribution at two points: R1 BLUE:
route-map o2E deny 10
match tag 90
route-map O2E permit 20
set tag 110
R1 RED
riyte-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90
R2 RED
route-map O2E deny 10
match tag 90
route-map O2E permit 20
set tag 110

R2 BLUE
route-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90


Redistribution Scenarios

Two-point Mutual Redistribution

Three-point Mutual Redistribution

If three protocols are involved in mutual redistribution at three points. The generic method to prevent the formation of routing loops when redistributing mutually between three or more protocols inside a route map:

1. deny destination protocol
2. match protocol 2
3. match protocol 3
4. match protocol 4
5. match protocol n

The challenge with this redistribution is if the tag will be maintained when redistributing from protocol 1 to protocol 2 and then to protocol 3. For example when redistributing from OSPF into EIGRP and subsequently into RIP. The tag is maintained when copying the routes from:

This may be IOS specific

Source	Destination	Tag Maintained
RIP	OSPF	Yes
RIP	OSPF	YES
EIGRP	RIP	NO
OSPF	RIP	NO
EIGRP	OSPF	YES
OSPF	EIGRP	YES

A solution would be for the following:

route-map O2E deny 10
match tag 90
route-map O2E permit 20
match tag 120
set tag 120
route-map O2E permit 30
set tag 110


The above route-maps will only operate if configured as a system on all the mutually redistributing routers. The route-maps will operate as a system and potentially prevent loops in 99.999% of the cases.

However, some situations exist where the above route-map will not succeed in preventing a routing loop.

When configuring redistribution, the configuration commands should be entered inside the destination routing protocol.

IPv6

By default, IPv6 does not include connected networks when doing redistribution. IPv6 does not include the subnets keyword in OSPFv3. This is because IPv6 does not necessarily use the concept of classful networks. To redistribute connected networks, use the keyaword include-connected.

IOS XE no longer redistributes the connected subnets on the interfaces over which the protocol is enabled. IOS XE routers will only redistribute route entries that exactly match the source protocol in the route table.

The keyword included-connected can be used with the redistribution command to include the locally connected prefixes in the dynamic routing protocol redistribution. The include-connected keyword only injects prefixes for interfaces that have a dynamic routing protocol enabled. To inkect networks for interfaces without a dynamic protocol the redistribute connected command is still required.

TODO : Redistribute some local interfaces and not others. This results in the IP address of the excluded connected interfaces being removed from the routing table. The solution is to include a match statement for that interface in the route map. Redistribution lABS ----------------------------------- -Configure RIP, redistribute OSPF -Configure EIGRP. redistribute to/from RIP, redistribute to/from OSPF -Configure OSPF: redistribute where possible for full connectivity.