Page MenuHomeFreeBSD

lagg(4): Tap traffic after protocol processing
ClosedPublic

Authored by zlei on Mar 23 2023, 9:39 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 21, 9:31 AM
Unknown Object (File)
Thu, Mar 21, 9:31 AM
Unknown Object (File)
Jan 31 2024, 8:49 PM
Unknown Object (File)
Jan 22 2024, 5:36 PM
Unknown Object (File)
Nov 12 2023, 12:06 AM
Unknown Object (File)
Nov 12 2023, 12:06 AM
Unknown Object (File)
Nov 12 2023, 12:06 AM
Unknown Object (File)
Nov 12 2023, 12:06 AM

Details

Summary

Different lagg protocols have different means and policies to process incoming traffic. For example, for failover protocol, by default received traffic is only accepted when they are received through the active port. For lacp protocol, LACP control messages are tapped off, also traffic will be dropped if they are received through the port which is not in collecting state and is not joined to the active aggregator. It confuses if user dump and see inbound traffic on lagg(4) interface but they are actually silently dropped and not passed into net stack.

Tap traffic after protocol processing so that user will have consistent view of the inbound traffic, meanwhile mbuf is set with correct receiving interface and bpf(4) will diagnose the right direction of inbound packets.

PR: 270417
MFC after: 1 week

Test Plan

Setup lagg0 and capture on the receive direction

ifconfig cxl0 up
ifconfig cxl1 up
ifconfig lagg0 create laggproto lacp laggport cxl0 laggport cxl1 up
tcpdump -nvi lagg0 --direction in

Verify the output. Should see incoming packets but not those are LACP PDUs when either or both lagg port is/are active.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

zlei requested review of this revision.Mar 23 2023, 9:39 AM
sys/net/if_lagg.c
399

I'd suggest either removing the lagg_proto_input() altogether (as it just returns m in the current code) OR
having a default handler function, so do you don't have the branch here.

Generally it LGTM, I’d suggest introducing a default no-op handler first (so it can be merged to 13) and removing pr_input at all (if there are no other uses) as a separate commit. I’d also wait for the feedback from other folks maro familiar with the code.

This revision is now accepted and ready to land.Mar 23 2023, 10:34 AM
  1. Use default noop input handler.
  2. Inline fast path.
This revision now requires review to proceed.Mar 23 2023, 2:16 PM
zlei marked an inline comment as done.Mar 23 2023, 2:18 PM
sys/net/if_lagg.c
2173–2174

While testing lacp setup, tcpdump shows LACP packets on lagg interfaces.

LACP packets should receive or be sent on lagg child interfaces but striped out from lagg interfaces. So bpf filter on lagg interfaces should not able to see them.

I'm not certain about it. Can someone comment on it?

Split and refactor default input handler into D39251. So it will be easy to MFCed.

Tap the interface after protocol input.

  1. LACP control messages are tapped off. bpf(4) should not see them.
  2. Set receive interface to lagg, so that bpf(4) on lagg(4) will diagnose the right direction of incoming packets.
zlei retitled this revision from lagg: Set receive interface earlier to lagg(4): Tap traffic after protocol processing.Mar 31 2023, 7:18 AM
zlei edited the summary of this revision. (Show Details)
zlei edited the test plan for this revision. (Show Details)
This revision was not accepted when it landed; it landed in state Needs Review.Apr 2 2023, 5:12 PM
This revision was automatically updated to reflect the committed changes.