新的中广宽带，
官网 www.5gtv.com.cn

目前新广电骨干网
2 个骨干节点，北京，重庆
8 个汇聚中心，天津，西安，武汉，南京，上海，成都，贵阳，广州

网内资源走自建骨干网，公网全部落地走移动，目前广电双栈 v4 & v6 只有移动一个上联，
对公网来说，你可以认为广电就是移动

@JensenQian @Licsber 广电暂时没用自己 AS ，都由各地移动 AS 代播，当地移动没有 AS 的就都在 9808
对于宽带来说，
ipv6 240a:4000::/21
ipv4 223.160/16 221.146/16

10G 到末端 2.5G 的设备中间有设备不支持 flow control ，很显然要么是你的（ 2 个 10G ，8 个 2.5G ）交换机出现了问题，要么是你的 10G 光猫出现了问题，不支持暂停帧。
原理很简单，10G 你能跑到 2600Mbps ，而 2.5G 接口最大只能跑到 2350Mbps ，
在你测速时来自 10G 的 2600Mbps 瞬间把你 2.5G 接口流量打满，每秒超过的约 300Mb 数据没有地方存储，只能丢掉凭空消失，造成了巨量的丢包率，导致更高重传。
启用 flow control 后，来自 10G 接口的流量打满 2350Mbps 后，交换机会向上一级流量来源设备逐级发送暂停帧来中断传输，以保证 10G 接口到当前 2.5G 的流量始终不大于 2350Mbps ，否则会导致巨量丢包触发巨量重传，最终稳定在接口速度的半速（一半正常数据包，一半重传）

任何存在不等速接口的网络设备都会存在该问题，10G->1G ，10G->2.5G ，都需要启用 flow control 来确保高速接口到低速接口的流量不超过低速接口的承载能力。

解决方案两个，要么全链路设备启用 flow control ，要么上级设备限速，让 2.5G 接口的设备限速不大于 2350Mbps

@guidozeng 买个中兴 E2631/E2633/E1630 ，便宜好用，妥妥的跑满千兆

@guidozeng i5 82xxu 在 Windows 下拨 pppoe 还真跑不满千兆，建议买个近期上市的路由器拨号试一下

桥接掉速妥妥的自己拨号设备性能问题，1Gbps 的 PPPoE 所需要的 CPU 性能是相当高的，
所谓局端设备也是升级 PPPoE ASIC 加速业务板卡，既然路由能跑满，那局端必然是升级过了的，
排查自己拨号设备性能吧，

有千兆接口不代表设备转发能力有千兆，
设备转发能力有千兆不代表在 PPPoE 下还能有千兆能力

即使没有 TR069 ，局端也可以通过 OAM/OMCI 控制你的 ONU ，三家都有重新启用 TR069 配置的信令

@Untu 上面提到的就是实际部署情况，上海电信和江苏电信 10G EPON 普遍为 1:16 或 1:4:4 ，少部分地区 1:8 ，浙江电信 XGPON 是普遍 1:64 （ 1:8:8 三级）起步，移动更喜欢 1:8:16 ，而且实际体验是低分光比地区全天近乎无波动，不像一些地区高峰期到网关都要 8ms 。
至于平滑演进，拿近期的 50G PON 改造来说，上海电信和江苏电信都做到了 EPON/10G EPON/50G EPON 复用，都是平滑演进，而 50G GPON 与 GPON 互斥，演进 50G PON 需要下线 GPON ，只能 GPON/XGPON 或 XGPON/50G GPON 二选一组网。

@yyzh @huangya @march1993 像上海电信和江苏电信都是在 2014 年-2015 年全市 /全省割接完成的 10G EPON ，那时候 XGPON 规范都还没有定稿，能选的只有 10G EPON 。
对用户来说 10G EPON 体验更好，像上海分光比都在 1:16/1:32 ，江苏是 1:16 ，部分地区 1:8 ，对用户来说带宽相当充足，
而 XGPON 普遍是做 1:64 分光，部分地区用高功率模块还能做到 1:128/1:256 的分光比，晚高峰的体验相当爆炸。
另外在接入网延迟上，XGPON 天生要比 10G EPON 高 0.6ms ，实际部署可能 XGPON 到网关 2-5ms ，而 10G EPON 能控制在 0.8-2ms ，天窗的波动也更少。

@Imsw93 @tcsky 上海联通场景宽带中的主播宽带，是 1000M 配 300M 上行的且相对静态 IP 的，现在是开不出了，只有存量用户。

@NSAgold #44 @iijboom #45 这么说吧，北京的 IPv4 持有数量比上海、广东、浙江、江苏、山东加起来还多

@ivanchou 再等等，新出库存不是很多，等大规模出货就便宜了

@YaNanGe #41 毕竟移动是亲儿子，联通和电信都改制过了，去年联通电信各给了移动两个 /17 还是 /16 大段，移动拿去搞移动云了也不分给宽带用户。

在运营商的 CGNAT 模式下确实是 NAT4 更省 IP ，CGNAT 开 NAT1 是每个用户固定分配 2000~3000 个端口范围，对应 65535 个端口只能开 20~30 个私网用户，但是 CGNAT 开 NAT4 后，公网 IP 的每个端口都可以多次复用给多个私网用户，甚至同一个用户也可以复用同一个端口，可获得几十倍的并发连接数提升。
至于 @heiher #3 提到的 NAT 硬件加速，实际上现在运营商都在改造为虚拟化 vBRAS ，列如华为的 VNE9000 、中兴的 V6000 ，转发平面开始上云并且用 x86 堆性能，同步改造 NAT4 也是没什么问题的。

