Repository navigation
Conversation
8dbfa8b to
2aacf0d
Compare
2aacf0d to
01f146a
Compare
|
here's what the stdout logged spans look like: The 2 pods in this case are a basic alpine pod on the control plane and on the worker node. |
09c43a0 to
ff14441
Compare
| IpProto::Tcp => { | ||
| let (src_port, dst_port) = parse_l4_ports(data, offset)?; | ||
| Ok(ParsedPacket::Direct { | ||
| five_tuple: FiveTuple { | ||
| src_ip: outer_src_ip, | ||
| dst_ip: outer_dst_ip, | ||
| src_port, | ||
| dst_port, | ||
| protocol: IpProto::Tcp, | ||
| ip_version: if outer_src_ip.is_ipv4() { 4 } else { 6 }, | ||
| }, | ||
| l2_metadata: l2_meta, | ||
| ip_metadata: ip_meta, | ||
| }) | ||
| } | ||
| IpProto::Icmp => { | ||
| let (type_code, _) = parse_icmp_type_code(data, offset)?; | ||
| Ok(ParsedPacket::Direct { | ||
| five_tuple: FiveTuple { | ||
| src_ip: outer_src_ip, | ||
| dst_ip: outer_dst_ip, | ||
| src_port: type_code, | ||
| dst_port: 0, | ||
| protocol: outer_protocol, | ||
| ip_version: if outer_src_ip.is_ipv4() { 4 } else { 6 }, | ||
| }, | ||
| l2_metadata: l2_meta, | ||
| ip_metadata: ip_meta, | ||
| }) | ||
| } | ||
| IpProto::Gre => { | ||
| // TODO: GRE parsing | ||
| Err(ParseError::UnsupportedProtocol) | ||
| } | ||
| _ => Ok(ParsedPacket::Direct { | ||
| five_tuple: FiveTuple { | ||
| src_ip: outer_src_ip, | ||
| dst_ip: outer_dst_ip, | ||
| src_port: 0, | ||
| dst_port: 0, | ||
| protocol: outer_protocol, | ||
| ip_version: if outer_src_ip.is_ipv4() { 4 } else { 6 }, | ||
| }, | ||
| l2_metadata: l2_meta, | ||
| ip_metadata: ip_meta, | ||
| }), |
There was a problem hiding this comment.
I don't think I understand why the rest of this parsing is being removed
There was a problem hiding this comment.
So I removed this parsing because it only produced ParsedPacket::Direct, and direct flows never hit userspace parsing. eBPF already has the 5-tuple, ICMP fields, TCP flags, etc. in FlowStats.
My thought was to make the userspace parser’s job a lot more narrow. Basically, given a tunnel flow key and the UDP payload bytes, extract the inner 5-tuple and VNI.
If we do it this way, it would make the old full-packet parser redundant for direct traffic. And it'd make the old parsing incorrect for the buffer layout that eBPF sends for tunnels.
There was a problem hiding this comment.
@veronica-m-ef also worth noting, the old parse_packet_deep path was dead code on main, and it expected a full ethernet frame while ebpf sends the buffer starting at the VXLAN header, so it couldn't have parsed tunnels anyway.
ff14441 to
27ed7f9
Compare
fb6320a to
693bb59
Compare
693bb59 to
f6700b1
Compare
Keying the flow map on the inner 5-tuple in eBPF means both tunnel directions and the veth copy of a flow share one FlowStats entry, so userspace no longer has to dedupe by deleting map entries. It also gives tunneled flows real TCP state, flags, timeouts, and inner byte counts, and keeps distinct inner flows apart when they share an outer UDP port. The outer headers and VNI are stored in FlowStats as tunnel metadata. FlowStats grows to 240 bytes, so the map schema version moves to 2.
f6700b1 to
0d3c6d2
Compare
This adds VXLAN and Geneve support by decapsulating in eBPF, so a tunneled flow is tracked and exported as its inner flow with
tunnel.*metadata from the outer headers.The first version parsed the tunnel payload in userspace on the first packet only. Since each outer direction (and the veth copy of the same flow) got its own map entry, it had to delete the extra entries to avoid duplicate spans, which lost those counts and made eBPF re-send a new flow event on almost every packet. TCP state, flags, and direction also came from the outer UDP flow. Keying the map on the inner 5-tuple in eBPF fixes all of that in one place.
Changes
FLOW_STATSon the inner 5-tuple. Ports come from theparserconfig through a newTUNNEL_PORTSmap.FlowStats, oriented the same way as the span's source and destinationtunnel.*span attributes fromFlowStats, including flows first seen on a veth and decapsulated latermermin/src/packet) and the separate tunneled flow path in the producerEBPF_MAP_SCHEMA_VERSIONto 2 sinceFlowStatsgrows from 192 to 240 bytes (~5.2 MB max kernel memory at the default capacity, up from ~4.4 MB)eth0withvxlan_port = 8472and requirestunnel.type "vxlan"on the enriched span.pullPolicy,ipam.mode, rollout waits) in e2e setupNotes
node:8472endpoints.