Cisco 300-410: Route Redistribution and Policy-Based Routing — Study Guide

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Part of the Cisco CCNP Enterprise 300-410 ENARSI — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

Route redistribution and policy-based routing (PBR) are powerful tools for integrating heterogeneous routing domains and influencing forwarding decisions beyond the default destination-based paradigm. Correctly implemented, they enable scalable inter-domain connectivity, selective traffic steering, controlled default-route propagation, and robust loop prevention. Incorrectly implemented, they create routing loops, route feedback, suboptimal paths, and difficult-to-diagnose black holes. This section explains the design rationale, operational mechanics, and failure modes, and provides precise guidance on filtering, metric translation, and PBR with tracking and verification.

Redistribution and Filtering Fundamentals

Routing-domain boundaries, seed metrics, and administrative distance

• Domain boundaries exist wherever different protocols intersect (OSPF/EIGRP/BGP/static/connected). At these edges, redistribution synthesizes reachability across domains.
• Seed metrics are mandatory where the target protocol cannot infer a metric (for example, OSPF external metric, EIGRP composite metric). Without explicit seeds or defaults, redistributed routes may be unusable or severely de-preferenced.
• Administrative distance (AD) arbitrates across protocols. Typical defaults: eBGP 20, static 1, OSPF 110, EIGRP internal 90, EIGRP external 170, iBGP 200. Mixed-AD environments can prefer unintended sources (for example, a redistributed OSPF external might beat an iBGP path if AD is not considered), causing asymmetric routing or loops.

Redistribution risk and two-way controls

• Two-way redistribution (A↔B) can re-inject learned routes back into the originating domain, creating persistent loops or route “feedback.” Control it with:
  • Route tagging to mark origin and block re-entry.
  • Directional filtering to admit only necessary prefixes.
  • Summarization at boundaries to reduce feedback granularity.
  • Passive-default policies: inject only a default or only summarized aggregates where appropriate.
  • AD tuning to ensure the primary domain prefers native routes over redistributed ones.

Route tags and loop-prevention patterns

• Use protocol-supported tags to carry origin metadata:
  • OSPF external LSA tags (32-bit).
  • EIGRP route tags via route maps.
  • BGP community/extended community tags.
• Common pattern:
  • Tag on redistribution into a target domain (for example, set tag 65001 if learned from EIGRP AS 65001).
  • On reverse redistribution, match that tag and deny to avoid re-origination.
• Tag collisions: define a tag plan to avoid overlapping semantics across edges.

Route maps, prefix lists, distribute lists, and filtering granularity

• Prefix lists: best for match granularity on prefixes and masks (supports ge/le operators). Use for both BGP and IGP edges.
• Distribute lists: legacy access-list/prefix-list driven filtering tied directly to a routing process; effective for IGPs but limited context.
• Route maps: versatile policies supporting match on prefix lists, tags, next hops, metrics, communities, and setting actions (metric, tag, type, community, as-path prepend).
• Use route maps when you need to both filter and transform attributes; use prefix lists for efficient, scalable prefix/mask selection.

Route filtering placement: inbound versus outbound

• Inbound filtering:
  • Reduces RIB/FIB growth and CPU by preventing undesired routes from being installed.
  • Preferred when protecting a domain from excessive or toxic updates (for example, BGP edge).
• Outbound filtering:
  • Prevents route leaks and over-advertisement.
  • Enforces export policy and attribute normalization.
• For BGP, always validate outbound route maps to avoid unintended attribute changes (for example, accidental AS-path prepending that increases hop count as seen by neighbors).

Default-route management

• Strategies include:
  • Inject a default only where needed (for example, OSPF default-information originate with a route map).
  • Redistribute static 0.0.0.0/0 carefully; ensure AD and metric-type avoid the default out-competing specific routes.
  • For dual edges (Internet and MPLS), separate defaults per VRF and apply export/import policies to avoid cross-leakage.

Metric Translation and Default-Route Management

Metric translation among OSPF, EIGRP, BGP, and static routes

• OSPF:
  • External routes carry cost and type. Type E1 accumulates internal cost toward the ASBR; E2 is constant by default. Choose E1 when internal path cost should influence exit selection.
  • Set external metrics explicitly to influence path selection across multiple ASBRs.
• EIGRP:
  • Composite metric uses bandwidth, delay, reliability, load, MTU. At redistribution, set at least bandwidth and delay; otherwise routes may be assigned poor metrics and be de-preferenced.
  • Use metric weights K1–K5 only if you must; keep defaults for interoperability.
• BGP:
  • Does not translate IGP metrics directly. Control path preference with local preference (intra-AS), MED (inter-AS hint), AS-path prepending, and weight (local to a router).
  • When redistributing IGP into BGP, use route maps to set communities, MED, and to prevent excess granularity.
• Static:
  • Seed into IGPs with explicit metrics. Beware a static with AD 1 overriding dynamic routes locally; adjust AD per-prefix if needed (for example, ip route 0.0.0.0 0.0.0.0 x.y.z.w 5).

