oxidecomputer / oxidecomputer/maghemite
forwarding plane dedup
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 94
- Forks
- 6
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 12
Description
When reviewing #650 it occurred to me that there are situations in which we can multiple paths in the RIB that are functionally the same from the perspective of forwarding. This has the potential to adversely skew forwarding behaviors such as ECMP. Consider the example where your max fanout is 2, you have 4 routes in the rib, 3 of which are functionally the same (same nexthop) and the two that you select for installation into the forwarding plane are two of the equivalent routes. This circumvents what most people would want there which is path diversity in the forwarding plane.
We should probably be performing some form of deduplication during or prior to bestpath selection to ensure this sort of unfortunate skew does not occur.
Contributor guide
No contributing guide indexed for this repository
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.
Research direction
Start by reviewing issue #650 and tracing the RIB and bestpath-selection flow described here. Determine where functionally equivalent routes should be deduplicated before forwarding-plane selection, then verify that a max fanout preserves path diversity with tests covering equivalent next hops.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100