Engineers must choose telemetry publication style for interface counters to graph and for interface admin-state that should wake a consumer only when it flips. Which consumption choice is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Counters like a pulse want a steady metronome; a door sensor should chirp only when it moves. Cadence for graphs, on-change for state flips—pick wrong and you flood or starve.
Full Explanation
Publication style should match how consumers use the data. Interface counters destined for graphs need periodic cadence samples; interface admin-state that should wake a consumer only when it flips fits on-change notifications. Choosing cadence for counters and on-change for state gives municipal ops useful time series without flooding the bus on every counter tick treated as a “change,” and without delaying rare state events until the next slow poll-like interval.
Using on-change for high-rate counters and cadence for rare state flips so graphs stay empty inverts the fit: counters may chatter uselessly or fail to graph smoothly, while state updates arrive late. Publishing every YANG tree on both cadence and on-change with no path filtering wastes bandwidth and storage across the civic fleet. Disabling all subscriptions and polling SNMP GET exclusively for both cases abandons MDT’s value when the stem asks for an appropriate consumption choice.
Exam caveat: not every leaf supports on-change; verify model capabilities on IOS XE. Cadence intervals must balance freshness against collector and WAN capacity for edge routers.
Operational check: subscribe counters at a modest cadence and admin-state on-change, then flap an interface and confirm a timely state event while counter series remain evenly sampled in the store.