Concise examples

• OSPF ← EIGRP with tags and E1:

  route-map EIGRP-TO-OSPF permit 10
   match tag 0
   set tag 65010
   set metric-type type-1
   set metric 50
  router ospf 1
   redistribute eigrp 10 subnets route-map EIGRP-TO-OSPF
  

• EIGRP ← OSPF with composite metric:

  route-map OSPF-TO-EIGRP permit 10
   match tag 0
   set tag 65020
   set metric 100000 50 255 1 1500
  router eigrp 10
   redistribute ospf 1 route-map OSPF-TO-EIGRP
  

• BGP outbound attribute control (avoid accidental path lengthening of local prefixes):

  route-map OUT permit 10
   match ip address prefix-list EXPORT
   set local-preference 150
  route-map OUT permit 20
  router bgp 200
   neighbor 1.1.1.1 remote-as 65001
   neighbor 1.1.1.1 route-map OUT out
  

  Always include a terminating permit sequence; otherwise, you may inadvertently append attributes (such as AS-path prepends) or drop all other routes.

Default route

• OSPF default with policy:

  route-map OSPF-DEF permit 10
   match interface GigabitEthernet0/0
  router ospf 1
   default-information originate route-map OSPF-DEF metric 10 metric-type 1
  

Policy-Based Routing Design and Operations

Core behavior and matching

• PBR changes the forwarding decision per-packet without modifying the routing table. It is applied inbound on an interface or to locally generated traffic.
• Common match criteria: source/destination prefixes, DSCP/precedence, protocol/port (via extended ACL), next-hop reachability.
• Key set actions:
  • set ip next-hop x.x.x.x [y.y.y.y …]
  • set interface
  • set ip default next-hop x.x.x.x (used only when the route lookup fails)
  • set dscp , set ip precedence

Fallback and availability awareness

• Use next-hop lists for ordered fallback. If the first next hop is unresolved, the router evaluates subsequent next hops.
• Use set ip next-hop verify-availability with object tracking to prefer only reachable next hops; otherwise, PBR can create black holes.

  ip sla 10
   icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
   frequency 5
  ip sla schedule 10 life forever start-time now
  track 10 rtr 10 reachability
  route-map PBR permit 10
   match ip address ACL_PBR
   set ip next-hop verify-availability 198.51.100.1 1 track 10
   set ip default next-hop 203.0.113.2
  interface GigabitEthernet0/1
   ip policy route-map PBR
  

• Local versus interface PBR:
  • Interface PBR (ip policy route-map) processes transit traffic entering that interface.
  • Local PBR (ip local policy route-map) processes traffic originated by the router itself (for example, management sessions, pings). Use carefully to avoid breaking control-plane sessions.

Control-plane and security interactions

• PBR operates in the data path before the normal routing lookup; it does not change the RIB. Verify CEF adjacency resolution for set next-hop.
• Control-plane policing (CoPP) does not police transit data affected by PBR, but it can police routing updates used by redistributed domains. When validating CoPP rates to avoid routing flaps, initially set conform-action transmit and exceed-action transmit while testing ACL classification, then tighten as needed.
• If uRPF is deployed on receiving devices, asymmetric paths created by PBR can cause drops. Use ip verify unicast source reachable-via any where appropriate to allow asymmetric return paths.

Verification, Rollback, and Troubleshooting Strategy

Verification commands

• Route and policy state:
  • show ip route and show ip route vrf to verify reachability per VRF.
  • show ip cef exact-route to observe actual forwarding decisions.
  • show route-map and show access-lists to validate sequence order and matches.
  • show policy-map control-plane to check CoPP effects during instability.
• Protocol-specific:
  • OSPF: show ip ospf database external, show ip ospf border-routers, and check LSA tags; for OSPFv3 interface enablement for IPv4, use ospfv3 1 ipv4 area under the interface.
  • EIGRP: show ip eigrp topology, show ip protocols for redistribution sources.
  • BGP: show ip bgp neighbors x.x.x.x advertised-routes and received-routes; confirm attribute changes (AS-path, MED, communities, local preference) and ensure outbound policies permit non-matched routes when intended.

Troubleshooting workflow

• Identify the symptom category:
  • Missing route: check inbound filters and redistribution policy at the ingress boundary.
  • Wrong path: inspect AD, metric translation, and outbound attribute modifications.
  • Black hole: verify PBR next-hop availability, IP SLA/track state, and ensure “set ip default next-hop” is used only for destinations not in the routing table.
  • Instability/flaps: check loop-prevention tags, filter leaks, and CoPP counters first.
• Inspect policy order:
  • Route-map sequence order matters. A deny sequence in BGP outbound can suppress export, while “permit with no set” passes routes unchanged. Always include a final permit 20 (or similar) to allow non-matched routes when appropriate.
• Validate loop prevention:
  • Confirm tags are set on export and filtered on re-import. Ensure summarization and filtering are symmetric at both edges.
