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.

BiDirectional Forwarding Detection (BFD)

Introduction and Overview

Bidirectional Forwarding Detection (BFD) is a light-weight standards-based protocol, defined by RFC 5880, that detects failure in the forwarding path on a layer 3 network between two adjacent routers. These failures may be on the connecting interfaces, data links, tunnels, and forwarding planes of devices not directly connected to the routers in a layer 2 network. BFD is capable of working on multiple media types. BFD uses UDP packets to exchange control information with peers on port 49152 as the source port and destination port of 3784.

BFD's primary goal is to detect loss of connectivity between two devices quickly and efficiently. BFD notifies client protocols of the link failure. BFD client protocols include OSPF, IS-IS RSVP, EIGRP, HSRP, BGP, static routes that have registered to receive BFD notifications. BFD provides faster and more consistent failure detection than the hello and keepalive timers of routing protocols. Failure detection in BFD can be in the millisecond range. Most routing protocol timers will detect a link failure at a minimum of one second after it has occurred. It is up to these client protocols to determine how to recover from the failure of the link between the two devices. The client protocols may try to find alternative paths for routes that were initially accessible through the failed device. The client protocols use the BFD-provided information independently. BFD runs to serve these client protocols. It is pointless to run BFD without client protocols.

Networks carrying realtime traffic such as video and voice need speedy network convergence. Link failure detection time usually delays convergence of networks. Traditional link failure detection relies on:

• Hello message timeouts of routing protocols.
• Transmission technology capability to detect failure.

BFD runs independent of routing protocol hello messages and notifies the client protocols of link failure by sending rapid failure detection notices to routing protocols and reducing convergence time through routing table recalculation. BFD can be used in place of routing protocol timers and can act as a single method of liveliness detection between nodes irrespective of media type.

On distributed platforms, BFD packets can be processed on interface modules of the line card hence it is not CPU intensive. In most cases, routing protocol hello packets are processed by the control plane (CPU).

BFD also provides failure detection on virtual circuits such as MPLS LSP, Ethernet virtual circuits tunnels.

By default, BFD topology is primarily point-to-point running on a link between two devices.

BFD can be implemented in multiple ways:

1. Single-hop BFD: BFD for IPv4 and IPv6
2. Generic Application of BFD
3. BFD for MPLS (LSPs)
4. Multihop BFD for peers that are several hops away from each other

Benefits of BFD

The closest alternative to using BFD for failure detection is the hello packet of routing protocols EIGRP, OSPF, IS-IS and BGP keepalive messages. If configured to their minimum supported values, these routing protocol timers usually detect failures of peers or their links within one second of the failure. With OSPF though, configuration of sub-second values is possible using the interface command ip ospf dead-interval minimal hello-multiplier <multiplier> where multiplier is the number of hello packets sent per second;

BFD does have some advantages over the aforementioned failure detection techniques:

• BFD is protocol independent and can therefore act as a generic failure detection mechanism for various routing protocols.
• Parts of BFD failure mechanisms can be configured to operate at the data-plane reducing or eliminating CPU involvement in failure detection. This can be contrasted with failure detection methods of routing protocols that largely operate at the control plane.
• BFD is able to detect failures in the sub-second range compared to most routing protocol failure detection which is usually at a minimum of one second.

Prerequisites for BFD

• Cisco Express Forwarding (CEF) needs to be enabled.
• The client routing protocol should be configured on the router before BFD is deployed.

Restrictions of BFD

• When BFD is enabled on an interface, an access control list (ACL) with the "log" opton is not supported on that interface.
• BFD is not supported in IPSec.

BFD Modes

BFD operates in one of two modes: asynchronous or demand mode. BFD also offers an echo function which works with both modes. Most vendors support asynchronous mode operating with or without echo function enabled.

Asynchronous Mode

BFD control packets are exchanged by neighboring systems at pre-agreed time intervals which is usually in milliseconds. If a specified number of sequential packets are not received from the BFD peer, BFD declares the session to be down and notifies any registered protocol of this failure. Asynchronous mode is supported by Cisco IOS.

Demand Mode

