SONiC-VPP t0 Fix missed svi neighbors.

[dypet]

Description of PR

Summary:
Fixes # (issue)
This PR fixes IP neighbors on VLAN SVIs (Vlan<id> interfaces) never being
programmed into the VPP data plane, which caused routed uplink→downlink
traffic destined to hosts on a VLAN to be silently dropped.

In the VPP virtual-switch (vslib/vpp), the neighbor-programming path
SwitchVpp::addRemoveIpNbr() only handled router interfaces (RIFs) of type
PORT and SUB_PORT. It unconditionally queried
SAI_ROUTER_INTERFACE_ATTR_PORT_ID up front, but a VLAN SVI RIF
(SAI_ROUTER_INTERFACE_TYPE_VLAN) has no PORT_ID attribute (it points at a
VLAN, not a single port). As a result the lookup failed and the neighbor was
dropped before the RIF type was ever examined — and VLAN was not an accepted
type anyway. The corresponding bridge-virtual interface (bvi<vlanid>) in VPP
therefore had no rewrite adjacency for those hosts, so L3 traffic routed toward
VLAN hosts had nowhere to go.

This PR teaches the neighbor path to recognize VLAN SVI RIFs and program the
neighbor against the bridge-virtual interface (BVI), and hardens the FDB/BVI
bring-up path with return-code checking, rollback, tracking, and diagnostic
logging so the underlying bridge-domain plumbing the fix depends on cannot fail
silently.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation update
• Test improvement

Approach

What is the motivation for this PR?

Hosts attached to a VLAN reach the rest of the network through the VLAN's SVI
(Vlan<id>), whose L3 endpoint in VPP is the bridge-virtual interface
bvi<vlanid>. The kernel resolves those host neighbors on the Vlan<id>
netdev, and neighsyncd/orchagent push them down via SAI. Because these VLAN
neighbors were being dropped before reaching VPP, the BVI never got an
adjacency for them and routed traffic to VLAN hosts was blackholed. This makes
L3-to-VLAN forwarding (e.g. routed uplink→downlink to a host on a VLAN)
work on the VPP platform.

Work item tracking

• Microsoft ADO (number only):

How did you do it?

vslib/vpp/SwitchVppNbr.cpp (addRemoveIpNbr):

• Query the RIF type first, before any PORT_ID lookup.
• Accept SAI_ROUTER_INTERFACE_TYPE_VLAN in addition to PORT and SUB_PORT.
• Only perform the PORT_ID (and, for sub-ports, OUTER_VLAN_ID) lookup for
  the PORT/SUB_PORT cases.
• For a VLAN RIF, resolve the VLAN id (RIF VLAN_ID attr → the VLAN object's
  VLAN_ID attr) and target the neighbor at bvi<vlanid>. This builds a
  complete rewrite adjacency on the BVI (dst = host MAC, tx = bvi<vlanid>).
  BVI→bridge-domain delivery to the specific member port then happens through
  the existing L2 FIB (unicast if the host MAC is learned, flood otherwise), so
  no explicit l2fib entry is required.

vslib/vpp/SwitchVppFdb.cpp (vpp_create_vlan_member, vpp_create_bvi_interface,
vpp_delete_bvi_interface) — hardening of the SVI/bridge-domain infrastructure
the fix relies on:

• Check return codes on previously fire-and-forget VPP calls
  (create_sub_interface, set_sw_interface_l2_bridge,
  set_l2_interface_vlan_tag_rewrite, interface_set_state,
  create_bvi_interface, configure_lcp_interface) and log descriptive errors.
• Roll back on hard failures (e.g. delete_sub_interface,
  delete_bvi_interface) and return SAI_STATUS_FAILURE; continue best-effort
  on softer failures.
• Track the BVI in the swif → bridge-domain map on create
  (swif_bdid_track) and untrack it on delete (swif_bdid_untrack), matching
  member tracking, so FDB-notification / port-invalidation logic sees a
  complete view of the bridge domain.
• Add NOTICE-level diagnostics dumping the bridge-domain member count after each
  member add and after BVI setup, so a VLAN_MEMBER that silently fails to land
  in the BD is visible in the logs rather than only surfacing as a failed
  data-plane test.

How did you verify/test it?

Ran T0 sonic-mgmt testsuite with SONiC-VPP and this fix, verified by the ACL test case improvement:
test_acl.py — the ACL tests drive traffic
uplink<->downlink through the Vlan1000 SVI, so uplink->downlink cases
depend on routed traffic reaching a host on the VLAN via the BVI adjacency this
fix programs:

• test_acl: 284 passed / 100 failures / 8 errors → 384 passed / 0 failures / 0 errors

And no regressions seen in other testcases between the two runs.

Any platform specific information?

SONiC-VPP virtual-switch platform only. Changes are confined to vslib/vpp
(SwitchVppNbr.cpp, SwitchVppFdb.cpp) and do not affect other ASIC
platforms.

Documentation

No documentation/Wiki update required.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.