• Rollback and change safety:
  • Use maintenance windows and staged deployment (apply inbound first to protect your domain; then outbound).
  • Keep configuration archives and use configuration replace to revert rapidly.
  • Where possible, apply policies in a VRF lab or on a limited subset of neighbors prior to global rollout.

Short targeted examples

• Inbound BGP subnet filtering to block more-specifics:

  ip prefix-list PL-IN deny 172.16.0.0/16 le 23
  ip prefix-list PL-IN permit 0.0.0.0/0 le 32
  router bgp 100
   neighbor 192.0.2.2 remote-as 200
   neighbor 192.0.2.2 prefix-list PL-IN in
  

• Correct use of route-map defaults to avoid over-constraining:

  route-map SETLP permit 10
   match ip address prefix-list P1
   set local-preference 99
  route-map SETLP permit 20
  

Operational caveats and failure modes

• Mis-seeded metrics result in either all traffic preferring one ASBR or none preferring an otherwise valid path.
• Unintended AS-path prepends or missing terminating permit cause neighbors to perceive local prefixes as being farther away, for example, a locally originated 192.168.130.0/24 being seen two AS hops away instead of one.
• PBR without track/verify-availability can create silent data-plane black holes during next-hop failure.
• Default redistribution without policy can overtake specific routes due to AD differences, causing suboptimal routing or loss of reachability.

Practical Problem Scenario

NorthPeak Media is merging an OSPF-based WAN with an EIGRP-based data center and needs selective Internet breakout via two ISPs. Requirements: prevent redistribution loops, prefer ISP-A for production traffic with automatic failover to ISP-B, and avoid impacting control-plane stability.

Approach

1. Define redistribution boundaries and tags

• Rationale: Two-way redistribution is required between OSPF (WAN) and EIGRP (DC). Tags identify route origin and prevent re-injection.
• Actions:
  • On the EIGRP-to-OSPF ASBR, redistribute eigrp with set tag 65010, metric-type E1, and cost 50.
  • On the OSPF-to-EIGRP ASBR, redistribute ospf with set tag 65020 and an EIGRP composite metric; deny any route with tag 65010 returning from OSPF, and vice versa.

2. Normalize metrics and AD

• Rationale: Ensure OSPF internal routes beat OSPF externals and EIGRP internal beats EIGRP external; avoid iBGP overshadowing IGPs unintentionally.
• Actions:
  • Use E1 for OSPF externals so internal cost to the ASBR influences egress selection.
  • If necessary, raise AD of redistributed statics to avoid trumping specific IGP routes.

3. Control default-route propagation

• Rationale: Only WAN edge should inject 0.0.0.0/0 into OSPF; DC should not leak a default into OSPF or EIGRP unintentionally.
• Actions:
  • On WAN ABR, default-information originate with a route map that matches an up/up ISP interface; metric-type E1 and moderate cost.
  • Do not redistribute static defaults from DC; explicitly deny 0.0.0.0/0 in route-map clauses for redistribution.

4. Apply PBR for selective breakout with IP SLA tracking

• Rationale: Direct production traffic to ISP-A with automatic, fast failover to ISP-B; do not alter the routing table.
• Actions:
  • Create an ACL matching production subnets.
  • Configure ip sla ICMP tests to ISP-A next-hop and track objects.
  • On campus ingress interfaces, apply ip policy route-map PBR-PROD:
    • set ip next-hop verify-availability 1 track
    • set ip default next-hop for destinations not present in the routing table.
  • Leave non-production traffic to follow normal IGP/BGP paths.

5. Safeguard control plane and management traffic

• Rationale: Ensure router-originated sessions and routing adjacencies are not disrupted by PBR or CoPP.
• Actions:
  • Use ip local policy route-map only for specific management-source addresses if needed; otherwise, avoid applying local PBR globally.
  • During CoPP policy activation, initially set conform-action transmit and exceed-action transmit for BGP/OSPF classes to validate ACL matching and rates without inducing flaps; then enforce desired policing.

6. Filter placement and validation

• Rationale: Protect the domain from excessive prefixes and avoid leaks.
• Actions:
  • Inbound prefix lists on BGP neighbors to block undesired more-specifics and bogons.
  • Outbound route maps to set local preference for selected prefixes and ensure a terminating permit.
  • Validate with show ip route vrf (per VRF), show ip bgp neighbors advertised-routes, and show route-map hit counts.

7. Test, monitor, and rollback

• Rationale: Controlled deployment reduces risk.
• Actions:
  • Deploy on a subset of interfaces/neighbors, monitor IP SLA state, and verify PBR counters and CEF adjacencies.
  • Archive the baseline and use configuration replace for rapid rollback if anomalies appear.
  • Confirm no loops by checking route tags end-to-end and verifying absence of re-origination with show ip ospf database external and show ip eigrp topology.

← BGP Policy · All domains · MPLS →

Practice these questions → · Timed practice on ExamRoll.io →