feat(containerlab): Add two-node gateway canary

[privateip]

Summary

The manifests from the previous PR need a lab environment to exercise before anyone runs them in a real cluster. This adds a dedicated active-active pair of gateway-role nodes to the containerlab topology, with the FRR underlay, route-reflector peering, and per-node overlay each needs, plus a canary NetworkRule pointed at a live backend pod. Seventh branch in the edge-gateway stack; builds on the config manifests PR.

Test plan

• sudo containerlab lab deploy brings up the two gateway nodes and their BGP sessions
• The canary NetworkGateway/NetworkRule CRDs reconcile without error

Note

End-to-end ingress traffic through the datapath doesn't reach a backend in this topology yet — a veth-specific XDP_TX behavior, not a code bug.

Related to #17

[ecv]

Holding off on approval here too, for one specific thing rather than the canary.

This PR adds COPY --from=network . /network to containers/galactic-router/Dockerfile, not only the gateway one. That is the image the publish pipeline ships today, and publish.yaml passes no build-contexts input, so the router image build breaks the moment this reaches main. The Dockerfile comment already anticipates this and says callers that do not pass the context must not hit it; publish.yaml is exactly such a caller. Same root cause as #358, and both COPY lines should come out when the replace does.

The lab side is the same coupling wearing different clothes: Taskfile.yaml passes --build-context network=../../../network for three images, and deploy-system.sh reads the new CRDs out of ../../../../network/config/crd. Local dev tolerates that better than CI does, but it means the lab now requires two checkouts in a specific layout with nothing checking for it up front. A clear failure early beats whatever Docker says when the context is missing.

On the canary itself, no objection. The topology, addressing and ASNs read consistently.

One thing worth calling out in the description rather than leaving in the diff: this removes the ns50 tenant entirely, including verify-ns50.sh, and replaces it with ns60. That trades a three-site IPv4 tenant for a single-site IPv6 one. You did update every reference, docs included, so nothing dangles. But anyone who used task deploy:ns50 for IPv4 coverage loses it, and that is the kind of change people should meet in the PR body rather than discover.

Also worth saying plainly, since the task description already half admits it: verify:gateway checks that CRDs are present, not that a packet crossed the datapath. A canary that passes without proving traffic flowed is the failure mode canaries exist to prevent. Fine as a first cut, but it should not stay that way once the lab can actually pass traffic.

[ecv]

Approving, with one thing that is about merge order rather than about this diff.

The COPY --from=network line this adds to containers/galactic-router/Dockerfile makes the currently-shipping router image unbuildable by the publish pipeline, which passes no build context. That is real, but CI shows it, and it disappears with the same fix as #358. So it is a sequencing constraint, not a reason to hold the branch: this should not land ahead of the module re-pin, and both COPY lines want to come out when the replace does.

Filed the canary's coverage gap as #368. Checking that the resources exist and the pods are up is a reasonable first cut, and it is also the exact shape of pass that the detached-program failure would have sailed through. Worth an assertion that a packet reached a backend and that the rule's counters moved before this is treated as datapath coverage.

The ns50 to ns60 swap I would still put in the PR body. You updated every reference, so nothing dangles, but losing the three-site IPv4 tenant is the kind of thing people should read rather than discover.

Topology, addressing and ASNs all read consistently.