Parks and Recreation runs IP SLA probes over a small LTE backup link and sets an extremely aggressive frequency. Staff then see the backup link congested by the probes themselves. What is the sound operational takeaway?
Select an answer to reveal the explanation.
Short Explanation
If your health check is louder than the patient, you have a problem. On a skinny LTE backup, hyperactive IP SLA probes can eat the very bandwidth you meant to watch.
Full Explanation
Parks and Recreation runs IP SLA probes over a small LTE backup link and sets an extremely aggressive frequency, then sees the backup link congested by the probes themselves. The sound operational takeaway is that probe frequency and packet size must be tuned so monitoring does not starve the link being measured. On constrained LTE backup paths, high-rate probes can consume scarce bandwidth, inflate latency, and falsely suggest the backup path is unusable—or actually make it unusable for failover traffic.
Claiming IP SLA frequency has no bandwidth impact because probes use out-of-band channels only fails by concept: probes traverse the same data path unless a truly separate OOB network exists, which LTE backup here is not implying. Saying aggressive timers automatically compress into Flexible NetFlow summaries confuses SLA probing with flow export aggregation. Claiming LTE links ignore IP SLA packets so frequency can always be minimum is false; LTE carries those packets like any other IP traffic subject to rate limits and congestion.
Exam caveat: monitoring has a cost—especially on low-bandwidth backup/cellular links. Design probe intervals and sizes with the measured path’s capacity and the municipal failover use case in mind.
Operational check for Parks and Recreation: baseline LTE capacity, set IP SLA frequency/size conservatively, confirm probes leave headroom for real failover traffic, and re-validate after changes so assurance does not become the outage.