Add vpp vlan-bvi HLD#2387
Conversation
Signed-off-by: Yue Gao <yuega2@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
lolyu
left a comment
lolyu
left a comment
There was a problem hiding this comment.
VLAN BVI HLD — Review (Comment)
Strong design overall. The v1.0->v1.1 re-architecture is a real improvement: moving per-buffer state into the vnet_buffer2(b)->unused overlay so it survives vlib_buffer_clone() is elegant and removes the v1.0 atomic-swap recycled-buffer race. The "no upstream VPP source modified" out-of-tree sonic_ext plugin approach is the right long-term call, and the per-protocol punt table (S3.1) is an excellent reference artifact.
Not blocking — posting as a Comment. The substantive items are clarifications I'd like resolved before this becomes the reference doc people implement against. Details inline; summary:
Major (clarify):
- S5.4 — relay vs. direct-L2-server model is never stated. A DHCP DISCOVER is both flooded to sibling members and punted to Linux. If a DHCP server lives on another member of the same VLAN, the client can be serviced via two paths (direct L2 flood + relay on the punted member tap). The HLD should state explicitly whether intra-VLAN DHCP is expected to work via pure L2 (in-VLAN server) or always via relay (L3-remote server), and whether double-servicing is possible.
- DHCP snooping interaction is unaddressed. With snooping on, the member port facing a DHCP server must be trusted or OFFER/ACK are dropped. Worth a paragraph.
- DHCPv6 is silent. ARP/DHCPv4 get full treatment, IPv6 ND is deferred to S7, but DHCPv6 isn't mentioned. It's link-scoped multicast (
ff02::1:2), so thedst==255.255.255.255gate inbcast-redirectwon't catch it — the design silently doesn't handle it today. State it as out-of-scope explicitly.
Minor:
4. Rev 1.2 is "TBD" — S5 walkthroughs flagged as still pending v1.1 reconciliation; clarify what's authoritative.
5. S6 show lcp example contradicts S3.6 (lcp-auto-subint disabled => no Ethernet0.10 netdev).
6. bcast-redirect punts any limited broadcast with no L4/port match — note rate-limit/policer expectations (CPU-DoS surface).
Full reasoning on each is attached to the relevant lines.
|
|
||
| Key observations: | ||
|
|
||
| - **Member flood copies are not punted** — they just go out the wire on |
There was a problem hiding this comment.
Major — DHCP snooping interaction is unaddressed. If DHCP snooping is enabled on the VLAN, the member port facing a DHCP server must be marked trusted, or server-originated OFFER/ACK arriving on an untrusted member port will be dropped. Since OFFER/ACK return either as broadcast or unicast back through the BD, please document how snooping trust state composes with the punt-via-member redirect path (does the redirect run before or after snooping enforcement?).
| vppctl show lcp | ||
| bvi10 → tap_Vlan10 | ||
| bobm0 → Ethernet0 (physical) | ||
| bobm0.10 → Ethernet0.10 (auto-subint) |
There was a problem hiding this comment.
Minor — this example contradicts S3.6. S3.6 mandates lcp-auto-subint off and states no Linux Ethernet0.10 netdev is created. But this show lcp output lists bobm0.10 -> Ethernet0.10 (auto-subint). One of them is wrong — fix this example to reflect the disabled-auto-subint reality (parent Ethernet0 only), otherwise it misleads implementers about what netdevs exist.
Signed-off-by: Yue Gao <yuega2@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Signed-off-by: Yue Gao <yuega2@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
4 participants
why
VLAN BVI is not supported today and an issue has been created: sonic-net/sonic-buildimage#26936
what this PR does
Create an HLD to document how we plan to support ARP, DHCP and unicast packet to VLAN.