Pages

Showing posts with label Redistribution. Show all posts
Showing posts with label Redistribution. Show all posts

Saturday, 15 July 2023

ROUTE REDISTRIBUTION

Redistribution

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.

Redistribution enables multi-protocol routing environments. 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.

Redistribution requires careful planning to avoid the formation of routing loops and traffic black holes.

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.

  • 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 conversion. 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 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 configured in the destination routing process.
  • Using a route-map with the set 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 value of the MED path attribute of the prefix.

Routes with the default redistribution metric of infinity are installed into the 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):

  • Routing Information Protocol (RIP): RIP uses hop count as its metric.   When redistributing connected routes into RIP, the default metric is typically 1 hop. You can usually configure this metric manually. If no metric is specified, some implementations might default to 0, which could prevent the routes from being advertised.
  • Open Shortest Path First (OSPF): OSPF uses a cost metric based on bandwidth.   When redistributing connected routes into OSPF, the default metric is usually 20. However, this can vary depending on the vendor and configuration. It's common practice to set a specific metric using the metric keyword under the redistribute connected command in the OSPF configuration. You might also need to specify a metric-type (Type 1 or Type 2 external route).  
  • Enhanced Interior Gateway Routing Protocol (EIGRP): EIGRP uses a composite metric based on bandwidth, delay, reliability, load, and MTU. When redistributing connected routes into EIGRP, you must specify the metric using the metric keyword followed by the five metric components (bandwidth in kbps, delay in microseconds, reliability from 0-255, load from 1-255, and MTU). If you don't specify a metric, EIGRP will not redistribute the connected routes.  
  • Border Gateway Protocol (BGP): BGP uses a path-vector routing protocol with a variety of path attributes to determine the best path. The metric in BGP is the MED (Multi-Exit Discriminator).   When redistributing connected routes into BGP, you can set the MED value using the metric keyword under the redistribute connected command in the BGP configuration. If no metric is specified, the MED will be 0 by default.

Configuration of Redistribution

When redistributing routes into a routing protocol from another routing domain, there are many controls that can be implemented at 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 protocol."

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. The following illustrations configure redistribution with the following metrics: Bandwidth (10000 Kbps), Delay (100 μs), Reliability (255/255), Load (1/255), MTU (1500).

  • 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)#topology base
    R2(config-router-af-topology)#redistribute ospf 1 metric 10000 10 255 1 1500

  • Classic mode: redistribution is configured under EIGRP router configuration mode as shown below:

    R2(config)#router eigrp 1
    R2(config-router)#redistribute ospf 1 metric 10000 10 255 1 1500

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.

In IPv4, by default, connected routes that are associated with EIGRP will have their configured network addresses included during 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.

