nkloveni

基本不会的，同城带宽很充足。但是流量大了可能会被当 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://www.v2ex.com/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 ，思科协议，企业用的多，相对墙的不严。