Once the BFD session is established, the participating systems can request that the BFD packets not be sent, then request an exchange of packets only when needed to verify connectivity. Though this mode is defined in the RFC 5880, few network equipment vendors support BFD demand mode.

How BFD Works

Once a BFD session is established with a neighbor, BFD exchanges control packets to verify connectivity and inform the requesting protocol(s) of link failure if a specified number of successive packets are not received. The requesting protocol is then responsible for responding to the link-failure. Routing protocols using BFD for failure detection continue to operate normally when BFD is enabled, including the exchange of their respective hello packets.

A BFD session is a three-way handshake and tear-down process:

1. Routing protocol discovers neighbor and registers neighbor as a client with BFD.
2. BFD control packets act as keepalive to maintain the neighbor session.
3. Failure of the BFD session triggers a notification to the registered routing protocol client which in term tears down the routing protocol neighbor session. If an alternative path exists the routing protocol immediately converges.

BFD Packets

BFD utilises control packets to exchange control information as well as detect the liveliness of the BFD peer.

BFD Control Packet Format

Field	Description
Diagnostic Code (Diag) and Session State:	State in which the BFD session is in and reason i.e. Up/Down/Init.
Discriminators:	demultiplexers
Detect Time Multiplier	Used to calculate detection times for peers. The detection time is the product of the Detect Time Multiplier and Min RX Interval that is used to question a peer's liveliness if a control packet is not received within this product in milliseconds.
Desired Min TX Interval (msecs):	Desired interval to transmit control packets. i.e. how fast the peer desires to send control packets.
Required Min RX Interval (msecs):	Minimum receive interval peer can handle. i.e. rate that the peer can receive packets.
Required Min Echo Interval	Interval within which echo packets are received to indicate liveliness of a peer (if the echo function is enabled).

The following output shows a Wireshark packet capture of a BFD control packet. From this packet capture, it can be determined that the transmit interval is configured to 1000ms, the receive interval to 1000ms, minimum echo interval to 50ms and the multiplier to 3 (x3 the value of the transmit interval).

BFD Control message
    001. .... = Protocol Version: 1
    ...0 0000 = Diagnostic Code: No Diagnostic (0x00)
    01.. .... = Session State: Down (0x1)
    Message Flags: 0x40
        0... .. = Poll: Not set
        .0.. .. = Final: Not set
        ..0. .. = Control Plane Independent: Not set
        ...0 .. = Authentication Present: Not set
        .... 0. = Demand: Not set
        .... .0 = Multipoint: Not set
    Detect Time Multiplier: 3 (= 3000 ms Detection time)
    Message Length: 24 bytes
    My Discriminator: 0x00000002
    Your Discriminator: 0x00000000
    Desired Min TX Interval: 1000 ms (1000000 us)
    Required Min RX Interval: 1000 ms (1000000 us)
    Required Min Echo Interval: 50 ms (50000 us)


Timer Negotiation and Detection Times

When making decisions on detection timers, BFD sends packets as fast as their local peers allow but no faster. A BFD device notes the Required Min RX Interval value received from a peer's BFD control packet (how fast a peer can receive BFD packets) and compares it to its configured Desired Min TX Interval (how fast it can send BFD control packets). The operational transmit interval is then set to whichever of the two values is higher.

When calculating the detection timer values, the local detection is equal to the product of the peer's Detect Time Multiplier and the peer's Tx value. The TX timer and the detection times can be different for each peer.

Given three scenarios where R1 forms a BFD session with peer R2, R3 forms a BFD session with R4 and R5 forms a BFD session with R6, the operational transmit interval and detection time are calculated as shown in the following table:

Device	TX Interval	Min_Rx	Operational TX	Multiplier	Detection Time
R1	50ms	50ms	50ms	3	3 ×50ms = 150ms
R2	50ms	50ms	50ms	3	3 ×50ms = 150ms
R3	50ms	150ms	150ms	5	10 ×150ms = 1500ms
R4	50ms	150ms	150ms	10	5 × 150ms = 750ms
R5	50ms	200ms	150ms	5	10 ×500ms = 5000ms or 5s
R6	500ms	150ms	500ms	10	5 × 150ms = 750ms

