@jocover 我感觉 UPNP 也是导致丢包的一大主因 不过 SDN 设备的不是有 UPNP 开关吗？在 APP 里

@jowenzzzzz 是的，只要超过 5000kbps = 500kb/s 就会间接性丢包，这是我在用 EPON 设备时从来没遇到过的问题
PS: 上海电信 SDN 服务端从昨天开始坏到现在，好几个平台的网友都在吐槽，没办法认证设备、新设备注册不了，快要被 SDN 秀的头秃了…

@openbsd 家中的路由器 WiFi 已经足够，从来不用家庭网关的残废 WIFI :)

@openbsd 排查发现是直播软件 OBS 速率一高就会出现这种症状 但不理解其中原因 目前已降低直播码率 情况已解决 让小工再看看到底啥原理 :(

今天凌晨把直播推流减少到 3000kbps 并且挂了一夜后的结果：
192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 28161，已接收 = 28160，丢失 = 1 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 17ms，平均 = 0ms

配合 #38 的测试结果看
真的让人感到头秃，GP1700 难道就这么点能力吗…这谁顶得住啊

@jousca 是的，以前 500M 的时候使用 EPON 设备根本不用考虑设备负载问题…#38 的情况我晚上再试试… SDN 这种情况太让人大跌眼镜了…

进一步测试负载问题，目前 SDN 的网口 1、网口 2 分别连接 主路由器（ 10.69.1.x ）、游戏路由器（ 10.69.2.x ）
目前情况为 2 个路由器都已连入设备（主路由：15 个设备 | 游戏路由：1PC | 所有设备均为挂着没动 单纯的接入而已）

1)
由游戏路由的 PC （ 10.69.2.108 ）发起 200ping
※ 其他所有已接入的设备全部空载中
192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 200，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 1ms，平均 = 0ms

2)
由游戏路由的 PC （ 10.69.2.108 ）发起 200ping
※ 直播用 PC （ 10.69.2.109 ）开始推送直播画面（ 5000kbps ）
※ 断开主路由（ 10.69.1.x ）与 SDN 设备的连接
192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 199，丢失 = 1 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 1236ms，平均 = 49ms

3)
由游戏路由的 PC （ 10.69.2.108 ）发起 200ping
※ 直播用 PC （ 10.69.2.109 ）降低推送质量（ 3000kbps ）
192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 200，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 1ms，平均 = 0ms

？？？？？？？？？？？？？？？？

4)
恢复已有设置 SDN 网关（ 192.168.1.x ） -> 主路由器（ 10.69.1.x ） -> 游戏路由器（ 10.69.2.x ）
※ 其他部分设备开始搞事（看直播、刷微博、刷微信）
由游戏路由的 PC （ 10.69.2.108 ）发起 200ping
192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 200，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 10ms，平均 = 0ms

！？！？？！？！？！？！？！？！
等今天晚上再试试情况？直播 500kb 每秒都会让 SDN 崩吗…有点不敢相信

@jciba5n4y6u
@tmac6740
以前 EPON 的设备从来没遇到过这种情况，不过我升级千兆后小工坚决要使用 SDN 设备，8245Q 是属于 SDN 吗…百度了下感觉不像啊

@xdeng 测试结果均为有线测试 参考 #34 是 SDN -> PC 的空载有线 200ping 的结果…

@fruitscandy
@ThirdFlame
@justs0o
@jousca
@xdeng

全局域网 1PC 200ping 结果

192.168.1.1 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 200，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 1ms，平均 = 0ms

-- 百度 baidu.com
123.125.114.144 的 Ping 统计信息: 数据包: 已发送 = 200，已接收 = 200，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位): 最短 = 25ms，最长 = 27ms，平均 = 26ms

结果真的傻眼了…难道真的如 @jousca 所说是上海的 SDN 设备带不动这么多包的转发吗？
稍等把路由接进来看 200ping 结果…

@jousca 如果根据大佬所说，我是否可以理解为这种缓冲的情况是实际发生于 SDN 设备上的，SDN 设备的包转发效率没有办法处理我家设备的总发包量导致 发包队列缓冲过多，直接抛弃了部分数据包，最终导致了丢包 及 间接高 ping ？
（正在测试空载 ping 值）

@wtks1 我这里目前是全天闪断、高 ping，晚上尤其严重…十分绝望 昨天 0 点的时候甚至上海电信的 SDN 服务端崩了 导致我的设备无法认证 直接断网…

@Mac 换之前和我的情况一样吗=。=全天频繁高 ping 掉包闪断……

@celeron533 已经更换了 2 个 SDN 设备，掉线依旧，且 EPON 设备不存在该问题
所以我觉得问题不是发生在我的所有设备上（理直气壮！）

@18k 记住！电信的嘴，骗人的鬼！ EPON 稳如狗，SDN 冤大头！能不换就不换！！！血汗泪啊！！我今天搜了下才发现 SDN 被吐槽的渣都不剩…

@JJBOOM 是的，感觉已经刷新了我对上海电信的三观了…麻烦了这么多次小工到时候被是我自己的问题
据说上海电信一到晚上就 QOS 特别可怕，我到 0 点后试试 拔光钎空载 ping500 和 插光钎通外网 1PCping500 试试效果
真的是糟心 229 一个月的付费 最后还得自己做网络调试 :(

@xyzhou 是的，确实换路由器完全徒劳，事实就是在 SDN 上丢的包，而且内网都能丢成这样子更别说外网了。
不过无线测速不能作为接入速率的参考条件，如果你的设备要求网络质量必须有线接入，这是最基础的要求了。
我现在和我这边的小工说换个百兆的 SDN 设备看看是否是 GP1700 这个垃圾设备带不动我这里的负载 :(

@JJBOOM 我有考虑过是否有设备向路由器发起攻击，不过这种排查是否只能一个一个设备接进来再看丢包情况？
我这边设备几乎都是常用且在使用 EPON 时没有发生这种问题
PS: 我家的所有设备均在 10.69.1.x 下，如果有攻击发起难道不是向 10.69 网段攻击吗？有可能跨网攻击到 192.168.1.x ？

大致也说一下情况，主要的延迟表现为间接性的高延迟或丢包 大概是这样的表现，主路由（ 10.69.1.1 ）的 CPU 负载在 10%以内，所以理论上不会出现因主路由负载过高导致与 SDN 网关传输丢包的现象…我甚至换了个主路由现象还是这样，比目前使用的路由 CPU 更快，反而丢包更频繁，等稍晚的时候把所有设备切断，只连个 PC 来 ping 下 SDN 网关下…

（学了 8 年网络专业，这次真的触及到我的知识盲区了……感觉专业白学……）

来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=3ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=50ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=61ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=155ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=251ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=193ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=96ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=803ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=445ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=99ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=99ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=141ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=146ms TTL=64
请求超时。
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=2ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=21ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64