vpp: portchannel punt via member interface#2440
Open
yue-fred-gao wants to merge 1 commit into
Open
Conversation
Signed-off-by: Yue Gao <yuega2@cisco.com>
Collaborator
|
/azp run |
|
No pipelines are associated with this pull request. |
lunyue-ms
reviewed
Jul 6, 2026
| |---------------|-------------|--------------------------|--------------------| | ||
| | **ARP** (main interface) | member phy | member netdev → kernel bond → `PortChannel10` | `linux-cp-punt-xc` → `be10` tap → **`sonic-ext-aggr-tap-redirect` → member tap** | | ||
| | **IPv4 unicast for-us** (main interface) | member phy | member netdev → kernel bond → `PortChannel10` | same as ARP | | ||
| | **ARP** (sub-interface) | member phy (tagged) | member netdev → bond → 8021q → `PortChannel10.1` | `linux-cp-punt-xc` → `be10.1` tap → **`sonic-ext-aggr-tap-redirect` → member tap (re-push .1Q)** | |
There was a problem hiding this comment.
Hi @yue-fred-gao, please correct me if my understanding is not correct: the packet delivered to be10.1 tap should have a vlan tag(vid1). In member tap (re-push .1Q), the packet will be re-push with a vlan tag. Can the re-pushed vid can be different from the vid in be10.1` tap in some cases?
Section6.3 notes mentioned "No tag strip/re-push is required". It seems that (re-push .1Q) needs to be changed?
lunyue-ms
approved these changes
Jul 6, 2026
lunyue-ms
left a comment
lunyue-ms
left a comment
There was a problem hiding this comment.
Thanks, Fred, this HLD is very clear and constructed. From the log, it seems that you have already implemented the main part.
AkeelAli
approved these changes
Jul 10, 2026
|
|
||
| ## 3. Design Principles (Punt Strategy Summary) | ||
|
|
||
| The design utilizes the punt-via-member infra in sonic-exe plugin introduced for VLAN/BVI. It uses |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
why
The current port-channel implementation punts control-plane packets directly to the
PortChannel<id>(bond) netdev.This does not conform to the SONiC data-plane model. On real hardware the NPU punts control traffic to the CPU on the physical/member port it was received on.
The most visible symptom is DHCP relay.
sonic-dhcp-relay/dhcrelay(the SONiC relay agent) binds and accepts uplink packets only on port-channel member interfaces. Because today's solution delivers the frame on the
PortChannel<id>netdev instead of the member, the relay agent never sees theuplink packet and DHCP relay over a port-channel uplink is broken.
what this PR does
Redesign the punt path for packets to port channel and port channel sub interface using sonic-ext plugin that was created for VLAN/BVI.