bj环境统计单向流比例将近40%

ID	Creation Date	Assignee	Status
OMPUB-1125	2024-01-24T17:06:36.000+0800	杨威	已解决

!image-2024-01-24-16-56-32-263.png|thumbnail! 请[~zhangzhihan]确认bj环境接入流量是否有存在单向流的情况zhangzhihan commented on 2024-01-24T17:13:52.817+0800:

从sapp的sysinfo.log上看，tcp没有单向流，udp有单向流但比例不高 !screenshot-1.png|thumbnail!

doufenghu commented on 2024-01-24T17:55:10.848+0800:

单向流计算：(asymmetric_c2s_flows + asymmetric_s2c_flows)/closed_sessions, 选取1月24日最近一小时(16:00-17:00) 单向流比例为38.81%。需Firewall协助排查下。

asymmetric_c2s_flows + asymmetric_s2c_flows = 130,703
closed_sessioins = 336,749

yangwei commented on 2024-01-24T20:44:14.964+0800:

“选取1月24日最近一小时(16:00-17:00) ” 查询会话日志，共计337008条

!image-2024-01-24-20-31-19-292.png|width=609,height=278!

在这个范围内查询{}session_record中{}单向流(filter=“sent_pkts=0 OR received_pkts=0“), 共计130969条，可知{}单向流比例130969/337008=38.8%，与issue描述一致{}

!image-2024-01-24-20-32-30-278.png|width=1160,height=526!

统计单向流会话的decode as分布，99.67%为BASE，进一步增加过滤条件，仅统计单向流中BASE的IP分布，发现单向流的Client IP排名第一的为5.5.5.5，其余多为内网地址（10.xx或者192.168.xx），Server IP排名靠前的也基本为内网地址。

!image-2024-01-24-20-38-42-125.png|width=810,height=378!

!image-2024-01-24-20-41-06-328.png|width=814,height=373!

结论：通过查询会话日志，1月24日(16:00-17:00) {}网关流量中接近40%为单向流，其中99%为UDP会话{}，且通信的双方大部分为内网地址，{}推测经过网关的流量存在内网地址间的测试流量{}。

yangwei commented on 2024-01-25T09:58:12.184+0800:

查询1月24日 23:00-24:00)的日志，共计110,232条，其中单向流49,069条，单向流比例44.5%，所有的的Decode path均为BASE。

!image-2024-01-25-09-29-21-037.png|width=721,height=310!

!image-2024-01-25-09-32-07-741.png|width=716,height=322!

!image-2024-01-25-09-33-40-660.png|width=713,height=406!

进一步分析，虽然功能端输出session_record设置需要达到的最小包数和字节数限制（目前限制为包数>3 AND 字节数>5），但是session_record中存在包数为1的记录，

存在该session日志的原因为，该session命中了一条Monitor_ALL的安全策略。

!image-2024-01-25-10-07-37-292.png|width=682,height=375!

yangwei commented on 2024-01-25T10:40:01.025+0800:

综合上述情况，目前Live Traffic Chart和session_record统计指标存在如下问题：

