Conversation
|
The CI build is now broken since the |
I'm *pretty* sure it's fine to just put back the original behavior on Medusa, since Medusa just tests the front-IO board in isolation, and thus there wouldn't ever be a situation where it would encounter a looped-back backplane connector since Those Don't Exist When You're Just A Front IO Board. But I'll ask a person who actually knows about such things to be sure.
|
Per https://github.com/oxidecomputer/mfg/issues/38#issuecomment-3955324142, this has been confirmed to fix the Reverso situation at the CM. So we should probably try to merge this now. |
|
I haven't looked closely at this, but I have a high level question: is the new "-reverso" sidecar image variant the same as "-dev" images? Viz., including all the udprpc remote debug stuff, etc. it seems like it would be good for that to be the case, given we're in a very debug test rack situation at all times. |
Yes it inherits the -dev flavored TOML! |
|
This LGTM, has this change been tested on a regular sidecar just to extra special make sure we haven't broken the existing behavior? |
5 participants
Note
This is just @mkeeter's PR #2226, but rebased onto the latest
master, since it turns out we actually do need this. I had wanted to just re-open Matt's original PR but github would not let me do this for some kind of reason I really don't fully understand. Anyway, heeeeeere's Matt Keeeeeeeterrrr!!!"Reverso" is a board with the same form factor as a Gimlet which loops back the two backplane connectors.
In this configuration, packets leaving the VSC7448 destined for SP i instead arrive at the peer Sidecar, appearing to have originated at SP i.
In the unlocked VLAN configuration, this is a problem: packets can arrive at one tech port and emerge from the other tech port, which creates a routing loop. When this happens, our CM's network unceremoniously turns off the offending network port, and we have to manually get it re-enabled.
This PR adds a
VlanTargetsparameter to unlock-related code:VlanTargets::EverySpis our existing behavior, where the technician port can communicate with every cubbyVlanTargets::ScrimletOnlylimits technician ports to only communicate with Scrimlet cubbies, which are guaranteed to be populatedBy preventing the technician port from talking to cubbies with Reverso installed, we can avoid network loops.
The switch zone in the scrimlet can still communicate with every cubby; indeed, this is how we expect to test connectivity with Reverso installed.