Incidents/2022-11-15 asw1-eqsin

== Summary ==
Connecting a new server to our eqsin top of rack switches triggered a Juniper bug which caused one of its processes to be killed and interrupting traffic transiting through the switch. This event caused also a Virtual-Chassis master switchover extending the outage. The process got automatically re-started and the situation stabilized by itself in about 5min.
==Timeline==
Write a step by step outline of what happened to cause the incident, and how it was remedied. Include the lead-up to the incident, and any epilogue.
Consider including a graphs of the error rate or other surrogate.
Link to a specific offset in SAL using the SAL tool at https://sal.toolforge.org/ (example)
All times in UTC.
*04:51 (TODO) OUTAGE BEGINS
*00:04 (Something something)
*00:06 (Voila) OUTAGE ENDS
*00:15 (post-outage cleanup finished)
TODO: Clearly indicate when the user-visible outage began and ended.
==Detection==
Write how the issue was first detected. Was automated monitoring first to detect it? Or a human reporting an error?
Copy the relevant alerts that fired in this section.
Did the appropriate alert(s) fire? Was the alert volume manageable? Did they point to the problem with as much accuracy as possible?
TODO: If human only, an actionable should probably be to "add alerting".
==Conclusions ==
OPTIONAL: General conclusions (bullet points or narrative)
===What went well?===
* The situation stabilized by itself
* Juniper was able to match the crash to a known bug (even though our code version is not supposed to be vulnerable to this bug)
* automated monitoring detected the incident
===What went poorly?===
* Nobody was paged despite the outage to be user impacting to be verified
* Nobody present during the outage opened a task documenting what happened
* Such improbable bug
===Where did we get lucky?===
*
==Links to relevant documentation==
* Network monitoring#virtual-chassis crash
==Actionables==
* Upgrade POPs asw to Junos 21 - https://phabricator.wikimedia.org/T316532
* We're phasing out virtual chassis in the new POP network designs (cf. drmrs). Even though such bugs might always be a possibility, the new design is more resilient (each switch is independent)
==Scorecard==
Incident Engagement ScoreCard
 	Question 	Answer
(yes/no)	Notes
People 	Were the people responding to this incident sufficiently different than the previous five incidents? 	yes	
People 	Were the people who responded prepared enough to respond effectively 	no 	
People 	Were fewer than five people paged? 	no 	no pages
People 	Were pages routed to the correct sub-team(s)? 	no 	no pages
People 	Were pages routed to online (business hours) engineers?  Answer “no” if engineers were paged after business hours.	no 	no pages
Process 	Was the incident status section actively updated during the incident? 	no 	
Process 	Was the public status page updated? 	no 	
Process 	Is there a phabricator task for the incident? 	yes	
Process 	Are the documented action items assigned? 	yes	
Process 	Is this incident sufficiently different from earlier incidents so as not to be a repeat occurrence? 	yes	
Tooling 	To the best of your knowledge was the open task queue free of any tasks that would have prevented this incident? Answer “no” if there are
open tasks that would prevent this incident or make mitigation easier if implemented.	no 	
Tooling 	Were the people responding able to communicate effectively during the incident with the existing tooling? 	no 	
Tooling 	Did existing monitoring notify the initial responders? 	yes	
Tooling 	Were the engineering tools that were to be used during the incident, available and in service? 	yes	
Tooling 	Were the steps taken to mitigate guided by an existing runbook? 	no 	auto-resolved
Total score (count of all “yes” answers above)	Total score (count of all “yes” answers above)