The first device to detect that the peer is unreachable will set a flag in the control packet notifying the peer that it is unreachable. The local BFD instance will notify the client routing protocols in each of the peers resulting in both tearing down the routing protocol neighborship.

Echo Function

When the echo function is activated, echo packets are looped back through the layer 3 forwarding path to the BFD peer without involving the CPU. Link failure is detected by an interruption in the stream of echoed packets. Echo function makes it possible for link failure detection using BFD to be handled at the data plane level and not involve the CPU.

The minimum reception rate for BFD control packets from the neighbor is also changed automatically when the echo function is operational, because liveness detection is supplied by the echo packets.

While BFD control messages are transmitted to UDP port 3784, BFD echo messages use UDP port 3785 for both source and destination ports of the BFD echo packet.

BFD started out based on a polling ("asynchronous") approach using control packets. One router polls the other and gets a quick response back. The challenge with this is delay in waking up the BFD process to send a reply, culminating in variable jitter in the response. If the peer is slow in responding BFD triggers a link failure notification, which is not ideal. It is possible to configure both peers to send BFD echo packets or one peer to send the BFD echo packet. The latter approach is referred to as BFD asymmetry.

The Echo function is an additional feature that can be enabled in any of the BFD operational modes i.e. asynchronous or demand modes. The BFD echo function enhances BFD in one very specific way; it allows the devices running BFD to test the actual forwarding path taken by data packets. This is a capability that the control packets are not able to carry out. In some IOS distributions, the Echo function is enabled by default.

Echo Packets

The Echo function uses echo packets using interesting values for the IP source and destination addresses. The destination IP address is set to the IP address of the sender. In other words, the destination IP address is the same as the source IP address of the sender. For Layer 2 addressing, the destination address is the MAC address of the BFD peer.

After the BFD peer receives an echo packet and determines that the destination IP address is different from any of its IP addresses, it consults the RIB/FIB to determine how to forward the packet and sends it to the sender. In this way it uses the data forwarding path of network traffic.

Echo Function in BFD Asynchronous Mode

Peers need to exchange BFD information such as intervals, State, Diag etc. Echo packets do not carry usable data and are technically processed by the sender. Control packets are still exchanged but the frequency is substantially decreased. In BFD asynchronous mode without the echo function, the control packets play the dual-role of exchanging BFD session information and detecting link failure. In BFD asynchronous mode with echo function, the echo function uses control packets to exchange BFD information as usual. However, the control packets are sent less frequently; more frequently sent are echo packets which take the primary role of detecting link failure.

Echo Function Activation

BFD peers use the control packet to signal activation of the echo function. The control packet field Required Min Echo Interval is used to signal echo function activation to a BFD peer. If the echo function is activated, the Required Min Echo Interval field contains a value in milliseconds. It is used to communicate to the BFD peer the minimum rate of the sender receiving echo packets. Conceptually, it is similar to the Required Min RX Interval of the Echo packet. The frequency of Echo packet are therefore partially dictated by the neighbors. Echo packets can not be sent more frequently than the Required Min RX Interval values of the BFD peer. If the echo function is not activated, the control packets from the peer will contain zero values for the Required Min Echo Interval field.

Restrictions to Using the Echo Function

1. Disable ICMP redirects on any interface where the BFD echo function will be used using the command no ip icmp redirects. With ICMP redirect active on an interface, the interface will notice that the echo packets are looped back. It will then generate an ICMP redirect message for each echo packet. Disabling ICMP redirect messages helps in avoiding high CPU uilization.
2. Any uRPF checks will need to be disabled on the interface or an exception should be made for echo packets on the interface. Based on the way echo packets are transmitted and looped back, they fail uRPF checks; depending on how strict the uRPF checks have been configured. If BFD echo mode and uRPF are configured on the same interface, BFD sessions will flap.

BFD Slow Timer

BFD can use the slow timer to slow down the transmission rate of BFD control packets when the echo function is enabled. This reduces the number of BFD control packets that are sent between two BFD neighbors. With echo function enabled, control packets are not used for failure detection hence may not be desirable to be exchanged frequently. This, in turn, further lightens the CPU load.

To configure BFD slow timer use the global configuration mode command bfd slow-timer <milliseconds>:

