feat: frr external for vlab testing #450
Conversation
edipascale
force-pushed
the
ema/vlab-external-testing
branch
4 times, most recently
from
6eb4a15 to
2837b13
Compare
edipascale
force-pushed
the
ema/vlab-external-testing
branch
from
2837b13 to
50c23c4
Compare
|
after troubleshooting this with @Frostman last week we realized there is something weird when using google's dns as the curl target on top of the external natting, and while we did not find the root cause, for now I will change the target to cloudflare's dns, which appears to work reliably. Note that the PR is still marked as draft because I realised there is a problem with multiple external peerings: test-connectivity will fail because pings between the VPCs peered with the externals will go through it and succeed, regardless of vpc peerings. I must tune the iptables rules in the external so that traffic coming from the fabric cannot be forwarded back to it directly - i.e. without going through the internet-facing interface first. EDIT: on closer inspection, it looks like pings actually go through the leaf connected to the external and not through the external itself, so this cannot be fixed there. I'm guessing there are ACLs in place in real switches to prevent that, and that with vlab we cannot implement this, is this correct? |
edipascale
force-pushed
the
ema/vlab-external-testing
branch
2 times, most recently
from
d831235 to
ee9ee26
Compare
Frostman
force-pushed
the
ema/vlab-external-testing
branch
from
ee9ee26 to
a4be368
Compare
cmd/hhfab/main.go
Outdated
| @@ -763,6 +764,11 @@ func Run(ctx context.Context) error { | |||
| Usage: "collect show-tech from all devices at exit or error", | |||
| EnvVars: []string{"HHFAB_VLAB_COLLECT"}, | |||
| }, | |||
| &cli.BoolFlag{ | |||
There was a problem hiding this comment.
Let's just always try to spawn the VM for externals, but skip it if no externals configured or smth like this
pkg/hhfab/vlabconfig.go
Outdated
| extAttach := extAttachments.Items[0] */ | ||
| // HACK: get the attachment by name since we cannot use labels | ||
| extAttach := &vpcapi.ExternalAttachment{} | ||
| if err := wiring.Get(ctx, client.ObjectKey{Name: fmt.Sprintf("%s--%s", switchName, extName), Namespace: conn.Namespace}, extAttach); err != nil { |
There was a problem hiding this comment.
Unfortunately we have to search for a right ExtAttach as we can't rely on the names. It's required anyways for resolving the previous comment
if starting the vlab with the --externals option, a new "external" vm will be created representing the external peering device. It runs FRR and it is autoconfigured from the wiring information. Note that there are several caveats: - there is no monitoring of changes to the wiring once the initial configuration step is completed - on any given connection, you can have several vlan tagged attachments OR an untagged one, but not a mix of both, due to an issue where outgoing untagged taffic from the vm gets tagged with vlan 4095 if there are vlan subinterfaces on it - since virtual switches do not support ACLs, peering multiple VPCs to the same external on a virtual switch will result in those VPCs being able to talk to each other, breaking connectivity tests; this is not a limitation of this patch Signed-off-by: Emanuele Di Pascale <[email protected]>
to workaround a weird issue we are seeing with google dns and vlab external testing Signed-off-by: Emanuele Di Pascale <[email protected]>
Signed-off-by: Sergei Lukianov <[email protected]>
edipascale
force-pushed
the
ema/vlab-external-testing
branch
from
69855c0 to
50d6799
Compare
if starting the vlab with the --externals option, a new "external" vm will be created representing the external peering device. It
runs FRR and it is autoconfigured from the wiring information.
Note that there are several caveats:
Closes https://github.com/githedgehog/internal/issues/78