Hi Fred, For tunnel interfaces, when VPP punts the rx sw_if_index will have been set to the tunnel, the encap will have been removed, and the packet will have been decrypted; is that also going to be an issue for you? Will you need to track and recover the encap, or even re-encrypt?
I’d rather look at your punt requirements as a whole, rather than case by case. That way we can hopefully come to a single solution to cover all cases. /neale From: [email protected] <[email protected]> on behalf of Yue Gao (yuega2) via lists.fd.io <[email protected]> Date: Saturday, 6 June 2026 at 8:09 am To: [email protected] <[email protected]> Cc: murali Venkateshaiah (muraliv) <[email protected]> Subject: Re: [vpp-dev] Add a field to keep original rx interface You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Neale, We can look at this case by case. For bond and bvi, SONiC wants the packet to be punted via member interface. It doesn’t create virtual interface for vxlan tunnel, srv6 tunnel, or ipinip tunnel etc. they can only be punted via the netdev of the incoming physical interface. Here is one example: https://github.com/sonic-net/sonic-linkmgrd/blob/65f563308c689e3225fdf3fc249a132350e9879b/src/link_prober/LinkProberBase.cpp#L71 It binds to a raw socket to a member interface to listen for icmp probes. It won’t receive it if the packet is punted to BVI. In the vpp, we can also handle this case by case. For example, in l2_to_bvi, we save the original rx sw_if_index, if it is not saved yet, when it is overwritten by bvi sw_if_index. Thanks, Fred From: [email protected] <[email protected]> on behalf of Neale Ranns via lists.fd.io <[email protected]> Date: Thursday, June 4, 2026 at 7:03 PM To: [email protected] <[email protected]> Cc: murali Venkateshaiah (muraliv) <[email protected]> Subject: Re: [vpp-dev] Add a field to keep original rx interface Hi Fred, Is the expectation that packets are punted on the original input interface common across all virtual interface types? Consider an IPSec tunnel. If, post decryption, the inner packet is for-us, is the expectation that the encapsulated (and encrypted) packet is punted as if it arrived on the physical? /neale From: [email protected] <[email protected]> on behalf of Yue Gao (yuega2) via lists.fd.io <[email protected]> Date: Thursday, 4 June 2026 at 12:02 am To: [email protected] <[email protected]> Cc: murali Venkateshaiah (muraliv) <[email protected]> Subject: Re: [vpp-dev] Add a field to keep original rx interface You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Ben, Sorry I wasn’t clear with interface stats. It is not the rx/tx counter but drop counter. Drop counter is accumulated along the forwarding path. If a packet is dropped after bond-input or l2-fwd after RX intf is replaced with bond or bvi sw_if_index, the drop will be counted under the new interface. But SONiC expects the drop to be counted under the member interface. In SONiC, it uses linux networking stack. For example, we create a VLAN 10 with member interfaces Ethernet0 and Ethernet1. In linux kernel, Vlan10 bridge is created and Ethernet0 and Ethernet1 are added to the bridge. In sonic-vpp, Ethernet0 and Ethernet1 are tap interfaces created by LCP plugin. LCP also creates a tap interface for Vlan10 as a pair of bvi interface. For the IP unicast, an example is a packet with DST-MAC of the BVI mac, DST-IP of a loopback address. Packet is received by bobm0 (physical interface of Ethernet0) of the bridge. The packet will go through ethernet-input -> l2-input -> l2-input-vtr -> l2-learn -> l2-fwd -> l2-ouput -> ip4-input -> ip4-lookup -> ip4-local -> linux-cp-punt-xc. Current behavior of linux-cp-punt-xc is to punt the packet to the LCP pair interface of the current RX interface, which is BVI. But SONiC expects the packet to be punted to the Ethernet0, which is LCP pair of the original rx interface. Please let me know if you need further clarification. Thanks, Fred From: [email protected] <[email protected]> on behalf of Benoit Ganne (bganne) via lists.fd.io <[email protected]> Date: Wednesday, June 3, 2026 at 3:56 AM To: [email protected] <[email protected]> Cc: murali Venkateshaiah (muraliv) <[email protected]> Subject: Re: [vpp-dev] Add a field to keep original rx interface Hi Fred, RX/TX statistics should already be available per interface under /interfaces/<ifname>/{rx,tx,drops} etc. Isn't that sufficient for that stat case? Regarding punting, can you describe the packet path a bit more? You have a packet destined to the address of the BVI, but you want to punt it somewhere through a specific interface? Best ben ________________________________________ From: [email protected] <[email protected]> on behalf of Yue Gao (yuega2) via lists.fd.io <[email protected]> Sent: Tuesday, June 2, 2026 23:12 To: [email protected] Cc: murali Venkateshaiah (muraliv) Subject: [vpp-dev] Add a field to keep original rx interface Hello, When working with sonic integration, we found there are a few cases we need to remember the rx interface. 1. SONIC expects rx packets to be counted under member interface, not bond interface. 2. In VLAN bridge with bvi, ip unicast packets to the host with bvi as nexthop should be punted to the member interface of the bridge, not bvi. For these cases, we need to remember the original rx sw_if_index (u32) in vnet_buffer_opaque2_t, for example. Do you think if this change is reasonable? Thanks, Fred
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27057): https://lists.fd.io/g/vpp-dev/message/27057 Mute This Topic: https://lists.fd.io/mt/119619157/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
