[EVPN Multihoming] orchagent fails to create L2 Next Hop Group of type Bridge port — SAI returns "Unsupported nexthop group type 7" (SAI_STATUS_INVALID_ATTR_VALUE_0)

[edufourWithings]

[EVPN Multihoming] orchagent fails to create L2 Next Hop Group of type Bridge port — SAI returns "Unsupported nexthop group type 7" (SAI_STATUS_INVALID_ATTR_VALUE_0)

What I am trying to achieve

I am trying to set up EVPN VXLAN Multihoming (all-active Ethernet Segment) between two SONiC switches. A baseline single-homed EVPN VXLAN L2 extension (BGP EVPN iBGP + VXLAN, VLAN ↔ VNI) already works correctly between the two switches: the VXLAN tunnel is up, Type-2 and Type-3 routes are exchanged, and unicast (SVI-to-SVI) works.

The problem appears as soon as I turn the PortChannel facing the server into an Ethernet Segment (multihoming).

Configuration used

CLI configuration used on both switchs:

config interface sys-mac add PortChannel9 00:00:00:0a:00:01
config interface evpn-esi add PortChannel0 00:00:00:00:00:00:00:0a:00:01

Check in config_db:

sonic-db-cli CONFIG_DB HGETALL "EVPN_ETHERNET_SEGMENT|PortChannel0"
{'df_pref': '32767', 'esi': '00:00:00:00:00:00:00:0a:00:01', 'type': 'TYPE_0_OPERATOR_CONFIGURED'}

On the PortChannel connecting to the multihomed device, on both switches, via FRR we have:

interface PortChannel0
 evpn mh es-id 00:00:00:00:00:00:00:0a:00:01
exit

Steps to reproduce

1. Two SONiC switches with a working single-homed BGP EVPN + VXLAN L2 extension (iBGP, advertise-all-vni, advertise-svi-ip, VLAN 100 ↔ VNI 10000).
2. Apply the Ethernet Segment configuration above on the PortChannel on both switches.
3. When the peer's Type-2 (MAC/IP) routes carrying a non-zero ESI are processed, orchagent tries to create an L2 Next Hop Group of type Bridge port and the creation fails in syncd/SAI.

Expected behavior

Remote MACs learned on the multihomed Ethernet Segment are programmed against an L2 ECMP next-hop group (SAI_NEXT_HOP_GROUP_TYPE_BRIDGE_PORT), enabling all-active aliasing, and L2 connectivity (ARP resolution + ping) to hosts behind the peer works — as described in the EVPN-MH HLD (doc/vxlan/EVPN/EVPN_VxLAN_Multihoming.md).

Actual behavior

orchagent fails to create the L2 Next Hop Group; syncd/SAI returns SAI_STATUS_INVALID_ATTR_VALUE_0. The multihomed remote MAC/neighbor entries are therefore not programmed into the ASIC, ARP does not resolve, and L2 traffic toward hosts behind the peer is black-holed.

Logs

2026 Jul 22 14:45:16.667850 sonic ERR syncd#syncd: [none] SAI_API_NEXT_HOP_GROUP:brcm_sai_create_next_hop_group_cmn:172 Unsupported nexthop group type 7 passed
2026 Jul 22 14:45:16.667864 sonic ERR syncd#syncd: :- sendApiResponse: api SAI_COMMON_API_CREATE failed in syncd mode: SAI_STATUS_INVALID_ATTR_VALUE_0
2026 Jul 22 14:45:16.668024 sonic ERR syncd#syncd: :- processQuadEvent: attr: SAI_NEXT_HOP_GROUP_ATTR_TYPE: SAI_NEXT_HOP_GROUP_TYPE_BRIDGE_PORT
2026 Jul 22 14:45:16.668366 sonic ERR swss#orchagent: :- create: create status: SAI_STATUS_INVALID_ATTR_VALUE_0
2026 Jul 22 14:45:16.668738 sonic ERR swss#orchagent: :- createSaiNextHopGroup: Failed to create an L2 Next Hop Group of type Bridge port: rc: -131072
2026 Jul 22 14:45:16.668999 sonic ERR swss#orchagent: :- handleSaiFailure: Encountered failure in create operation, SAI API: SAI_API_NEXT_HOP_GROUP, status: SAI_STATUS_INVALID_ATTR_VALUE_0

Environment

Item	Value
SONiC version (show version)	SONiC.master.1169746-d5b2072d3
Distribution	Community SONiC
Platform	Dell S5248F-ON
ASIC	Broadcom Trident3-X7
SAI (docker exec syncd dpkg -l | grep saibcm)	libsaibcm 15.2.0.0.0.0.11.1 (branch SAI_15.2.0_GA)
FRR version	FRRouting 10.5.4 on Linux(6.12.41+deb13-sonic-amd64)
Kernel	6.12.41+deb13-sonic-amd64

Questions

1. Is EVPN Multihoming — and specifically the SAI_NEXT_HOP_GROUP_TYPE_BRIDGE_PORT L2 ECMP next-hop group — expected to be supported on this platform (Trident3-X7) with the current XGS SAI build in Community SONiC?
2. If this is a known limitation, is there a tracking issue or a roadmap item? The EVPN-MH HLD documents the L2 NHG mechanism and lists dependencies (SAI object support, newer Linux kernel for split-horizon / non-DF BUM filtering, new orchagent submodules). It would help to know whether the gap here is on the SAI side, the kernel side, or the orchagent side.
3. Should this be raised against opencomputeproject/SAI (or with the ASIC vendor) instead of sonic-net/swss? Happy to move it if this is the wrong tracker.

Additional context

• The control plane looks healthy: show evpn es reports the segment as Type: LR (local + remote), the VXLAN tunnel is up, and show evpn vni detail shows the remote VTEP with flood: HER and non-zero MAC/ARP counts. Only the hardware programming of the L2 NHG fails, with the errors above.
• Removing the Ethernet Segment (no evpn mh es-id ... / no evpn mh es-df-pref ...) on both switches makes the errors disappear and restores L2 connectivity (single-homed EVPN VXLAN works fine).