A library consortium wants traffic to prefer one WAN exit by influencing the EIGRP composite metric on an interface. Which inputs most directly feed that classic composite metric?
Select an answer to reveal the explanation.
Short Explanation
EIGRP’s scorecard is mostly "how skinny is the skinnier pipe?" (bandwidth) and "how long does the trip feel?" (delay), stirred by the K-value recipe. Nudge bandwidth or delay on the library exit you like, and the composite metric follows.
Full Explanation
The classic EIGRP composite metric is driven primarily by the minimum bandwidth along the path and the cumulative delay, weighted by the configured K-values (with other K components available but often unused in default recipes). To make a library-consortium WAN exit preferred, operators influence bandwidth and/or delay on the relevant interfaces so the composite metric improves for that exit relative to alternatives. Hello and hold timers affect detection, not the composite path score; administrative distance selects among routing sources, not among EIGRP path metrics inside the process.
Hop count and administrative distance alone fail by concept as the composite inputs: hop count is not the classic EIGRP scorecard, and AD is not an EIGRP metric component. Copying OSPFv2 cost and BGP MED into the EIGRP topology table is not how EIGRP computes its composite metric. Using only hello interval and hold time on the preferred exit fails because those timers do not feed the bandwidth/delay composite.
Exam caveat: changing bandwidth/delay for metric influence must be consistent with operational documentation—cosmetic bandwidth changes affect EIGRP path preference and can surprise QoS or capacity planning if misunderstood. Operational check: before and after tuning on the preferred library exit, capture show interface bandwidth/delay, show EIGRP topology metrics for the target prefixes, and confirm the desired exit becomes successor without breaking FS eligibility on backups.