How to Set Up BGP Route Redistribution on Cisco Routers: Configuration and Best Practices

Redistribution is where BGP meets the rest of your routing domain — the point where routes learned from OSPF, EIGRP, static configuration, or connected interfaces get injected into BGP (or the reverse). Done carefully, it’s a powerful integration tool. Done carelessly, it’s one of the fastest ways to create routing loops or accidentally leak internal routes to the internet. This guide walks through safe, deliberate redistribution design and configuration on Cisco routers.

Why Redistribution Needs Extra Caution With BGP

Unlike redistributing between two IGPs of similar scope, redistributing into BGP often means taking routes from a contained internal domain and exposing them to external peers — potentially the entire internet, depending on your peering relationships. The stakes for a mistake here are much higher: a redistribution error into an IGP might cause internal instability, but a redistribution error into BGP that reaches an external peer can leak private addressing, cause route flapping across the internet, or in the worst historical cases, cause major outages when very large route tables get accidentally advertised.

The golden rule: always filter what you redistribute, both at the redistribution point and again at the eBGP edge.

Redistributing Static Routes Into BGP

The simplest and often safest form of redistribution — for injecting a small number of well-understood prefixes:

Router(config)# router bgp 65001
Router(config-router)# redistribute static route-map STATIC-TO-BGP

Router(config)# route-map STATIC-TO-BGP permit 10
Router(config-route-map)# match ip address prefix-list ALLOWED-STATICS

Router(config)# ip prefix-list ALLOWED-STATICS seq 10 permit 198.51.100.0/24

Without the route-map filter, redistribute static would inject every static route on the router into BGP — including default routes, null routes, or management routes you never intended to advertise.

Redistributing Connected Routes Into BGP

Common when you want to advertise directly connected transit or peering subnets without manually configuring network statements for each:

Router(config-router)# redistribute connected route-map CONNECTED-TO-BGP

Router(config)# route-map CONNECTED-TO-BGP permit 10
Router(config-route-map)# match interface Loopback0

Redistributing an IGP (OSPF) Into BGP

This is where things get more dangerous, because OSPF can carry hundreds or thousands of internal routes that should never touch BGP directly.

Router(config)# router bgp 65001
Router(config-router)# redistribute ospf 1 route-map OSPF-TO-BGP

Router(config)# route-map OSPF-TO-BGP permit 10
Router(config-route-map)# match ip address prefix-list PUBLIC-BLOCKS
Router(config-route-map)# set community 65001:100

Router(config)# ip prefix-list PUBLIC-BLOCKS seq 10 permit 198.51.100.0/22

Only the specific summarized public block gets redistributed — not the full internal OSPF table.

Redistributing EIGRP Into BGP

Router(config-router)# redistribute eigrp 100 route-map EIGRP-TO-BGP

route-map EIGRP-TO-BGP permit 10
 match ip address prefix-list PUBLIC-BLOCKS

Redistributing BGP Into an IGP (The Riskier Direction)

Injecting the full internet routing table into an IGP like OSPF or EIGRP is almost always a mistake — IGPs aren’t designed to scale to hundreds of thousands of routes, and doing this can crash or severely degrade routers with limited memory/CPU. If you genuinely need select external routes inside your IGP (for example, a small number of partner routes learned via BGP that internal routers need to reach directly), filter aggressively:

Router(config)# router ospf 1
Router(config-router)# redistribute bgp 65001 subnets route-map BGP-TO-OSPF metric-type 1

route-map BGP-TO-OSPF permit 10
 match ip address prefix-list PARTNER-ROUTES-ONLY

ip prefix-list PARTNER-ROUTES-ONLY seq 10 permit 203.0.113.0/24

Never redistribute the full BGP table into an IGP without a very deliberate, tightly scoped filter — and generally, prefer a default route plus a handful of explicit statics over full redistribution for this direction.

Setting Metrics and Metric-Types During Redistribution

For OSPF, always be explicit about metric-type, since the default (Type 2) may not reflect actual path cost realistically for downstream routers making best-path decisions:

route-map OSPF-TO-BGP permit 10
 match ip address prefix-list PUBLIC-BLOCKS
 set metric-type type-1

For EIGRP, redistributed routes require an explicit metric unless a default-metric is configured, or the redistribution will fail silently for that protocol:

Router(config-router)# redistribute static route-map STATIC-TO-BGP
Router(config-router)# default-metric 10000 100 255 1 1500

Practical Enterprise Scenario

A company has an internal OSPF domain, a small pool of public IP space (198.51.100.0/24) hosted on internal servers reachable via a DMZ, and needs to advertise just that block to two ISPs via eBGP, while keeping internal OSPF routes entirely private.

router ospf 1
 network 10.0.0.0 0.255.255.255 area 0