问题1：session record过滤小流的限制条件，在session命中安全策略时仍然会被发送，并且在session record中能够被查询和统计，容易给用户造成困惑。 ** 方案1：不再设置过滤小流的限制条件，对所有session进行记录 *** 优点：数据口径一致，不存在用户不可感知的隐藏参数 *** 缺点：日志量可能增加（按照各个现场的经验，由于UDP小碎流的存在，预计日志整体增加一个数量级） ** 方案2：界面开放给用户设置记录session record过滤小流的条件，查询session record时olap执行该条件 *** 优点：用户可感知参数，在设置合理的前提下，能够有效减少小流的日志量 *** 缺点：增加从界面同步的参数
问题2：Live Traffic Chart的数据源，对所有的session进行统计输出（未执行session record过滤小流的限制条件），会造成Live Traffic Chart计算的单向流比例，与session record不一致（结合问题1，当前Live Traffic Chart为全量统计结果，session record记录的是过滤后的小流+命中策略的所有流） ** 方案1：从Live Traffic Chart中展示单向流的比例目的出发，如果是向用户展示接入流量的完整性趋势，参照24.01版本之前仅根据session record计算的逻辑，Live Traffic Chart中单向流比例仅展示TCP会话相关的结果 *** 优点：单向流比例不受UDP流干扰，更能反应流量中整体的情况 *** 缺点：未统计所有流，与session record查询结果对比时需要增加ip protocol=tcp的过滤条件，可能增加给用户的解释成本 ** 方案2：参照问题1的方案2，功能端输出Traffic Metric时，也执行小流过滤条件，仅输出满足条件的流的统计信息 *** 优点：数据输出口径保持一致 *** 缺点：未对所有流进行统计，增加给用户的解释成本
问题3：session record中，对于未达到满足app识别最小包数（当前值为20包）的流，功能端Application字段填充为-，在Live Traffic Chart中，Application值为-和unknown都被计算为unknown，该统计结果，与session record中的值不一致，容易给用户造成困惑。 ** 方案1：功能端对未满足app识别最小包数的流，统一标识为unknown *** 优点：数据口径一致 *** 缺点：Application为unknown可以作为策略条件执行，但对于未满足最小识别包数的流，在流结束时（通常为active timeout）执行安全策略无意义，此时产生安全事件日志容易给用户造成歧义（例如deny失效） ** 方案2：将app识别最小包数作为参数开放至界面允许用户配置，未达到最小识别包数的Application仍然被标识为-，同时Live Traffic Chart中增加-的统计行 *** 优点：用户可感知参数，减少解释成本 *** 缺点：当最小识别包数设置为较小的值时（例如1），安全策略不生效的歧义仍然存在

yangwei commented on 2024-01-29T13:38:51.554+0800:

经2024-01-29讨论，上述3个问题，对应的解决方案选择如下：

{}问题1{}：选择{}方案2{}，界面在是否开启session_record的开关处，{}增加可配置记录最小包数{}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。

{}问题2{}：{}现有逻辑不做更改{}。Live Traffic Chart统计的对象为全流量，session_record记录的是过滤后的流信息，两者的结果不能保证完全一致，仍然保留Live Traffic Chart记录所有流的特性

{}问题3{}：选择{}方案1，{}对于未满足识别长度即结束的流，统一标识为unknown，由于此时已不具备执行安全策略的条件（通常由时间触发active timeout，对应的session状态为closing），在此阶段不再执行安全策略。

zhangwei commented on 2024-01-31T15:57:17.319+0800:

{quote}{}问题1{}：选择{}方案2{}，界面在是否开启session_record的开关处，{}增加可配置记录最小包数{}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。 {quote} 在仍然有Management Vsys的版本中实现此功能，UI和CM在Management Vsys查询Session Records设置该限制作为过滤条件比较复杂，打破了现有CM补全Vsys过滤条件的实现逻辑。

当前实现：vsys_id in (1,2,3) and ($filter)
如增加最小包数限制作为过滤条件：( (vsys_id=1 and recv_pkts+sent_pkts>=$vsys1_min_packets) or (vsys_id=2 and recv_pkts+sent_pkts>=$vsys2_min_packets) or (vsys_id=3 and recv_pkts+sent_pkts>=$vsys3_min_packets) ) and ($filter)

doufenghu commented on 2024-01-31T16:28:20.330+0800:

[~yangwei] 界面增加min_packets阈值后，UI查询OLAP默认为什么要增加过滤条件？Session Records 还会有小于min_packets的日志？

yangwei commented on 2024-01-31T16:34:39.265+0800:

24.01以后，功能端生成session_record与策略日志合并，对于命中策略的会话，即使不满足min_packets的条件，依然会向session_record的topic发送该会话的信息（例如上述分析中提到的命中monitor_all策略，但仅传输1个包的情况）。

doufenghu commented on 2024-02-01T10:05:28.718+0800:

建议命中策略并且小于min_packets的会话，查询时默认不对其增加过滤条件。目前会话日志设计上以流量为中心，以全局视角应看到所有命中策略的日志。

gitlab commented on 2024-02-05T18:47:12.855+0800:

[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|9407dcda1f] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: Supports user-specified packet number limit for sending logs{quote}

gitlab commented on 2024-02-05T19:07:56.344+0800:

[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|ce64026bca] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: session is not identified app, and unknown is filled by default.{quote}