Is it platform specific
generic (VPP platform / docker-syncd-vpp, libsaivs)
Importance or Severity
High
Description of the bug
On the VPP platform, updating a SAI_ROUTER_INTERFACE of type VLAN (i.e. the Vlan<x> SVI, realized in VPP as a BVI) always fails with SAI_STATUS_FAILURE.
SwitchVpp::vpp_update_router_interface() (vslib vslib/vpp/SwitchVppRif.cpp) reads SAI_ROUTER_INTERFACE_ATTR_PORT_ID before it branches on the RIF type:
attr.id = SAI_ROUTER_INTERFACE_ATTR_PORT_ID;
status = get(SAI_OBJECT_TYPE_ROUTER_INTERFACE, object_id, 1, &attr);
if (status != SAI_STATUS_SUCCESS) {
SWSS_LOG_ERROR("attr SAI_ROUTER_INTERFACE_ATTR_PORT_ID was not passed");
return SAI_STATUS_FAILURE; // <-- VLAN RIF has no PORT_ID => always here
}
A VLAN router interface has no SAI_ROUTER_INTERFACE_ATTR_PORT_ID (it has SAI_ROUTER_INTERFACE_ATTR_VLAN_ID instead), so the get() fails and the whole set() returns SAI_STATUS_FAILURE. The create and remove paths already branch on TYPE == VLAN first; only the update path does not.
The failure is reliably triggered on dual-ToR, where IntfsOrch issues a SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS update on the Vlan1000 RIF (shared gateway MAC reconcile). orchagent turns the sticky SAI failure into a hard error, re-logs it continuously, and asks syncd to dump:
ERR swss#orchagent: :- doTask: Failed to set router interface mac 22:ad:a2:34:08:76 for port Vlan1000, rv:-1
NOTICE swss#orchagent: :- notifySyncd: sending syncd: SYNCD_INVOKE_DUMP
orchagent then stays unhealthy (the RIF SET remains in m_toSync and retries forever), which stalls further programming on that Executor.
Steps to Reproduce
- Deploy a dual-ToR VPP KVM testbed (
vms-kvm-vpp-dual-tor / t0-dualtor), platform vpp, docker-syncd-vpp.
- Bring up the
Vlan1000 SVI with a router interface (VLAN-type RIF) — normal dual-ToR minigraph does this.
- Let
IntfsOrch issue a SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS (or MTU) update on the VLAN RIF (happens automatically during mux/gateway-MAC reconcile; can also be forced with config interface ... that re-derives the SVI MAC).
- Observe orchagent logging
Failed to set router interface mac ... for port Vlan1000, rv:-1 and issuing SYNCD_INVOKE_DUMP.
Actual Behavior and Expected Behavior
Actual: Any attribute update to a VLAN (SVI/BVI) router interface returns SAI_STATUS_FAILURE because vpp_update_router_interface() requires PORT_ID. On dual-ToR this wedges orchagent with a sticky, endlessly-retried SAI failure and repeated SYNCD_INVOKE_DUMP.
Expected: Updating a VLAN router interface should succeed. The update should be dispatched by RIF type (as create/remove already are) and applied to the BVI (bvi<vlan_id>), mirroring vpp_create_bvi_interface(). Supported attributes (SRC_MAC, MTU) should be applied to the BVI and persisted to the SAI object store; unsupported attributes should not fail the call.
Relevant log output
# orchagent (host syslog) — repeats until the RIF SET is satisfied
ERR swss#orchagent: :- doTask: Failed to set router interface mac 22:ad:a2:34:08:76 for port Vlan1000, rv:-1
NOTICE swss#orchagent: :- notifySyncd: sending syncd: SYNCD_INVOKE_DUMP
# /var/log/swss/sairedis.rec — VLAN RIF is created with TYPE_VLAN + VLAN_ID (no PORT_ID) ...
c|SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x60000000005d7|SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID=oid:0x3000000000002|SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS=00:AA:BB:CC:DD:EE|SAI_ROUTER_INTERFACE_ATTR_TYPE=SAI_ROUTER_INTERFACE_TYPE_VLAN|SAI_ROUTER_INTERFACE_ATTR_VLAN_ID=oid:0x260000000005bc|SAI_ROUTER_INTERFACE_ATTR_MTU=9100|SAI_ROUTER_INTERFACE_ATTR_NAT_ZONE_ID=0
# ... then a later SRC_MAC 'set' on that same VLAN RIF is what fails in vpp_update_router_interface():
s|SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x60000000005d7|SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS=22:AD:A2:34:08:76
Output of show version, show techsupport
SONiC Software Version: SONiC.master.1182394-fc9ea17bb
Distribution: Debian 13.5
Kernel: 6.12.41+deb13-sonic-amd64
Build commit: fc9ea17bb
Platform: x86_64-kvm_x86_64-r0
HwSKU: Force10-S6000
ASIC: vpp
ASIC Count: 1
Fix
Dispatch the update by RIF type before the PORT_ID lookup and handle the VLAN case on the BVI:
Related (dual-ToR trigger / root cause of the spurious SRC_MAC reconcile):
Is it platform specific
generic (VPP platform /
docker-syncd-vpp,libsaivs)Importance or Severity
High
Description of the bug
On the VPP platform, updating a
SAI_ROUTER_INTERFACEof type VLAN (i.e. theVlan<x>SVI, realized in VPP as a BVI) always fails withSAI_STATUS_FAILURE.SwitchVpp::vpp_update_router_interface()(vslibvslib/vpp/SwitchVppRif.cpp) readsSAI_ROUTER_INTERFACE_ATTR_PORT_IDbefore it branches on the RIF type:A VLAN router interface has no
SAI_ROUTER_INTERFACE_ATTR_PORT_ID(it hasSAI_ROUTER_INTERFACE_ATTR_VLAN_IDinstead), so theget()fails and the wholeset()returnsSAI_STATUS_FAILURE. The create and remove paths already branch onTYPE == VLANfirst; only the update path does not.The failure is reliably triggered on dual-ToR, where
IntfsOrchissues aSAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESSupdate on theVlan1000RIF (shared gateway MAC reconcile). orchagent turns the sticky SAI failure into a hard error, re-logs it continuously, and asks syncd to dump:orchagent then stays unhealthy (the RIF SET remains in
m_toSyncand retries forever), which stalls further programming on that Executor.Steps to Reproduce
vms-kvm-vpp-dual-tor/ t0-dualtor), platformvpp,docker-syncd-vpp.Vlan1000SVI with a router interface (VLAN-type RIF) — normal dual-ToR minigraph does this.IntfsOrchissue aSAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS(or MTU) update on the VLAN RIF (happens automatically during mux/gateway-MAC reconcile; can also be forced withconfig interface ...that re-derives the SVI MAC).Failed to set router interface mac ... for port Vlan1000, rv:-1and issuingSYNCD_INVOKE_DUMP.Actual Behavior and Expected Behavior
Actual: Any attribute update to a VLAN (SVI/BVI) router interface returns
SAI_STATUS_FAILUREbecausevpp_update_router_interface()requiresPORT_ID. On dual-ToR this wedges orchagent with a sticky, endlessly-retried SAI failure and repeatedSYNCD_INVOKE_DUMP.Expected: Updating a VLAN router interface should succeed. The update should be dispatched by RIF type (as create/remove already are) and applied to the BVI (
bvi<vlan_id>), mirroringvpp_create_bvi_interface(). Supported attributes (SRC_MAC, MTU) should be applied to the BVI and persisted to the SAI object store; unsupported attributes should not fail the call.Relevant log output
Output of
show version,show techsupportFix
Dispatch the update by RIF type before the
PORT_IDlookup and handle the VLAN case on the BVI:Related (dual-ToR trigger / root cause of the spurious SRC_MAC reconcile):