vlab: generate wiring for externals

[edipascale]

Generate wirings for externals as part of hhfab vlab gen. Add parameters to determine how many externals and external connections are created, and where the ext. connections are placed (i.e. mclag, eslag or orphan leaves).

All attachments are currently vlan tagged, I didn't want to over complicate things with extra params for untagged.
Also all externals are in the same namespace, and attachments are created for all externals and all connections.

Closes: #521

[Copilot]

Pull Request Overview

This PR adds functionality to generate wiring for externals as part of the vlab generation process on top of a previous MR. It introduces new parameters to control the number of externals and their associated connection types, adds validation and logging for these parameters, and creates external entities along with their attachments.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
pkg/hhfab/vlabbuilder.go	Adds parameters, validations, and logic for generating and attaching externals
cmd/hhfab/main.go	Introduces new CLI flags to handle external generation parameters

[edipascale]

I've added commits to also address #522, but we have a problem here:

• I've set the default to 1 external and 1 connection on an eslag leaf, similar to what we have in physical envs
• however, in collapsed-core mode only mclag switches are created, which means that the defaults are now invalid for this mode
• and on the other hand, we don't want to default to mclag externals because of test-connectivity failure with (virtual) external peerings from mclag leaves #524

In terms of having the ci passing, it would be easy enough to add explicit values to the vlab-gen for either the collapsed-core (if we keep the defaults as described above) or the spine-leaf cases (if we do not touch the current default). The question is what is the "least undesirable" option @Frostman

[Frostman]

We should probably generated conns to external from the the from both switches of the last redundancy group configured. Let's chat next week and discuss what would be the best approach.

[edipascale]

current status:

• the changes in release-test to use the first external have to be reverted or at least adapted; we cannot use virtual externals for most scenarios, as multiple external peerings (together with the limitation on virtual switches and ACLs) mean that VPCs will be able to ping each other even when they shouldn't. We can either revert the change, or fetch the annotations for externals and discard non-hardware ones.
• on top of that, there is https://github.com/githedgehog/internal/issues/145 which makes test-connectivity jobs with the new external peering fail in the ci

[edipascale]

current status:

• the changes in release-test to use the first external have to be reverted or at least adapted; we cannot use virtual externals for most scenarios, as multiple external peerings (together with the limitation on virtual switches and ACLs) mean that VPCs will be able to ping each other even when they shouldn't. We can either revert the change, or fetch the annotations for externals and discard non-hardware ones.

I went for the second option but it's not perfect. Technically the issue is not with virtual externals, but with virtual switches attached to any type of externals. Because right now we only have hardware externals connected to hardware switches and virtual externals connected to virtual switches, discarding virtual externals is the easy solution... but we probably want to revisit it.

• on top of that, there is troubleshoot virtual external peering with active connections on multiple leaves internal#145 which makes test-connectivity jobs with the new external peering fail in the ci

I've already got an answer from BCM on the case I opened requesting more info, which I provided; let's see if we can get unblocked there. In the meanwhile I reduced the autogenerated external connections from 2 to 1, which should work even with this strange issue.

Also I'm seeing several failures in the CI, both here and in other PRs. but they do not appear related to the changes. I'll dig a bit more tomorrow.

[edipascale]

@Frostman this is technically ready to review now. I've removed the default external generation as discussed, and added warnings in case an option with multiple external connections is selected. The only thing missing is a run on a physical environment to check whether we need any additional fix for https://github.com/githedgehog/lab/issues/247, unsure whether we want to wait for that before tagging this as ready

[edipascale]

I could finally check this on physical environments, please see https://github.com/githedgehog/lab/issues/247 for details but this should be ready to be reviewed