Database/Firmware, BMC & network fabric

Arista EOS (secure VXLAN / Tunnelsec agent): TENANT ISOLATION: after the Tunnelsec agent restarts, traffic that should
Impact
TENANT ISOLATION: after the Tunnelsec agent restarts, traffic that should be encrypted inside secure VXLAN tunnels goes out in cleartext. You configured tunnel encryption between sites or between pods, the agent bounced, and now every tenant's overlay traffic is readable by anyone with a tap on the underlay — with no alarm, because the tunnels still look up. This is the worst kind of fabric bug: the control plane reports healthy while the confidentiality guarantee is silently gone.
Who can reach it
Passive attacker with access to the underlay path the VXLAN tunnels traverse — a dark-fibre tap, a transit provider, a compromised intermediate switch, or another tenant with underlay visibility. Requires the Tunnelsec agent to have restarted, which happens on upgrade, crash, or config change.
What to do
EOS upgrade plus a switch reload on every VTEP running secure VXLAN. Until then, monitor Tunnelsec agent restarts and treat any restart as a confidentiality incident for traffic since that moment. There is no config workaround that keeps encryption on across a restart.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.