R6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z
R6(config)#bfd slow-timers 12000
R6(config)#

BFD Configuration

Configuration of BFD is a two step process:

Step 1: Enable BFD on interface through which the peer is reachable using the interface configuration command: bfd interval <tx-interval> min_rx < min_rex> multiplier <multiplier>. The rate of exchanging hello control packets (similar to hello-timer) can be set in the range 50 - 9999 milliseconds. min_rx: minimum interval supported for receiving BFD control packets from a neighbor. multiplier: used to compute the hold-down time. If multiplier is 3 and hello interval 50 then holddown timer is 150 ms.

R6(config)#interface gigabitethernet0/0
R6(config-if)#bfd interval 100 min_rx 50 multiplier 3


Step 2: Configure the routing protocol to use BFD for failure detection. Interested clients include static routing, EIGRP, OSPF, BGP, FHRP(HSRP, VRRP, GLBP), MPLS LSP, etc registers with BFD and is notified as soon as BFD detects a neighbor loss.

BFD for BGP

BFD must be running on all participating BGP devices.

R6(config)#router bgp 65531
R6(config-router)#neighbor 1.1.1.1 remote-as 65532
R6(config-router)#neighbor 1.1.1.1 fall-over bfd ?
  multi-hop   Force BFD multi-hop to detect failure
  single-hop  Force BFD single-hop to detect failure
<cr>

BFD in BGP supports two session types: multi-hop and single-hop. This is because BGP supports BGP peers that can be directly connected or several hops away. This BFD session type will depend on the BGP session type of the neighbor being configured; if the neighbor is several hops away, configure the BFD multi-hop type.

BFD in EIGRP

In EIGRP named mode, BFD is configured under the af-interface mode:

R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
R6(config-router-af-interface)#

If BFD is configured under af-interface default, all interfaces with EIGRP peers will be registered to receive BFD notifications. However, remember that BFD has to first be configured on the interface otherwise the following error messaage will be generated:

R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
%EIGRP: BFD interval is not configured on interface GigabitEthernet0/0 required for BFD operation.
R6(config-router-af-interface)#

In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on link failure on a single interface as below:

R6(config)#router eigrp 2
R6(config-router)#bfd interface gigabitethernet 0/0

In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on all EIGRP-enabled interfaces as below:

R6(config)#router eigrp 2
R6(config-router)#bfd all-interfaces

NOTE: Configuration of EIGRP to receive notifications from all EIGRP enabled interfaces as demonstrated above does not issue a log message if BFD has not been enabled on the interface using the interface-mode BFD configuration commands.

BFD in OSPF

BFD is configured in OSPF for all interfaces with the router ospf mode command bfd all-interfaces. The command does not provide the additional flexibility of EIGRP of installing on select interfaces or all interfaces at once. To enable BFD on an interface, issue the following interface configuration command: ip ospf bfd

Under an interface, to disable BFD for a specific interface in interface mode issue the command: ip ospf bfd disable.

BFD in Static Routing

BFD is able to detect failures in the forwarding path of static routes. To configure BFD in static routing:

R6(config)#interface g1/0
R2(config-if)#bfd interval 250 min_rx 150 multiplier 3
R2(config-if)#exit
R6(config)#ip route static bfd gigabitethernet1/0 10.0.26.1


Verification

BFD operation can be verified using the command show bfd neighbors (detail)

BFD Troubleshooting

Troubleshooting of BFD may be required when BFD is not functioning effectively:

• BFD session down: Verify BFD configuration on both routers.
• BFD session is flapping: check if uRPF has been configured on the interface.

The following commands are important in troubleshooting BFD:

Command	Description
show bfd neighbor detail	Displays the BFD adjacency database. The details keyword shows all BFD protocol parameters and timers per neighbor.
debug bfd event	Displays debugging information about BFD control packets or events such as BFD state transitions.

Recommendations on Deployment of BFD

• The use of BFD echo function is encouraged.
• BFD may not be necessary if devices are directly connected on point to point link without any other device such as a switch in-between. BFD is ideal if two routers are connected to each other with a switch interconnecting the two devices.
• Remember to configure the slower timer command, when you enable BFD echo function.