A university edge router keeps dropping and restoring its BGP session toward the upstream provider. What should notify the network team?
Select an answer to reveal the explanation.
Short Explanation
A door that keeps banging needs a bell on the frame, not a note to study the hallway later. You alert on the BGP session state so the flap pages the network team. A student CPU alert, a dashboard with no rule, or a capacity study either watches the wrong thing or pages nobody.
Full Explanation
A BGP session that drops and then restores is a routing-state event, and the notification that matches it is an alert on that session state. An alert on the BGP session state at the campus edge pages the network team when the session flaps, which is the condition the university is seeing. An end-user CPU alert aimed at one student laptop watches an endpoint processor. The session can flap while that CPU is idle, and a busy laptop can page while BGP is stable. A BGP dashboard that shows the flaps but has no alert rule is visibility without notification. Someone must already be looking, or the flap passes with no page. A capacity study that reviews the campus edge and does not page anyone may inform a later design change. It does not notify anyone when the session state changes. Exam caveat: BGP state is a network-condition alert, and it is distinct from an end-user CPU rule and from a review that never notifies. Operational check: under a change window, confirm the alert fires when the session state drops and clears after the session stays established.