fix(srv6): steer pod-to-node service traffic through End.DT6 SID

[ryskn]

Summary

In an IPv6 single-stack + SRv6 setup, once SRv6 is actually active (the localsid/policy pools are marked allowedUses: [Tunnel] so Pods are allocated from the default pool), host-network-backed ClusterIP Services break.

A concrete example is a Pod on one node accessing the kubernetes Service:

fd30::1 -> apiserver node IP fd00:1::10

The packet is dropped on the backend node. Pod-backed ClusterIP Services are unaffected.

Root cause

For a host-network-backed Service, cnat DNATs the Service VIP to a node IP. That node IP is directly connected in the uplink subnet, so the packet bypasses SRv6 and is forwarded over the uplink as plain IPv6.

At the same time, cnat excludes node-IP destinations from SNAT, so the Pod source address is preserved.

On the receiving node, that Pod prefix is only reachable through the SRv6 overlay. As a result, a Pod-sourced packet arriving unencapsulated from the uplink fails the source/reverse-path lookup and is dropped (ip6 source lookup miss).

Pod-backed Services do not hit this path because the backend is a Pod address; its FIB resolution is an SRv6 tunnel, so traffic stays symmetric.

Fix

Steer Pod-originated traffic destined to a remote node's own IPv6 address (/128) through that node's already-advertised End.DT6 SID. This adds steerNodeIPViaSID in AddConnectivity.

• The steering entry is installed in PodVRFIndex, so node-to-node control traffic in the main table is unaffected.
• It reuses the remote node's existing End.DT6 local SID (created by setEndDT with FibTable 0); no new dataplane primitive is required.
• The Pod source identity is preserved; no SNAT is needed.

The resulting path is:

pod source preserved
  -> SRv6 encap toward the remote node's End.DT6 SID
  -> remote node decapsulates
  -> lookup in table 0
  -> delivered to the host-network backend

The DT6 policy is already installed in VPP by the CreateSRv6Tunnel pass over the node's Pod prefixes, so this change only adds the steering entry and does not re-add the policy. This avoids churn of a live policy shared with the Pod-prefix steering, since AddModSRv6Policy is delete-then-add.

Notes

• IPv4 node IPs / DT4 are out of scope for this PR. Dual-stack support would need the corresponding End.DT4 and SrSteerIPv4 handling.
• Explicit teardown of this node-IP steering is not implemented here because DelConnectivity is currently a no-op, matching the existing limitation for Pod-prefix steering. Once fix(srv6): implement DelConnectivity with NLRI-key teardown and candidate-path failover projectcalico/vpp-dataplane#1025 lands, this steering should be removed from the same teardown path.

[Copilot]

Pull request overview

IPv6 single-stack + SRv6 環境で SRv6 が有効になった際に、host-network backed な ClusterIP Service への Pod 発トラフィックが SRv6 を迂回して非対称経路になり drop される問題を、PodVRF 上でリモートノード IP(/128)宛を End.DT6 SID に steer することで解消する変更です。

Changes:

• リモートノード自身の IPv6 Node IP(/128) 宛トラフィックを、当該ノードの End.DT6 policy(BSID) に steering するヘルパーを追加
• AddConnectivity の SRv6 構築完了タイミングで上記 steering を追加し、host-network backed ClusterIP の往復対称性を確保

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.