After migrating to EIGRP named mode, a school-district WAN team notices metric values in show outputs look different from classic scaled metrics. What should troubleshooters understand?
Select an answer to reveal the explanation.
Short Explanation
Named mode often shows the "wide" yardstick—bigger numbers, finer resolution—not a broken network. School-district techs should compare paths with that wide-metric lens instead of hunting for a classic 32-bit value that no longer prints the same way.
Full Explanation
After migrating to EIGRP named mode, school-district WAN operators commonly see wide (64-bit) metric calculations in show outputs rather than classic 32-bit scaled metric displays. Wide metrics increase resolution of the composite calculation; larger printed numbers can still reflect a correct preference order. Troubleshooters must interpret path preference with wide-metric awareness instead of assuming the network is broken because values no longer match old classic scaled scratch paper.
Claiming named mode deletes delay and leaves hop count as the only metric fails by concept: delay and bandwidth remain central composite inputs under wide metrics. Claiming wide metrics appear only when BFD is enabled fails—wide metrics are a named-mode/metric-computation presentation, not a BFD side effect. Claiming any display change means K-values automatically reset to zero fails; migration does not zero K-values as the explanation for larger metric readouts.
Exam caveat: compare relative preference and successor/FS relationships, not absolute classic-versus-wide numeric equality across pre/post migration captures. Operational check: pick representative school-district prefixes, confirm successor choice still matches design intent under wide metrics, document expected wide values for baselines, and avoid “fixing” bandwidth/delay just to recreate old 32-bit numbers.