From e0d9eadc632f46b18122807e9ebdc11fcf59897d Mon Sep 17 00:00:00 2001 From: Emanuele Di Pascale Date: Wed, 24 Jun 2026 11:08:00 +0200 Subject: [PATCH] document l3vni blackhole issue Signed-off-by: Emanuele Di Pascale --- docs/known-limitations/known-limitations.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/known-limitations/known-limitations.md b/docs/known-limitations/known-limitations.md index bdcaf828..da3df5b9 100644 --- a/docs/known-limitations/known-limitations.md +++ b/docs/known-limitations/known-limitations.md @@ -6,6 +6,7 @@ working hard to address: * [Deleting a VPC and creating a new one right away can cause the agent to fail](#deleting-a-vpc-and-creating-a-new-one-right-away-can-cause-the-agent-to-fail) * [Configuration not allowed when port is member of PortChannel](#configuration-not-allowed-when-port-is-member-of-portchannel) * [Breakout and CMIS transceiver initialization issues on DS5000](#breakout-and-cmis-transceiver-initialization-issues-on-ds5000) +* [Traffic gets black-holed for up to 5 minutes if a host changes IP within its L3VNI VPC subnet](#traffic-gets-black-holed-for-up-to-5-minutes-if-a-host-changes-ip-within-its-l3vni-vpc-subnet) ### Deleting a VPC and creating a new one right away can cause the agent to fail @@ -78,3 +79,20 @@ This occurs because SONiC did not always correctly reinitialize hardware abstrac - Prefer inserting transceivers before breaking out ports to avoid the issue altogether, if possible. - Always follow any REBOOTREQ status after upgrades or configuration changes. - If problems persist, perform a full power cycle as a last resort. + +### Traffic gets black-holed for up to 5 minutes if a host changes IP within its L3VNI VPC subnet + +When a host changes its IP address inside an L3VNI VPC subnet, leaves not directly attached to the host will +black-hole all traffic to the new IP address for up to 5 minutes, i.e., until the old neighbor is aged +out. This is due to a defect in SONiC that will be fixed in a future release. + +#### Diagnosing this issue + +Pings to the new IP address of the host from a remote peer will fail with `Destination Host Unreachable`. + +In the remote leaf, a log like the following one can be observed, where `10.10.99.70` is the hypothetical new IP of the host: +>NOTICE swss#orchagent: :- handleConflictingNeighbor: Route: Add IP:10.10.99.70 vrf_id:0x844424930134944, has no matching interface + +#### Known workarounds + +The black-hole will age out on its own after a few minutes. As a defensive measure, users can configure [static DHCP leases](../user-guide/dhcp.md#static-leases) to ensure that hosts will always receive the same IP address and prevent the issue from happening.