!
router bgp 65001
 neighbor 203.0.113.1 remote-as 64500
 neighbor 198.51.100.1 remote-as 64501
 redistribute static route-map STATIC-TO-BGP
!
route-map STATIC-TO-BGP permit 10
 match ip address prefix-list PUBLIC-BLOCK
!
ip prefix-list PUBLIC-BLOCK seq 10 permit 198.51.100.0/24
!
ip route 198.51.100.0 255.255.255.0 Null0

Note the static route to Null0 for the aggregate — this is a common, deliberate pattern: it gives BGP a stable route to advertise (an aggregate) regardless of the state of individual internal /32s, and the Null0 route only becomes relevant as a last-resort discard if more specific internal routing somehow fails, which also protects against inadvertent black-holing since more specific internal routes are always preferred when present.

Verification Commands

Router# show ip bgp
Router# show ip bgp neighbors 203.0.113.1 advertised-routes
Router# show ip route bgp
Router# show route-map STATIC-TO-BGP
Router# show ip protocols

Sample output confirming what’s actually being advertised:

Router# show ip bgp neighbors 203.0.113.1 advertised-routes
Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.100.0/24  0.0.0.0                  0         32768 i

If unexpected prefixes show up here, the redistribution filter needs tightening immediately.

Common Configuration Mistakes

• Redistributing without a route-map at all — redistribute ospf 1 with no filter injects everything OSPF knows into BGP, a classic cause of route leaks.
• Forgetting subnets keyword on OSPF redistribution into BGP context (or reverse) — without it, only classful network boundaries are redistributed, silently dropping subnetted routes.
• Redistributing BGP into an IGP without tight filtering, risking IGP table exhaustion or instability.
• Not setting a default-metric for EIGRP redistribution, causing routes to silently fail to redistribute.
• Assuming a route-map with only a deny and no explicit final permit will allow anything through — remember the implicit deny-all at the end of every route-map, same as ACLs.
• Redistributing mutually between two protocols in both directions without loop prevention, creating redistribution loops where routes bounce back and forth gaining artificial preference.

Best Practices

1. Always use a route-map with explicit prefix-list matching for every redistribution statement — never redistribute unconditionally into BGP.
2. Aggregate before you advertise. Advertise summarized blocks rather than every individual internal /32 or /30, both for internet routing table hygiene and to reduce your BGP update churn.
3. Tag redistributed routes with a community (see the BGP Communities guide) so downstream policy can identify and specifically handle redistributed-vs-native BGP routes.
4. Filter at both the redistribution point and again at the eBGP edge — defense in depth in case one filter has a mistake.
5. Avoid two-way redistribution loops between BGP and an IGP without tag-based loop prevention (using route-tags to mark and reject routes that already originated from the other protocol).
6. Test in a lab with realistic prefix counts before deploying redistribution changes affecting production BGP sessions with external peers.

Troubleshooting Checklist

• show ip bgp neighbors X advertised-routes — confirm exactly what’s being sent, not what you assume is being sent.
• show route-map NAME — confirm hit counts on each sequence to validate the filter logic is matching as expected.
• show ip route bgp — for the reverse direction, confirm which BGP routes actually made it into the IGP.
• Check IGP router memory/CPU utilization after any redistribution change involving a large route count.
• Use debug ip routing (cautiously, in a maintenance window) if routes aren’t appearing where expected.

FAQs

Should I ever redistribute the full BGP table into an IGP? Almost never. IGPs aren’t designed for internet-scale route counts, and doing this risks router resource exhaustion and instability. Use default routes or a small set of explicit statics instead.

Do I need subnets every time I redistribute into OSPF? Yes, in virtually all modern deployments, since almost everything is subnetted. Omitting it silently drops subnetted routes from redistribution.

Is redistributing connected routes safer than redistributing an IGP? Generally yes, since connected routes are a small, well-known set, but you should still filter deliberately — an accidentally advertised management or loopback subnet is still a leak.

How do I prevent redistribution loops between BGP and an IGP? Use route-tagging: tag routes as they’re redistributed from IGP into BGP, then filter on that tag to deny re-redistribution back into the same IGP, and vice versa.

Summary

Route redistribution into and out of BGP is powerful but unforgiving — the difference between a clean integration and a route leak or IGP meltdown often comes down to a single missing route-map. The discipline that keeps redistribution safe is consistent: filter explicitly with prefix lists at every redistribution point, aggregate before advertising externally, avoid injecting large IGP or BGP tables into the wrong domain, and always verify with show ip bgp neighbors ... advertised-routes after any change rather than trusting the configuration alone.

References

• Redistributing Routing Protocols: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/irg-bgp-redis.html
• BGP Case Studies: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13756-32.html
• Configuring OSPF: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16/iro-xe-16-book.html