A fire-district IT team redistributes static routes for fire-station WANs into EIGRP and must assign a controlled composite metric. Which route-map capability provides that metric during redistribution?
Select an answer to reveal the explanation.
Short Explanation
You need to give redistributed static routes an EIGRP metric rather than expect EIGRP to infer one. Use set metric in the redistribution route-map to assign the bandwidth, delay, and other EIGRP components to the matched station routes. That gives you a controlled composite metric for them.
Full Explanation
EIGRP advertises routes using a composite metric, commonly based on bandwidth, delay, reliability, load, and MTU components as configured. Static routes do not inherently carry that EIGRP metric, so the redistribution route-map should use set metric with the appropriate components to give matched station WAN routes a controlled, predictable seed metric. Matching a route tag alone selects routes; it does not create bandwidth or delay, so that action does not solve the metric requirement. Setting local-preference is a BGP action, and EIGRP neighbors do not convert it into delay. Setting origin igp changes a BGP ORIGIN attribute; it does not assign an EIGRP metric and has no role in OSPF stub areas. Exam caveat: a seed metric of infinity makes redistributed statics unreachable, and EIGRP wide-metric or classic-metric settings and K-values must be consistent across the autonomous system. Operational check: use show ip eigrp topology <station-prefix> to verify the redistributed static appears as an external with the intended composite metric values, and inspect the route-map and EIGRP configuration to confirm set metric is applied to the redistribution.