A developer automates nightly checks on 60 IOS XE switches with Netmiko. Some devices take close to a minute to answer, and the change report needs hostname, model and software release as separate fields for every switch it checks. Which Netmiko call pattern meets those timing and parsing needs?
Select an answer to reveal the explanation.
Short Explanation
You need Netmiko to allow for slow responses and return structured data you can map into separate report fields. A raised read_timeout gives a minute-long response time to finish, while TextFSM can parse the output when a matching template is available.
Full Explanation
The required pattern combines enough time for slow responses with structured parsing: send_command with use_textfsm enabled and a raised read_timeout can accommodate devices that take close to a minute and parse supported command output. Mapping the parsed hostname, model, and software release into separate report fields then meets the reporting requirement for every checked switch. Using TextFSM at its default timeout can produce the needed separate fields, but devices that take close to a minute may time out before their output is collected. Raising read_timeout without TextFSM and extracting only the software release allows more time, but leaves hostname and model unavailable as separate fields, so the report is incomplete. Enabling TextFSM and raising read_timeout handles timing and parsing, but putting all parsed values in one JSON report field does not meet the requirement for separate fields. Exam caveat: TextFSM parsing depends on a matching template being available for the command and platform; enabling it does not guarantee every device's output will parse. Practical check: test representative IOS XE outputs, confirm the parsed keys and report-field mapping, and verify that the configured timeout exceeds observed response times.