@YaNanGe @qwvy2g 一朋友投诉到省公司和 10085 服务监督热线了，最后转到技术部门给的答复是与 PCDN 关系不大，给出的解释是移动的公网 IP 池用完，一个公网 IPv4 用 NAT1 模式最大开 30 个用户保障 2000 个 TCP 连接，用 NAT4 可以开 200~500 个用户保障 2000~5000 个 TCP 连接，被迫改造而已。一些地方 IP 缺到专线都开不出来了，未来各个地区都会推进改造。
移动现在宽带用户接近 4 亿，比电信和联通加起来用户还多，IPv4 资源还不到电信的零头，现在是遇到第二次枯竭，即使用 CGNAT 也不够用。

@morebuff @bytesfold 咸鱼有，关键字就是 ZTE D321 ，中兴 D321 ，新出的很漂亮

ZTE D321 ，最近新出的，360 到手

F4607P 的下行光是私有协议，非中兴 ONU 无法认证，华为也是同理
除非你能修改固件适配中兴私有协议~

@llinge #17 上面只提到了使用 ICMP 发送到你出口公网 IP 这一种方式，实际上还有通过业务通道探测 MTU 的方式，比如在 MQTT 的 TCP 长连接中发送不可分片的大包进行探测。
#19 目前支持 IPoE 认证的设备大都严防死守，各厂家甚至还加了 secure boot 和分区加密，以前的破解方式失效了，也没法把二进制提取出来分析，只能后期再看了。

@2397613259qqq #20 推测 MTU 只是风控参数中的一环，专线这些可能有其他参数。

@dianso #21 既然能收到 ICMP 包，那必然是公网，移动也是公网地址。

@lshero #22 ipv6 体验比较差，最近一直关闭使用的。

@dndx #23 同意，MTU 只是众多风控参数的一环，实际上通过 TCP 探测更有效，比如一个 C 段里面都是 1492 的 MTU ，其中几个 IP 是 1440 ，那必然是通过某些代理访问的，如果一个 C 段都是 1440 的 MTU ，那也不会有问题。所以猜测是割接 IPoE 导致同一个 C 段里面既有 1492 又有 1500 ，触发了风控。
#25 经过群友测试，几个不同的网站都会触发某一地的探测，因此推测是某个第三方风控产品的厂家做的，风控服务 /各种拖动滑动验证码服务 /IPGeo 服务这些。
#37 @lxcopenwrt # 38 @billccn #40 现在反过来想，这个奇淫技巧确实有效，毕竟大部分企业普通宽带，家庭宽带都是 PPPoE 的方式，一但 MTU 变小或者过大，都可能是套代理或者 IDC 爬虫自动请求之类，加上其他一些参数进行风控也算合理，至于企业专线手机上网这些，第三方 IP 地理位置库都有标记，按需加白就可以，剩下只有这些动态 IP 的拨号宽带需要处理了。

@rrfeng #28 发帖的时候写错了，确实是 type 3 code 4 ，而且是我回复的包，与服务器无关。实际是我访问某网站南京的 CDN 节点，几十秒后会有浙江的 IP 连续发包探测，而且这种有规律的 ICMP 包在空闲时段没有，因此是我来回复，与服务器端与中间设备都无关，因为 1500 的包已经正确到达了我公网 IP 。而且已经说明了，这只是最简单的一个例子，而且不一定是唯一风控条件，比如某厂还会在业务 TCP 长连接发大包探测 MTU 。
routeros 日志如下
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1500
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1472
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1440
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1400
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1280

@Untu #29 所以 MTU 不是唯一风控条件，只是其中一个参数。

@tavimori #31 是的，ICMP 的方式只能探测到公网终结点，上面提到的是公网 IP 的情况，联通和移动都是公网 IP 。所以一些厂商还会用 TCP 通道来探测 MTU 。

@pcslide #48 ICMP 只是其中一种最简单的方式，在 TCP 业务通道也可以探测 MTU 。

@dndx #3 是会有一些触发条件的，不是必现，需要静置一段时间，再访问这些网站 /APP ，大约 15 秒的样子会有 ICMP 过来，后续访问都很少会有，也许是没有抓到包，访问的南京 CDN 节点，会有杭州的 IP 发送 ICMP 。

@lshero #4 @huaes #10 IP 段的问题考虑过，某位群友投诉运营商回退了 PPPoE 后，IPoE 和 PPPoE 都在同一个 C 段，也有通过 DDNS 历史记录交叉比对，IP 段没有太大变化，是固定几个段。

@msdurex #8 包含 PPPoE 的 8 字节包头 1500 字节包只会止步于 BRAS ，自 BRAS 出口至对方 IP 是剥离了 8 字节包头的 1492 字节包

@songofsaya #6 暂时只有一个不能改桥接的缺点，其他公网 IPv4 该有的都有，原来没有的现在也没有

@wwbfred ICMP 是异步的随机地区发来的，推断是某种后台风控触发的，以前 1492MTU 这些包到达运营商 BRAS 就会被丢弃或者回复 too big ，现在 1500MTU 恰好可以到达用户端设备。
根据多个小伙伴的观察，这些探测不只有 ICMP ，还有某些 APP 用业务长连接发送大包的方式，一些视频网站会用 websocket 探测等等。

@ilovey482i #12 理论上只要想探测，方法有很多种。

参考 /t/875867