docs: document migrating a static external attachment to BGP - #351
Merged
Merged
Conversation
Static-ness is per-attachment, not per-External, so one External can have both a static and a BGP attachment at once. Document the migration sequence and its two sharp edges: the attachment conversion and dropping spec.static can't be applied atomically, and BGP communities need to be configured on the External after the migration since they can't be set while it's still static. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Pau Capdevila <pau@githedgehog.com>
|
🚀 Deployed on https://preview-351--hedgehog-docs.netlify.app |
Two back-to-back warning admonitions read like an afterthought list; fold both sharp edges into a single warning with two bullets instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Pau Capdevila <pau@githedgehog.com>
The prior wording attributed the outage window to attachment/External static-flag mismatch causing the switch to skip programming the BGP link. Re-verified against a freshly fetched fabric@origin/master: the switch-agent gates BGP route-exchange per attachment (extHasBGP), not on the External's own static flag, so that part was wrong -- the earlier read was against a stale, pre-feature local checkout. The real mechanism: the API forbids setting inboundCommunity/ outboundCommunity while any static prefix remains on the External, to protect the static route's own EVPN re-origination. That's what forces step 3 to wait for step 2, and it's the actual reason a community- filtering Edge Device drops everything the Fabric advertises until step 3 completes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Pau Capdevila <pau@githedgehog.com>
edipascale
reviewed
Sep 21, 2026
Per review feedback from the feature's author: since this BGP session is new, there's no prior community filter on the Edge Device to conform to. Coordinating with the Edge Device operator to defer community-based filtering until after the migration avoids the gap entirely, when that coordination is possible. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Pau Capdevila <pau@githedgehog.com>
edipascale
approved these changes
Sep 21, 2026
edipascale
left a comment
edipascale
left a comment
Contributor
There was a problem hiding this comment.
maybe let's squash the commits into a single one, other than that LGTM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
ExternalAttachmentstatic-ness is per-attachment, not per-External, so oneExternalcan carry both a static and a BGP attachment at once - document the migration sequence from static to BGP.spec.staticcan't be applied atomically, andinboundCommunity/outboundCommunityneed to be set on theExternalafter migrating, since the API forbids setting them while it's still static.