You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SRv6 decap drops off the second uplink bond when the FRR underlay restarts #778
When the FRR underlay on a site restarts, nodes remove the SRv6 decap hook from their second uplink bond and that bond's member ports, then put it back 6 to 14 seconds later, so tenant traffic arriving on that bond is lost for that window on every release that restarts FRR.
The second bond is picked up only because BGP-learned routes point through it, and FRR withdraws those routes from the kernel while it restarts.
Two Envoy requests to a VM returned 503 during the 2026-10-07 staging rollout of #777, while its compute node flapped twice.
Acceptance criteria
An FRR restart leaves the decap hook on every uplink bond and member port for the whole restart
An uplink that genuinely stops carrying fabric routes still loses the hook, after a delay long enough to ride out route churn
Seen on three of the four staging nodes during the #777 rollout. On each, the second bond and its two member ports dropped out of the attached interface set 11 to 29 seconds after startup and came back 6 to 14 seconds later. One compute node did it twice in a row. The #776 build showed the same pattern, so this predates #777.
The interface set comes from autoDetectInterfaces, which takes default-route links first and then links carrying a BGP-learned route (isFabricPeerRoute). The default-route bond never moves. The second bond is found only through fabric routes, and the watch loop's reconcile detaches usid_ingress from a removed interface on the first re-evaluation that misses it.
A hold-down before detaching would cover the first criterion, as would keeping any bond master or slave seen at startup until its routes stay gone for a while. What moves the fabric routes off the second bond in the first seconds after a restart is not yet known.
changed the title [-]SRv6 decap drops off the second uplink bond after a CNI restart[/-][+]SRv6 decap drops off the second uplink bond when the FRR underlay restarts[/+]on Oct 7, 2026
Correction: the trigger is the FRR underlay restarting in the same rollout, not the CNI installer, since on every flapping node the drop lines up with that site's FRR pods restarting and the detection code is unchanged since v0.5.3.
Activity
privateip commentedon Oct 7, 2026
Seen on three of the four staging nodes during the #777 rollout. On each, the second bond and its two member ports dropped out of the attached interface set 11 to 29 seconds after startup and came back 6 to 14 seconds later. One compute node did it twice in a row. The #776 build showed the same pattern, so this predates #777.
The interface set comes from
autoDetectInterfaces, which takes default-route links first and then links carrying a BGP-learned route (isFabricPeerRoute). The default-route bond never moves. The second bond is found only through fabric routes, and the watch loop'sreconciledetachesusid_ingressfrom a removed interface on the first re-evaluation that misses it.A hold-down before detaching would cover the first criterion, as would keeping any bond master or slave seen at startup until its routes stay gone for a while. What moves the fabric routes off the second bond in the first seconds after a restart is not yet known.
[-]SRv6 decap drops off the second uplink bond after a CNI restart[/-][+]SRv6 decap drops off the second uplink bond when the FRR underlay restarts[/+]privateip commentedon Oct 7, 2026
Correction: the trigger is the FRR underlay restarting in the same rollout, not the CNI installer, since on every flapping node the drop lines up with that site's FRR pods restarting and the detection code is unchanged since v0.5.3.