AC1150丢包严重

公司使用ac1150，网桥模式。前段时间一直正常，最近发现丢包严重。

资源信息：

cpu:28%    内存：42%     磁盘：74%  会话21346

上网故障排除，直通模式也是丢包，拦截日志如下：

9:45:42

192.168.2.38:3144 -> 180.153.229.29:80

tcp

br0 -> br0

443(B)

线路1

360 update

360软件下载[5]

AppControl

appcontrol

应用服务控制丢包。

57

09:45:42

10.0.1.60:49152 -> 113.105.95.169:8000

udp

br0 -> br0

94(B)

线路1

ffffffff

00000001

AppControl

appcontrol

应用服务控制丢包。

58

09:45:42

10.0.3.115:2758 -> 221.8.69.25:80

tcp

br0 -> NULL

48(B)

线路1

00000000

00000000

web authen

webattest

用户认证丢包。

59

09:45:42

218.75.141.7:80 -> 10.0.3.99:62294

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

60

09:45:42

218.75.141.7:80 -> 10.0.3.99:62294

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

61

09:45:42

218.75.141.7:80 -> 10.0.3.99:62294

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

62

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

63

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

64

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

65

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

66

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

67

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

68

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

69

09:45:42

58.218.214.16:80 -> 10.0.3.99:51797

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

70

09:45:42

218.75.141.7:80 -> 10.0.3.99:62294

tcp

NULL -> NULL

1514(B)

线路1

多线程下载

下载工具

FluxCtrl

unknown

流控丢包。（流控缓存数据包过多）

您好，请问您说的丢包，是内网用户PING外网丢包，还是用户通过设备访问不了外网的某个应用？开直通后，访问是否正常了呢？

您好！根据您的直通日志，是流控缓存数据包太多以及应用控制两个模块导致的丢包哈，请检查一下流控设置处的上下行带宽呢？应用控制第一条有看到是360软件下载导致的丢包，麻烦确认一下上网策略里面是否有关于此的策略限制呢？

直通模式也是丢包，我自己电脑设置全局排除地址了，一样丢包。
10:13:10
10.0.3.193:2712 -> 218.17.116.203:80
tcp
br0 -> br0
131(B)
线路1
网站浏览
http_download
UrlMatchRule
webfilter
URL过滤丢包。（匹配了某个“浏览网页过滤”中的规则）
92
10:13:10
192.168.2.5:8 -> 180.149.132.47:0
icmp
br0 -> br0
40(B)
线路1
ICMP协议
ICMP
AppControl
appcontrol
应用服务控制丢包。
93
10:13:10
10.0.2.72:1025 -> 183.60.14.60:8000
udp
br0 -> br0
94(B)
线路1
ffffffff
00000001
AppControl
appcontrol
应用服务控制丢包。
94
10:13:10
192.168.2.124:8 -> 123.125.114.224:0
icmp
br0 -> br0
40(B)
线路1
ffffffff
00000001
AppControl
appcontrol
应用服务控制丢包。
95
10:13:10
10.0.1.47:30438 -> 119.147.20.81:8090
udp
br0 -> br0
65(B)
线路1
腾讯资源
QQUp-Live-旋风[U]
AppControl
appcontrol
应用服务控制丢包。
96
10:13:10
10.0.2.117:30898 -> 119.147.207.172:8000
udp
br0 -> br0
57(B)
线路1
腾讯资源
QQUp-Live-旋风[U]
AppControl
appcontrol
应用服务控制丢包。
97
10:13:10
10.0.4.142:1025 -> 163.177.69.40:8000
udp
br0 -> br0
94(B)
线路1
ffffffff
00000001
AppControl
appcontrol
应用服务控制丢包。
98
10:13:10
10.0.1.65:30378 -> 119.147.20.81:8090
udp
br0 -> br0
65(B)
线路1
腾讯资源
QQUp-Live-旋风[U]
AppControl
appcontrol
应用服务控制丢包。
99
10:13:10
10.0.4.142:1070 -> 14.17.19.41:8000
udp
br0 -> br0
94(B)
线路1
ffffffff
00000001
AppControl
appcontrol
应用服务控制丢包。

开直通和配置了全局排除，都一样丢包，那问题可能不在AC设备上哦，AC是网桥的，您可以先绕开设备，测试下看访问是否正常？
若这时，还是丢包的，麻烦检查下您的网关。

我所说的丢包严重，一直在ping某公司的ip丢包。中午会尝试绕开试试 。

您好！在流量管理处，保障带宽和限制通道是怎么配置的呢？通道使用范围的配置处，建议保障带宽适用对象除了选择HTTP应用，还需选择“网站类型”，另外将DNS做保障，保证DNS解析速度有保证，ICMP主要是满足客户在内网使用PING命令测试网络延迟性，当然，也可将ICMP作为单独通道来保障
设置带宽限制的时候，下行速率的限制尽量限制在20%~30%，建议启用“抑制p2p下行丢包”及“当线路带宽空闲时允许突破”

您先试试呢？

开始发现ping外网丢包，就一步步的尝试，发现到某公司这里开始丢包的。记忆中以前ping某公司时间也很短，现在多数在100ms以上。241是某公司设备ip地址
来自 192.168.0.241 的回复: 字节=32 时间=163ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=94ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=99ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=138ms TTL=63
请求超时。
来自 192.168.0.241 的回复: 字节=32 时间=98ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=124ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=62ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=103ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=101ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=169ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=131ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=140ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=93ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=36ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=48ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=53ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=45ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=37ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=149ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=148ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=22ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=68ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=115ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=6ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=1ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=19ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=156ms TTL=63

来自 192.168.0.241 的回复: 字节=32 时间=1ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=8ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=8ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=4ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=1ms TTL=63
请求超时。
来自 192.168.0.241 的回复: 字节=32 时间=21ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=5ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=4ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=120ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=7ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=173ms TTL=63
请求超时。
来自 192.168.0.241 的回复: 字节=32 时间=162ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=184ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=167ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=148ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=140ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=164ms TTL=63
来自 192.168.0.241 的回复: 字节=32 时间=124ms TTL=63

您好！如果是设备主动丢包的，就要检查是否是防dos攻击引起的，禁用防dos攻击后是否可以恢复正常？
如果不能恢复正常，则检测配置是否有问题，例如没有包含lan口、dmz口下面的全部的内网网段，或者dos防御的参数配置过小等。