@Spoter 啥卡，这么便宜，有多少 G 的漫游流量？

基本不会的，同城带宽很充足。但是流量大了可能会被当 PCDN 查了

@Tianao OLT 是参与 PPP 的，报文里插入点啥很简单的

这个事很简单啊，找个能看 pppoe 拨号日志的设备就行了，会告诉你为啥的。原因嘛，也很简单，就是 olt 请求 bras 的时候，会带上端口号，bras 会判断账号和端口的绑定关系，如果对不上就拒绝接入。

参考
https://support.huawei.com/enterprise/zh/doc/EDOC1100419262/3594afc3
如图 19-22 所示，用户发起 PPPoE 拨号。OLT 设备上使能 PPPoE+功能，在透传 PPPoE 报文的时候向报文中插入用于标识用户物理位置的 access-line-id （ PPPoE+）信息。BRAS 设备上使能 Option82 功能，信任客户端上传的 access-line-id 信息，向 RADIUS 服务器发送报文时不改变客户端上报的报文中携带的 access-line-id 信息。RADIUS 服务器上需要预先加载 RADIUS 属性字典文件，RADIUS 服务器在收到用户认证请求报文时，根据报文中携带的 access-line-id 信息，在认证回应报文中通过属性 Framed-Pool 下发 IPv4 地址池属性，通过属性 Framed-IPv6-Pool(100)和 HW-Delegated-IPv6-Prefix-Pool(HUAWEI-191)下发 IPv6 地址池属性。BRAS 设备上配置的地址池名称要与 RADIUS 服务器上一致，根据认证回应报文携带的地址池为用户分配地址。

找别人 ping 下你的 IP ，ping 的中间关了你的猫，看看会不会 ping 不通。如果还能 ping 通，贵运营商搞了 NAT4444 了 https://yangjunhui.monster/t/875867

@huaxie1988 你猜当交换机在 mac 表里找不到数据包的 mac 地址，不知道该向哪个口转发的时候，交换机会怎么办？

你看看你 ICMP reject ，回包的 IP ，应该就是你那个 nft 的 reject 导致的。交换机的 mac 表只是看了一眼报文里的 mac 地址和 ip 地址，就把对应关系记录下来了。而你的机器开了 ip_forward ，回个别的 IP 给网关很正常啊

@AEnjoyable 你这玩意就是一个普通的 bgp 呀，和 anycast 没啥关系。楼上说的很清楚，就是 IP 地址段登记信息的问题。这个也没啥办法，整个美国 native ip 做 NAT 吧

@MFWT 不光是 SLA ，而且特别稳，你去 ping 一下，延迟很低而且几乎不带变的。适合跑个语音啥的对延迟丢包敏感的业务。缺点就是真的贵

用 openvpn ，静态共享密钥，点对点，跑 TCP ，没啥协议号。墙看起来就是一段乱码，不知道为什么跑在 80 或 443 端口上。还带来一个额外的优点就是 QoS 的级别高
或者 openconnect ，思科协议，企业用的多，相对墙的不严。

@crc8 一般直接租三大运营商 + 军方的裸纤，然后自己做长传，成本嘛，说高也不低

openvpn p2p ，用 static key ，用的很小众，墙不管这个

@tywtyw2002 不至于的，都是硬件转发。没有哪个 2.5G 交换机跑 1 个小时会死机的。

回程是对端决定的，可能路由搞搓了，也可能就是为了分流，选一个便宜而烂的路径

还算良心啊，放了几个 bras 你能选选
北京这边只有一个 vbras 了

@povsister 哥我错了....

@tianwm 看看啥进程占的

@povsister nic 100%，这个是修改过优先级的进程占的 cpu ，等同于 usr ，占 100%，确实不太正常。

俩出口间相互发点包就完了。
搞个 VPN ，就说要给内网专项做互备，但是策略没做好，导致流量多发了一份...

可以的，和他们说清楚你是备份数据，目标地址就是一个 IP 。