Source Command Metric Requirements Notes
BGP redistribute bgp <ASN> where <ASN> is the BGP autonomous system number. Metric required; BGP routes may have higher AD (use distance to adjust if needed). Use bgp redistribute-internal to redistribute BGP routes not in the routing table.
Connected Routes redistribute connected [metric] Requires explicit metric or default-metric Use redistribute connected under EIGRP process.
Static Routes redistribute static [metric] Must define metric or use default-metric Redistributes all static routes
OSPF redistribute ospf [process-id] [metric] Specify metric; optionally filter with match [internal | external | nssa] Example: redistribute ospf 100 match external type-5
RIP redistribute rip [metric] Metric required to ensure consistency across domains Use redistribute rip under EIGRP; add subnets for classless support.
IS-IS redistribute isis [metric] Define metric; ensure IS-IS routes are in the IP routing table. Use redistribute isis under EIGRP proces
EIGRP redistribute eigrp [AS-number] [metric] Metric required; avoid loops by using route-maps or tags. Redistribute between EIGRP ASes (e.g., redistribute eigrp 100.

Configuration example:

router eigrp 100
default-metric 10000 100 255 1 1500 // Sets default metric for all redistributed routes
redistribute connected
redistribute static
redistribute rip 1
redistribute ospf 100 match external type-5
!

OSPF

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.

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

When configuring redistribution into OSPF, the following command 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 keyword is excluded, only classful routes are advertised and the following notification message is displayed:

R2(config-router)#redistribute eigrp 1
% Only classful networks will be redistributed
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.

OSPF External Route Types

OSPF categorizes redistributed routes as external type 1 and external type 2 routes. By default, OSPF classifies redistributed 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 the metric increases downstream from the ASBR. 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.

Source Command Metric Requirements Comments
Connected Routes redistribute connected [subnets] Use metric (cost) or default-metric. Add subnets for non-classful routes. Connected routes require subnets keyword to include subnetted routes
Static Routes redistribute static [subnets] Define metric (cost) or use default-metric. Add subnets for non-classful routes. Static routes must exist in the IP routing table.
RIP redistribute rip [subnets] Specify metric (cost) and metric-type (E1/E2). Add subnets for classless support. Example: iredistribute rip metric 100 metric-type 1
EIGRP redistribute eigrp [AS-number] Define metric(cost) and metric-type . Optionally use route-map for filtering. Example: redistribute eigrp 100 metric 150
IS-IS redistribute isis [level-1/level-2] Specify metric (cost) and metric-type. Ensure IS-IS routes are in the IP routing table. Example: redistribute isis level-1 metric 200
BGP redistribute bgp [AS-number] Define metric (cost) and metric-type. Use bgp redistribute-internal for iBGP routes. Example: redistribute bgp 65001 metric 100 metric-type 2
Another OSPF Process redistribute ospf [process-id] Specify metric (cost) and metric-type . Avoid loops with route-map or tags. Rarely used; mutual redistribution requires careful planning.

Key Considerations for OSPF Redistribution

  1. Metric (Cost):
    • Use metric to define the cost for redistributed routes.
    • Use default-metric under the OSPF process to set a global default cost. Example: router ospf 100 default-metric 100
  2. Metric-Type :
    • Type-1 (E1) : Cost is cumulative across the OSPF domain.
    • Type-2 (E2) : Cost remains static (default).
    • Specify with metric-type 1 or metric-type 2.
  3. Route-Maps: Use route-map [map-name] to filter or modify attributes during redistribution. Example: router ospf 100 redistribute eigrp 100 route-map EIGRP-TO-OSPF
  4. Administrative Distance (AD) : Adjust AD with distance ospf [external 150] to prioritize redistributed routes if needed.
  5. Loop Prevention :
    • Use route-tag or distribute-lists to avoid routing loops during mutual redistribution.
    • In NSSA areas, use type-7 LSAs for redistribution (converted to type-5 by ABR).
  6. Subnets: Always add subnets to redistribute non-classful routes (e.g., redistribute static subnets).

Example Configuration Snippet

router ospf 100
default-metric 100 ! Sets default cost for redistributed routes
redistribute connected subnets ! Redistributes connected routes
redistribute static subnets metric 150 metric-type 1
redistribute rip subnets route-map RIP-TO-OSPF
redistribute eigrp 100 metric 200 metric-type 2
redistribute bgp 65001 metric 50
!
route-map RIP-TO-OSPF permit 10
match ip address 1
set metric 100
set metric-type type-1

Summary

  • Metric : Always define metric or use default-metric.
  • Type : Choose between E1 (dynamic cost) and E2 (static cost).
  • Filters : Use route-map or distribute-list for granular control.
  • NSSA Areas : Use type-7 LSAs for redistribution in stub/NSSA areas.

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.

Redistribution into BGP Configuration Table

Source Syntax Parameters Notes
Connected Routes redistribute connected [route-map] Use route-map to set origin, med, weight, or community. Connected routes must exist in the routing table. Use ip route 0.0.0.0 0.0.0.0 Null0 for summary routes.
Static Routes redistribute static [route-map] Define attributes via route-map (e.g., set origin, set med). Static routes must be present in the routing table. Avoid redistributing default routes unless necessary
RIP redistribute rip [route-map] Use route-map to set origin, med, and filter unwanted routes. Ensure RIP routes are in the IP routing table. Use match ip address in route-maps for filtering.
EIGRP redistribute eigrp [AS-number] [route-map] Set origin, med, and as-path via route-map. Adjust AD if needed. EIGRP routes must be in the routing table. Use match metric-type to filter internal/external routes.
OSPF redistribute ospf [process-id] [route-map] Set origin, med, and filter with match internal/external/nssa. Example: redistribute ospf 100 match external type-5. Use subnets for non-summarized routes.

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.

IS-IS redistribute isis [process-id] [route-map]. Set origin, med, and filter via route-map. IS-IS routes must be in the IP routing table. Use match isis-level-1/level-2 for granular control.
Another BGP Process Not typical; use import/export policies Use neighbor route-map or vrf import/export for inter-process communication. Avoid mutual redistribution loops. Use as-path prepending or community tags for control.

Key Considerations for BGP Redistribution

  • Route-Maps: Always use route-map to control redistribution and set attributes. Example:
    route-map STATIC-TO-BGP permit 10
       match ip address 1
       set origin igp
       set med 100
  • Origin Codes: Redistributed routes default to incomplete (?). Use set origin igp or set origin egp in route-maps to override. Example:
    set origin igp ! Marks routes as originating from an IGP
  • MED (Multi-Exit Discriminator): Influences inbound traffic from external neighbors. Set via set metric in route-maps. Example:
    set metric 50 ! Sets MED value for route selection
  • Administrative Distance (AD): BGP routes inherit the AD of their source (e.g., static = 1, OSPF = 110). Adjust with distance bgp . Example:
    distance bgp 20 200 255 ! External BGP routes have AD 20, internal 200
  • Loop Prevention: Use as-path access lists or community attributes to prevent loops during mutual redistribution. Example:
    ip as-path access-list 1 deny _65001$ ! Blocks routes originated in AS 65001
  • Maximum Prefixes: Limit redistributed routes with maximum-prefix to avoid instability. neighbor 192.168.1.2 maximum-prefix 1000 ! Limits prefixes to 1000 Example Configuration Snippet
    router bgp 65001
       bgp router-id 1.1.1.1
       redistribute static route-map STATIC-TO-BGP
       redistribute ospf 100 route-map OSPF-TO-BGP
       neighbor 192.168.1.2 remote-as 65002
       neighbor 192.168.1.2 activate
       neighbor 192.168.1.2 soft-reconfiguration inbound
    !
    route-map STATIC-TO-BGP permit 10
       match ip address 1
       set origin igp
       set metric 100
    !
    route-map OSPF-TO-BGP permit 10
       match ip address 2
       set origin incomplete
       set metric 200

Summary

  • Route-Maps: Mandatory for filtering and attribute manipulation.
  • Origin Codes: Control path selection with origin igp, egp, or incomplete.
  • MED: Influences inbound traffic; set via set metric>
  • AD: Adjust with distance bgp if needed.
  • Loop Prevention: Use as-path filters or communities.

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

Prefix filtering can be implemented during the redistribution with some prefixes filtered (prevented 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

Two-Way Multipoint Redistribution

Two-way multipoint redistribution occurs when routes are exchanged bidirectionally between two routing protocols at multiple redistribution points (e.g., two routers redistributing between OSPF and EIGRP). While this provides redundancy and flexibility, it introduces risks of routing loops , suboptimal paths , and route feedback . Proper configuration and loop prevention techniques are critical.

Configuration Example

Topology

  • Routers : R1 and R2

  • Protocols :

    • OSPF (Process ID 100) for the core network.

    • EIGRP (AS 1) for the edge network.

  • Redistribution : Both routers redistribute routes between OSPF and EIGRP in both directions.

Basic Configuration

! R1 Configuration
router eigrp 1
redistribute ospf 100 metric 1000 100
255 1 1500
default-metric 1000 100 255 1 1500
!
router ospf 100
redistribute eigrp 1 subnets
default-metric 100


! R2 Configuration
router eigrp 1
redistribute ospf 100 metric 1500 150
255 1 1500
default-metric 1500 150 255 1 1500
!
router ospf 100
redistribute eigrp 1 subnets
default-metric 100>

Loop Prevention Techniques

Without safeguards, routes redistributed at R1 could be re-advertised back into OSPF/EIGRP at R2, creating loops. Below are techniques to mitigate this:

  1. Route Tags: Use route tags to mark redistributed routes and filter them during redistribution. Assign a unique tag (e.g.,TAG_EIGRP=100, TAG_OSPF=200) to routes when redistributing. Filter routes with the same tag when redistributing back to avoid feedback.

    ! R1: Mark EIGRP routes redistributed into OSPF with tag 100
    router eigrp 1
    redistribute ospf 100 metric 1000 100
    255 1 1500 route-map TO_EIGRP
    !
    route-map TO_EIGRP permit 10
    set tag 100




    router ospf 100
    redistribute eigrp 1 subnets route-map
    TO_OSPF
    !
    route-map TO_OSPF permit 10
    match tag 100 ! Drop routes already
    tagged as redistributed from EIGRP
    deny
    !
    route-map TO_OSPF permit 20 ! Allow
    all other routes
    set tag 200 ! Tag OSPF routes
    redistributed into EIGRP




    ! R2: Similar configuration with
    inverse tags
    router eigrp 1
    redistribute ospf 100 metric 1500 150
    255 1 1500 route-map TO_EIGRP_R2
    !
    route-map TO_EIGRP_R2 permit 10
    set tag 100




    router ospf 100
    redistribute eigrp 1 subnets route-map
    TO_OSPF_R2
    !
    route-map TO_OSPF_R2 permit 10
    match tag 100
    deny
    !
    route-map TO_OSPF_R2 permit 20
    set tag 200

  2. Distribute-Lists: Filter specific routes using access control lists (ACLs) or prefix lists during redistribution. Define a list of networks to exclude from redistribution (e.g., subnets already present in the target protocol).

    ! R1: Block redistribution of 192.168.1.0/24 from EIGRP to OSPF
    ip access-list standard BLOCK_EIGRP_SUBNETS
    deny 192.168.1.0 0.0.0.255
    permit any


    router ospf 100
    redistribute eigrp 1 subnets
    distribute-list BLOCK_EIGRP_SUBNETS in

  3. Administrative Distance (AD): Adjust AD to prioritize internal routes over redistributed ones. Redistributed routes typically have higher AD. For example, EIGRP external routes default to AD Use distance commands to tweak AD values.

    ! R1: Set higher AD for redistributed OSPF routes in EIGRP
    router eigrp 1
    distance 180 10.0.0.0 0.255.255.255 OSPF_SOURCE ! Redistributed OSPF routes have AD 180
    ip community-list 10 permit 65001:123 ! Match specific communities

    ! R2: Set higher AD for redistributed EIGRP routes in OSPF
    router ospf 100
    distance 150 192.168.0.0 0.0.255.255 EIGRP_SOURCE ! Redistributed EIGRP routes have AD 150

  4. Metric Manipulation Set higher metrics for redistributed routes to avoid suboptimal paths Configure higher costs in one direction to make routes less preferred.

    ! R1: Lower metric for EIGRP-to-OSPF redistribution
    router eigrp 1
    redistribute ospf 100 metric 1000 100 255 1 1500 ! Lower metric


    ! R2: Higher metric for EIGRP-to-OSPF
    redistribution
    router eigrp 1
    redistribute ospf 100 metric 1500 150 255 1 1500 ! Higher metric

  5. Route-Maps with Communities (Advanced): Use BGP-style communities to tag and filter routes. Set communities during redistribution, thereafter, filter routes with matching communities when redistributing back.

    ! R1: Set community for EIGRP-to-OSPF routes
    route-map TO_OSPF permit 10
    set community 65001:123


    router ospf 100
    redistribute eigrp 1 subnets route-map TO_OSPF


    ! R2: Block routes with community 65001:123
    route-map FROM_EIGRP deny 10
    match community 65001:123


    route-map FROM_EIGRP permit 20 ! Allow other routes

Verification & Best Practices

  1. Check Routes:
    • Verify OSPF routes: show ip route ospf
    • Verify EIGRP routes: show ip route eigrp
  2. Debug Redistribution: Monitor route updatesdebug ip routing

Best Practices

  • Avoid mutual redistribution at multiple points unless absolutely necessary.

  • Always use route tags or distribute-lists to prevent feedback loops.

  • Test configurations in a lab before deploying to production.

Summary

Two-way multipoint redistribution introduces complexity but can be safely implemented with:

  • Route tags to block feedback loops.

  • Distribute-lists/prefix lists to filter unwanted routes.

  • Metric tuning to enforce path preference.

  • Administrative distance adjustments to prioritize internal routes.

By combining these techniques, you can ensure a stable and loop-free network.


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.

Three-Way Multipoint Redistribution

Three-way multipoint redistribution involves exchanging routes among three routing protocols (e.g., OSPF, EIGRP, and BGP) at multiple redistribution points (e.g., routers). This setup increases redundancy and flexibility but introduces significant risks of routing loops , suboptimal paths , and route feedback . Proper configuration and loop prevention are critical.

Topology Overview

  • Protocols :
    • OSPF (Process ID 100) for core/internal routing.
    • EIGRP (AS 1) for edge networks.
    • BGP (AS 65001) for external connectivity.
  • Routers:
    • R1: Redistributes OSPF ↔ EIGRP.
    • R2: Redistributes EIGRP ↔ BGP.
    • R3: Redistributes BGP ↔ OSPF.
  • edistribution Points : Routes flow bidirectionally between all three protocols across R1, R2, and R3.

Configuration Example

Basic Redistribution Setup

! R1: OSPF ↔ EIGRP Redistribution
router eigrp 1
redistribute ospf 100 metric 1000 100
255 1 1500 route-map TO_EIGRP
default-metric 1000 100 255 1 1500
!

router ospf 100
redistribute eigrp 1 subnets route-map
TO_OSPF
default-metric 100



! R2: EIGRP ↔ BGP Redistribution
router bgp 65001
redistribute eigrp 1 route-map
bgp router-id 2.2.2.2
neighbor 192.168.2.2 remote-as 65002
!

route-map EIGRP-TO-BGP permit 10
set origin igp
set metric 100



! R3: BGP ↔ OSPF Redistribution
router ospf 100

redistribute bgp 65001 subnets
route-map BGP-TO-OSPF
default-metric 100

!
router bgp 65001
redistribute ospf 100 route-map
OSPF-TO-BGP

Loop Prevention Techniques

Without safeguards, routes redistributed at one point (e.g., R1) could re-enter the network via another (e.g., R3), creating loops. Below are techniques to mitigate this:

  1. Route Tags: Use unique route tags to identify the source of redistributed routes and block feedback loops. Assign distinct tags for each protocol (e.g., TAG_OSPF=100, TAG_EIGRP=200, TAG_BGP=300). Filter routes with matching tags when redistributing back.

    ! R1: Tag OSPF routes redistributed into EIGRP with TAG_OSPF=100
    route-map TO_EIGRP permit 10
    set tag 100




    ! R1: Block EIGRP routes tagged with TAG_EIGRP=200 when redistributing into OSPF
    route-map TO_OSPF permit 10
    match tag 200
    deny
    !

    route-map TO_OSPF permit 20
    set tag 100



    ! R2: Tag EIGRP routes redistributed into BGP with TAG_EIGRP=200
    route-map EIGRP-TO-BGP permit 10
    set community 65001:200
    set tag 200



    ! R3: Block BGP routes tagged with TAG_BGP=300 when redistributing into OSPF
    route-map BGP-TO-OSPF permit 10
    match tag 300
    deny
    !
    route-map BGP-TO-OSPF permit 20
    set tag 300

  2. Distribute-Lists: Filter specific routes using prefix lists or ACLs during redistribution. >Define prefixes to exclude from redistribution (e.g., subnets already present in the target protocol).

    ! R1: Block redistribution of 192.168.1.0/24 from EIGRP to OSPF
    ip prefix-list BLOCK_EIGRP_SUBNETS seq
    10 deny 192.168.1.0/24
    ip prefix-list BLOCK_EIGRP_SUBNETS seq
    20 permit 0.0.0.0/0 le 32



    router ospf 100
    redistribute eigrp 1 subnets
    distribute-list prefix
    BLOCK_EIGRP_SUBNETS in

  3. Administrative Distance (AD): Prioritize internal routes over redistributed ones by tweaking AD values. Redistributed routes typically have higher AD (e.g., BGP external = 20, EIGRP external = 170).
    ! R2: Increase AD for BGP routes redistributed into EIGRP
    router eigrp 1
    distance 180 10.0.0.0 0.255.255.255
    BGP_SOURCE ! BGP routes have AD 180



    ! R3: Increase AD for OSPF routes
    redistributed into BGP
    router bgp 65001
    distance 200 192.168.0.0 0.0.255.255
    OSPF_SOURCE ! OSPF routes have AD 200
  4. Metric Manipulation: Set higher metrics for redistributed routes to avoid suboptimal paths. Configure higher costs in one direction to make routes less preferred.

    ! R1: Lower metric for OSPF-to-EIGRP redistribution
    router eigrp 1
    redistribute ospf 100 metric 1000 100 255 1 1500



    ! R3: Higher metric for BGP-to-OSPF redistribution
    router ospf 100
    redistribute bgp 65001 subnets
    default-metric 200 ! Higher cost for BGP routes

  5. Communities (Advanced): Use BGP communities to tag and filter routes across redistribution points. Set communities during redistribution. Filter routes with matching communities when redistributing back.

    ! R2: Tag EIGRP routes redistributed into BGP with community 65001:200
    route-map EIGRP-TO-BGP permit 10
    set community 65001:200



    ! R3: Block routes with community 65001:200 when redistributing into OSPF
    ip community-list 10 deny 65001:200
    ip community-list 10 permit all



    route-map BGP-TO-OSPF permit 10
    match community 10
    deny

Verification

  1. Check Routes:
    • show ip route ospf Verify OSPF routes
    • show ip route eigrp ! Verify EIGRP routes
    • show ip bgp ! Verify BGP routes
  2. Debug Redistribution: debug ip routing ! Monitor route updates

Best Practices

  • Avoid mutual redistribution at multiple points unless absolutely necessary.

  • Always use route tags or distribute-lists to prevent feedback loops.

  • Test configurations in a lab before deploying to production.

Summary

Three-way multipoint redistribution is inherently complex but manageable with:

  • Route tags to block feedback loops across protocols.

  • Distribute-lists/prefix lists to filter unwanted routes.

  • Metric tuning to enforce path preference.

  • Administrative distance adjustments to prioritize internal routes.

  • Communities for advanced control in BGP environments.

By combining these techniques, you can ensure a stable, loop-free network across multiple routing protocols. 🛡️


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.

Thursday, 6 July 2023

Understanding Prefix-Lists

Overview

Like access control lists (ACLs), prefix lists are used as a filtering tool. However, unlike ACLs, which are used for a wide variety of tasks, prefix lists are predominantly used by routing protocols for route/prefix filtering. Prefix lists provide granular control over matching prefixes for route filtering; matching the prefix and prefix-length; ACLs match only the prefix. Like an ACL, prefix-lists use permit or deny clauses to match prefixes and prefix lengths. Internal processing of IP prefix-lists uses an internal tree structure that results in faster matching of routes compared to ACLs. In recent developments, improvements have been made with the processing of prefix-lists and ACLs in hardware.

Naming and Structure

The naming and structure of prefix lists is similar to named ACLs. The prefix list naming recommendations include the following:

  • Name cannot contain spaces or punctuation marks.
  • Prefix list name cannot begin with a number
  • Prefix list name must be unique; prefix lists of different types cannot have the same name
  • Prefix list name can have a mixture alpahnumeric characters
  • Recommended that the prefix list name be written in capital letters
  • Prefix list names are locally significant. Multiple routers on the network can be configured to have the same name
  • Choose names that identify the function of the prefix list

Prefix-lists use the concept of a unique name for a single prefix-list with multiple entries. Each entry has a unique sequence number. The use of sequence numbers allow for subsequent modification of the prefix list through the addition or deletion of individual entries from the prefix list.

Prefix-lists do not use wildcard masks or bits; they use the prefix length for matching against the network address and subnet mask. A prefix-list is used to match routes particularly for route filtering and not for packet filtering:

  • Permit: the route is matched, the route should not be filtered.
  • Deny: route is not matched and should be filtered.

Prefix-list have a default implicit deny all statement at the end. The command to configure a prefix-list is: ip prefix-list <name> [seq <num>] {deny | permit} <prefix/prefix-length> [ge <prefix-length>] [le <prefix-length>] where:

  • Prefix/prefix-length: is the prefix and prefix-length that is being matched.
  • ge ( greater than or equal): value is used to match against the subnet mask. The prefix-length to be matched by ge is in the range: ge value and 32. The ge value sets the lower limit of the prefix length range to be matched. The prefix-length MUST be less than the ge value; otherwise IOS will report this error message % Invalid prefix range for 10.1.1.0/24, make sure: len < ge.value <= le.value.

  • le (less than or equal to): when matching the route's prefix length, the le value sets the upper limit of the prefix length comparison range. The range of prefix lengths to be matched is between route prefix length to the le value. The prefix-length must be less than the le value; otherwise IOS will report this error message: % Invalid prefix range for 10.1.1.0/24, make sure: len < ge.value <= le.value
  • le and ge: if both are configured, on the same prefix list statement, the value of le must be greater than or equal to the value of ge:
    • Prefix lengths to be matched are in the range ge value to le value.
    • If le is equal to ge, then the prefix length is matched against the specific le/ge value rather than a range.

Prefix Matching

The logic of a prefix-list is as follows:

  • The route's prefix must be within the range of addresses implied by the prefix-list command's prefix/length parameters.
  • The route's prefix-length must match the range of prefixes implied by the prefix-list command's prefix-length, ge and le parameters.

Every matching done by a prefix list checks the network address and the subnet mask. Up to four types of matching can be performed using prefix lists:

  1. Exact match: only the prefix and prefix length are specified by the prefix list. The ge and le keywords are not used in prefix and prefix length matching.
    • ip prefix-list PL permit 10.1.1.0/24
      • Matches the network address 10.1.1.x.
      • Matches the subnet mask 255.255.255.0.
  2. From minimum prefix length: implemented using the ge keyword.
    • ip prefix-list PL permit 10.1.1.0/24 ge 26
      • Matches the network address 10.1.1.x
      • Matches the subnet mask 255.255.255.192 - 255.255.255.255
    • ip prefix-list PL permit 10.1.1.0/8 ge 9
      • Matches the network address of 10.x.x.x
      • Matches the subnet mask 255.128.0.0 - 255.255.255.255.
  3. Up to a maximum prefix length: implemented using the le keyword prefix length in the range prefix length to le value.
    • ip prefix-list PL permit 10.1.1.0/16 le 26
      • Matches the network address 10.1.x.x
      • Matches the subnet 255.255.0.0 - 255.255.255.192
    • ip prefix-list PL permit 10.1.1.0/19 le 27
      • Matches for the network address of 10.1.x.x/19
      • Matches the subnet mask 255.255.224 - 255.255.255.224.
  4. Range of prefix lengths: implemented by the configuration of both ge and le keywords:
    • ip prefix-list PL permit 10.1.1.0/16 ge 22 le 30
      • Matches the network address 10.1.x.x
      • Matches the subnet 255.255.252.0 - 255.255.255.252
    • ip prefix-list PL permit 10.1.1.0/24 ge 26 le 29
      • Matches the network address of 10.1.1.x
      • Matches the subnet mask 255.255.255.192 - 255.255.255.248.
    • ip prefix-list PL permit 10.1.1.0/24 ge 26 le 26
      • Matches the network address 10.1.1.x
      • Matches the subnet 255.255.255.192

Matching the Default Route

IPv4

ip prefix-list PL permit 0.0.0.0/0

  • Match any address
  • The subnet mask MUST match zero(0). Only the default route has a subnet mask of zero.

IPv6

ipv6 prefix-list PL permit ::/0

Match all prefixes

IPv4

ip prefix-list PL permit 0.0.0.0/0 le 32

  • le 32 implies that the subnet mask will match from 0.0.0.0 - 255.255.255.255. Even the broadcast address is matched.

IPv6

ipv6 prefix-list PL permit ::/0 le 128

Exercise

Objective: Deny all routes which have the first 24-bits of 10.10.10.x AND subnet mask is GE 24 but LE 30.