Add patch for FRR with regression fix for MAC mobility #1321
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change introduces a patch to our pinned FRR version which fixes a regression affecting MAC mobility (and hence VM migration) introduced between 10.0 and 10.1.
Depending on ordering between different hosts, a receiving KVM host may learn the MAC address of a migrating guest before the sending host stops announcing it. Due to the regression, bgpd would frequently decide that the remote route was a "better" route than the locally learned route and thus delete the latter, which would mean that when the remote route was withdrawn when the migration completed, bgpd would not announce a route for the locally learned MAC.
This would lead to routes for guest MAC addresses going missing, causing unnecessary flooding from the other hosts in the EVPN fabric and eventually to site-wide network performance degradation.
This regression has been fixed upstream and backported to the stable branch, but is yet to appear in a 10.1.x stable release.
PL-133422
@flyingcircusio/release-managers
Release process
Created changelog entry using./changelog.sh
PR release workflow (internal)
Design notes
on
oroff
. Example: rate limiting.Security implications