[ObuMan]

Added DHCP relay support for the Nokia SR Linux provider (internal/provider/nokia/srlinux).

• Implements EnsureDHCPRelay and DeleteDHCPRelay on the SR Linux Provider, reaching feature parity with the existing Cisco NX-OS implementation.
• Uses native Nokia YANG models (srl_nokia-interfaces / srl_nokia-interfaces-ip-dhcp-relay), targeting the per-subinterface gNMI path:
  srl_nokia-interfaces:interface[name=<iface>]/subinterface[index=<n>]/ipv4/srl_nokia-interfaces-ip-dhcp-relay:dhcp-relay
• Parses the subinterface index from the interface name suffix (.N) - e.g. ethernet-1/1.100 → interface ethernet-1/1, subinterface index 100.
• Sets admin-state: enable explicitly on every reconcile because it is the platform default; omitting it would produce a false diff on every subsequent GET.
• Supports optional cross-VRF relay via vrfRef: when set, the resolved VRF's spec.name is written to network-instance; when unset the field is omitted from the payload (platform default is "no network-instance").
• Handles the deprecated interfaceRefs path the same way as the Cisco provider: returns nil without touching the device.

Testing

Tested manually against an emulated Nokia SR Linux device (ghcr.io/nokia/srlinux:26.7.1)

SR Linux has no InterfaceProvider yet, so the subinterface was pre-configured directly on the device and the Interface CR status was faked:

gnmic -a 192.168.65.254:9339 -u admin -p admin --skip-verify set \
  --update-path 'srl_nokia-interfaces:interface[name=ethernet-1/1]/subinterface[index=100]' \
  --update-value '{"index":100,"ipv4":{"admin-state":"enable"}}' \
  -e json_ietf

kubectl patch interface eth1-1 --subresource=status --type=merge -p '{
  "status": {
    "conditions": [{"type":"Configured","status":"True","reason":"Configured","message":"Configured",
                    "observedGeneration":1,"lastTransitionTime":"2024-01-01T00:00:00Z"}]
  }
}'

1. Apply the DHCPRelay CR and verify the device receives the configuration:

kubectl apply -f - <<'EOF'
apiVersion: networking.metal.ironcore.dev/v1alpha1
kind: DHCPRelay
metadata:
  name: dhcprelay-test
spec:
  deviceRef:
    name: leaf1
  interfaceRef:
    name: eth1-1
  servers:
    - 192.0.2.1
EOF

Device state after the controller reconciles (gnmic get on the dhcp-relay path):

{
  "admin-state": "enable",
  "server": ["192.0.2.1"]
}

2. Idempotency - controller log after a second reconcile with no spec change:

2026-10-15T11:59:50Z  Configuration is already up-to-date
  controller=dhcprelay  DHCPRelay=default/dhcprelay-test
  path=srl_nokia-interfaces:interface[name=ethernet-1/1]/subinterface[index=100]/ipv4/srl_nokia-interfaces-ip-dhcp-relay:dhcp-relay

No gNMI Set was issued.

3. Cross-VRF relay via vrfRef:

SR Linux has no VRF provider, so the VRF controller continuously overwrites the CR status to NotImplemented - making it impossible to hold the VRF in a Ready state long enough for the DHCPRelay controller to complete a reconcile. The device-level behavior was verified directly with gnmic instead:

kubectl apply -f - <<'EOF'
apiVersion: networking.metal.ironcore.dev/v1alpha1
kind: VRF
metadata:
  name: vrf-shared
spec:
  deviceRef:
    name: leaf1
  name: shared-services
EOF

The device correctly accepts network-instance when it is included in the payload - confirmed by a direct gNMI Set and subsequent Get:

{
  "admin-state": "enable",
  "network-instance": "shared-services",
  "server": ["192.0.2.1"]
}

The provider code path for vrfRef is covered by unit tests.

4. Delete the CR and confirm the relay is removed from the device:

kubectl delete dhcprelay dhcprelay-test

gnmic get on the same path returns an empty response - no dhcp-relay node present.

[felix-kaestner]

How did you test your implementation given that the Nokia SRLinux provider currently supports neither the Interface or the VRF/NetworkInstance configuration? Both are a prerequisite for even being able to configure a dhcprelay.

[felix-kaestner]

We need to make sure that as this is a subtree of the YANG tree of the interface itself, that when we implement the interface provider for native Nokia SRLinux later, that we don't use a gnmiext.Update to replace the configuration of an interface, as that would then also overwrite whatever we set here in a nested path. Therefore the interface provider implementation must use Patch() calls only to update the interface tree.

[ObuMan]

How did you test your implementation given that the Nokia SRLinux provider currently supports neither the Interface or the VRF/NetworkInstance configuration? Both are a prerequisite for even being able to configure a dhcprelay.

Both are already covered in the PR description under the Testing section:

1. The subinterface was pre-configured via gnmic set and the Interface CR status was patched manually.
2. The VRF path could not be tested end-to-end through the operator since the VRF controller immediately sets the status to NotImplemented the device-level behavior was verified directly with gnmic instead

Testing relies on workarounds, and VRF in particular cannot be tested end-to-end without a working provider. In hindsight, this should have been implemented after the Interface and VRF providers. I'd suggest freezing this PR until the Interface and VRF providers are implemented, so it can be tested end-to-end without manual scaffolding