哦你要支持 windows……那么 go plugin 不行。
purego 显然也不可以，这里不只是没有 runtime 的问题，还有当两个 runtime 在同一个进程里存活时是不是有打架的风险，我不好说，我觉得至少协程调度的时候如果双方互相不认得对方，可能会有很微妙的问题。

为什么是「调研使用 CGO 来加载由 Go 编译的动态库」而不是直接使用 https://pkg.go.dev/plugin ，从你的描述中我好像没看到和这个能力冲突的需求

这种风骚属于脱离生态后不得已而为之，带有强迫的属性，所以是其他「受害者」。
上游先有一个预处理器把 excel 干掉，剩下的事情就好办很多……

看来更新到我这边了，我这里也开始只有 218.80 了

羡慕正规宽带

这个是 TP 的水平问题，或者配置问题，不是什么踩不踩雷……

第一句话就在飞叶子了，“可以有超过/24 的子网”这句话意指是有某种规范要求子网不能超过/24 ，但 Class A/B/C/D 这种东西存在的时候，本身就没有 CIDR ，因为 CIDR 就是对应 classless subnet 的。

折腾这些没啥用，等你设备多了，业务丰富了，上传起来了，就要被限速了。

@shiyunjin BRAS 是很靠前的，如果不是物理拓扑上有割接（比如一个 BRAS 下带机量太多被拆到另一个）应该不太会变。这次应该是 DHCP 服务器从一个换成了另一个，从而导致地址池变化；另外可能转发时打的标签/VLAN 也有变，从之前精品网的实现形式换成了其他形式，所以 MTU 也从 1442 变成了 1480 。

之前这条隧道的 overhead 是 50 字节，大家猜测是 VxLAN ；现在 overhead 是 12 字节，我猜可能是 MPLS 之类的什么东西多打了几层？一个 v4 头就要吃掉 20 个字节了，不太像是什么上层的隧道。

@KexyBiscuit TX 没思路（肯定不是腾讯）。XIX 一开始我想的是西区局，但不对，这个范围太大了。

@KexyBiscuit 好怪，楼主是肇嘉浜机房，你是南汇周浦，但写的地区都是 GD ，但 vBRAS 的型号又不一样。

看起来像是他们在尝试割接什么新玩意。

请问可否在 dup 下分享下 vbras 名称？这样大家可以知道自己的 vbras 是否会被波及。感谢。

@bclerdx 这个读下就能读出来，不重要，只是 VBRAS 方便运营商上一些新类型的业务模板，传统 BRAS 扩展比较难。网段分配这种，无论是哪个 BRAS 都可以的。

总体上 DCN 不会用，DCI 可能会用，要看具体的演进选型，DCI 能用的技术栈往往受限于历史因素。

@shiyunjin 我这里没看到

Access-Concentrator: SH-SH-TX-VBASCP-1.NMAN.VNE9000
AC-Ethernet-Address: 00:00:5e:00:01:64
--------------------------------------------------
Access-Concentrator: SH-SH-XIX-MSE-1.MAN.M6000
AC-Ethernet-Address: cc:1a:fa:e9:67:a0
--------------------------------------------------
Access-Concentrator: SH-SH-TX-VBASCP-1.NMAN.VNE9000
AC-Ethernet-Address: 00:00:5e:00:01:65
--------------------------------------------------

暂时还没发现。楼主哪个区局？

就应该全体都搞 PCDN ，倒逼运营商取消不合理的 PCDN 限制。
呼吁微信、QQ 、拼多多加入 PCDN 阵营，搞死运营商。

不要用简单和复杂来评价系统的安全性。你家小区大门口挂着的那把三环锁结构很简单，没技术也没钥匙不还是打不开……
安全是相对的，你不会用就不安全。

啥方向的