Description
MTUs for vteps are 1500 by default and do not work in sonic-vs due to us pushing jumbo frames over them, while they do work on edgecore switches. We currently fix that by running a script in the sonic vm, which changes the mtu at runtime.
I found out that the problem is that the sonic-vs images don't use the SONiC SAI at all and do not emulate any switch logic. sonic-swss uses a hardcoded MTU of 9100 when configuring ASICs, which leads to us not observing this issue in hardware.
And it turns out that sonic has a platform target called sonic-vpp based on Vector Packet Processor, which emulates a virtual switch silicon.
It would be awesome to get a broadcomm trident 3 emulation SAI implementation to get the most reproduction accuracy. But moving over to sonic-vpp should already greatly improve our ability to transfer low-level networking assumptions between mini-lab and physical deployments.
Description
MTUs for vteps are 1500 by default and do not work in sonic-vs due to us pushing jumbo frames over them, while they do work on edgecore switches. We currently fix that by running a script in the sonic vm, which changes the mtu at runtime.
I found out that the problem is that the sonic-vs images don't use the SONiC SAI at all and do not emulate any switch logic. sonic-swss uses a hardcoded MTU of 9100 when configuring ASICs, which leads to us not observing this issue in hardware.
And it turns out that sonic has a platform target called sonic-vpp based on Vector Packet Processor, which emulates a virtual switch silicon.
It would be awesome to get a broadcomm trident 3 emulation SAI implementation to get the most reproduction accuracy. But moving over to sonic-vpp should already greatly improve our ability to transfer low-level networking assumptions between mini-lab and physical deployments.