Skip to content

[draft] [v3.29] fix for issues on ipv6 enabled clusters#834

Closed
sknat wants to merge 12 commits intorelease/v3.29.0from
abasu-dhcp6-fix-v329
Closed

[draft] [v3.29] fix for issues on ipv6 enabled clusters#834
sknat wants to merge 12 commits intorelease/v3.29.0from
abasu-dhcp6-fix-v329

Conversation

@sknat
Copy link
Collaborator

@sknat sknat commented Nov 14, 2025

[WIP] cherry-pick of fixes from master for issues on ipv6 enabled clusters

@sknat sknat marked this pull request as draft November 14, 2025 17:06
@aritrbas aritrbas changed the title [v3.29] add mFIB entries for host IPv6 multicast traffic [v3.29] fix for issues on ipv6 enabled clusters Nov 18, 2025
@aritrbas aritrbas marked this pull request as ready for review November 20, 2025 21:23
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch 3 times, most recently from d70ee5c to 326b60f Compare November 25, 2025 01:08
@aritrbas aritrbas marked this pull request as draft December 2, 2025 08:12
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch from 326b60f to cab1a3c Compare December 4, 2025 01:03
@aritrbas aritrbas changed the title [v3.29] fix for issues on ipv6 enabled clusters [draft] [v3.29] fix for issues on ipv6 enabled clusters Dec 4, 2025
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch 12 times, most recently from a72d00a to 86f489e Compare December 11, 2025 02:16
@aritrbas aritrbas marked this pull request as ready for review December 11, 2025 20:38
@aritrbas aritrbas marked this pull request as draft December 11, 2025 20:38
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch 2 times, most recently from 8d985ce to 838d59d Compare December 17, 2025 04:28
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch 2 times, most recently from ece4d90 to 90c11d4 Compare January 26, 2026 08:22
Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Aritra Basu and others added 10 commits January 30, 2026 17:21
Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Signed-off-by: Aritra Basu <aritrbas@cisco.com>
This patch removes the nodeIP from the tap0 interface in VPP.
With this patch, for each uplink interface eth0 with IP 192.168.0.1/24
we create a corresponding tap0 set up the following way:

* In VRF:0
  * we create the af_packet interface with IP 192.168.0.1/24
  * we receive 192.168.0.1/32 locally, traffic to 192.168.0.1 without listeners
    will end up in punt
* In the punt table
  * we route 192.168.0.1/24 via tap0 192.168.0.1
* In linux
  * tap0 has the 192.168.0.1/24 address
  * tap0 will respond to ARPs as VPP has arp proxy enabled
* In a host-tap-eth0-v4 VRF
  * we place the tap0 interface
  * we give it the 169.254.0.1/32 address, overridable with CALICOVPP_TAP0_ADDR
  * we enable IP6 without setting an address
  * we add a static neighbor for 192.168.0.1 to the MAC of the linux side of the tap
* If we specify a rule in redirectToHostRules (e.g. for DNS in kind)
  * we will have the classifier entry redirect to tap0 192.168.0.1

Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
IPv6 gateway traffic (DHCPv6/ICMP) fails when VPP takes over the uplink.
- Without gateway ND proxy, host NS for the default gateway is dropped by VPP
  with "neighbor solicitations for unknown targets" error due to missing /128
  target entry in the tap FIB.

Fix:
- Enable ND proxy for the gateway on the tap so the host can resolve the
  gateway via VPP.

Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
Configure ip6tables mangle rule to set hop limit to 2 for DHCPv6 OUTPUT
traffic from client (sport 546) to server (dport 547). This prevents VPP
from dropping DHCPv6 SOLICIT/REQUEST packets when it decrements hop-limit
by 1 during forwarding. Since clients generate SOLICIT/REQUEST with
hop-limit=1, without this rule VPP drops the packet (ip6 ttl <= 1)
with ICMP time exceeded, causing DHCPv6 lease negotiation to fail.

The rule is checked for existence before adding to prevent duplicates
since ip6tables does not auto-dedupe rules. The rule is also cleaned
up during configuration restoration.

Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Link-local addresses are not routable. When synchronizing Linux
routes to VPP's uplink interface, filter out link-local addresses
so that they are not added to VPP's main VRF routing table.

Signed-off-by: Aritra Basu <aritrbas@cisco.com>
Capture ID_NET_NAME_* properties before VPP driver unbind and restore them
via udev rules after VPP creates host-facing tap/tun interface. This is
needed for IAID generation by DHCPv6 client in systemd-networkd to be
consistent across VPP lifecycle on the node.

Key changes:
- Add new CAPTURE_HOST_UDEV_PROPS hook that runs before PreconfigureLinux()
- Store ID_NET_NAME_* values and MAC address while interface still has original driver
- Create udev rules for the interface to restore ID_NET_NAME_* values after VPP runs
- Cleanup udev rules on VPP shutdown
- CAPTURE_HOST_UDEV_PROPS → capture, VPP_DONE_OK/ERRORED → cleanup

Signed-off-by: Aritra Basu <aritrbas@cisco.com>
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch from 90c11d4 to d05da9d Compare January 31, 2026 19:56
IPv6 ping between nodes fails with "l3 mac mismatch" error in VPP's
ethernet-input node. Packets arriving on tap0 with destination MAC
set to the infrastructure gateway's MAC are dropped.

- IPv4 (ARP Proxy): Host sends ARP request, VPP responds with its own
  tap interface MAC. All subsequent IPv4 packets use VPP's MAC as the
  destination, passing VPP's L3 MAC filter check.

- IPv6 (ND Proxy + Neighbor Advertisement): While VPP's ND proxy responds
  to Neighbor Solicitations with the tap interface MAC, the host also
  receives Neighbor Advertisement (NA) packets from the real gateway.
  These RA packets contain the Target Link-Layer Address Option (TLLAO)
  with the real gateway's MAC address. The host overwrites its neighbor
  cache with this information and sends IPv6 packets to the real gateway
  MAC instead of VPP's tap MAC.

Capture the gateway's MAC address from Linux neighbor cache before VPP
takes over the interface, then add it as a secondary MAC address on the
tap interface using VPP's existing sw_interface_add_del_mac_address API.

VPP's ethernet-input node accepts packets with either the primary MAC
or any configured secondary MAC addresses, allowing traffic to flow
regardless of which MAC address the host learned (from ND proxy or NA).

This is a control plane only fix that requires no VPP patches.

Signed-off-by: Aritra Basu <aritrbas@cisco.com>
@aritrbas aritrbas force-pushed the abasu-dhcp6-fix-v329 branch from d05da9d to 325659e Compare February 3, 2026 03:19
@sknat
Copy link
Collaborator Author

sknat commented Feb 5, 2026

closing in favor of #864

@sknat sknat closed this Feb 5, 2026
@aritrbas aritrbas deleted the abasu-dhcp6-fix-v329 branch February 5, 2026 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants