Known limitations: state that the 1 minute black-hole bound depends on the Fabricator version
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- documentation, networking
Research direction
Open docs/known-limitations/known-limitations.md and locate the entry about traffic being black-holed for up to 1 minute after a host changes IP within its L3VNI VPC subnet. Verify the wording distinguishes Fabric v0.126.0 and later from earlier releases, while preserving the existing diagnosis and static DHCP lease workaround.
Written by the indexing model from the issue text.
Description
The entry "Traffic gets black-holed for up to 1 minute if a host changes IP within its L3VNI VPC subnet" in docs/known-limitations/known-limitations.md gives the window as up to 1 minute. That number is not a property of the defect, it is the result of the Fabric agent setting the drop-neighbor aging time to 60 seconds, which is the lowest value the platform accepts. Without that setting the platform default applies and the black-hole lasts up to 5 minutes.
The agent only began setting it in Fabric v0.126.0. A user running an earlier version who follows the current wording will measure roughly 5 minutes, conclude the documentation is wrong, and have no way to tell whether they are hitting the documented limitation or a different problem.
Proposed change to that section:
- state that up to 1 minute applies from the release that ships Fabric v0.126.0 onward, and that earlier releases see up to 5 minutes
- keep the existing diagnosis and the static DHCP lease workaround as they are
- Dominant language
- Just
- Stars
- 6
- Forks
- 12
- Avg merge
- 18h 48m
- Merged PRs (30d)
- 9
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from githedgehog/docs
-
VM ctrl/gw recommendations: xcp-ngMay be free again @mrbojangles3 claimed this 83 days ago, and no pull request is open. Open
githedgehog/docs#326 · 1 assignee ·
Maintainers usually reply within 1 day
-
Evaluate New Docs FrameworkMay be free again @mrbojangles3 claimed this 108 days ago, and no pull request is open. Open
githedgehog/docs#315 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
githedgehog/docs#309 ·
Maintainers usually reply within 1 day
-
Add section on Gateway peering with NAT externalsMay be free again @mrbojangles3 claimed this 321 days ago, and no pull request is open. Opendocumentation
githedgehog/docs#218 · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
githedgehog/docs#214 · 4 comments ·
Maintainers usually reply within 1 day
All issues in githedgehog/docs
Similar issues
-
accepting PR Content:HTML
Difficulty 1/5 Under an hour Newbie friendliness 88/100
mdn/content#45988 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
pyca/verified-garbage#1023 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
quickemu-project/quickemu#1960 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100