maybeonly

默认出口上老老实实静态路由，选一个当 default ，另一个走单独的联通/电信路由表。
墙内的情况是，根据转发上游的 dns ，通常会解析到当前运营商的 ip ，可以匹配路由表出去。

@dosmlp 完全没看懂什么卡 bug ，esim 也不是什么国外专属的东西，只是国内被加了壁垒
为啥一定要手机呢，飞鸽传书八百里加急不行吗？
当年不让我用 wifi ，现在又限制 esim ，就抱怨他给我设置壁垒，剥夺我选择权怎么变成卡 bug 了
见证的话建议去 x

@dosmlp 难道不应该国内国外的月亮都一样吗？不敢让中国人看国外的月亮？本质上还是不自信，人为增加壁垒，限缩了消费者的选择权，增加了经营者的成本。

1.我家有两个 ipv6 出口，目前用的是 fdxx::出口做 snpt 。以前也尝试过把其中一条宽带的公网下发过去，走另一条宽带的时候在出口处做 snpt ，这样可以避免一些 app 误认为没有 ipv6 。后来改掉的原因是，觉得这样一个 webrtc 就找到你了，不好。现状就是写了一套配置脚本用配置文件配置 ipv6 的下发（ fdxx 或者来自某个 wan 的 dhcp-dp 或者不给）
2.软路由手搓的，想咋搓咋搓。
3.其他考虑：
内网互联从来不考虑 ipv6 ，因为涉及到真实 ip 和虚拟地址的转换，只有经过网关的时候才能生效，而且需要双向经过网关（ snpt/dnpt ）而实际上并不总是经过网关，或者会让网络环境过于复杂（现在已经非常复杂了）。内网互联老老实实使用 ipv4 。
从未考虑过下发多个前缀的 ipv6 地址，并不是所有设备都能兼容，而且同样的提高整个网络而不仅仅是路由器的复杂度。
有将拿到的/60 拆分成多个/64 在不同的 vlan 使用。例如 bt 采用的是单独的 vlan ，该 vlan 使用的是(1)中提到的真实地址下发，同时通过脚本添加了另一段的 ipv6 地址在 dummy 口以供上报。这里的情况同时下发多前缀似乎可行，但是考虑到使用统一的配置模板，并未如此操作。
而且多 ip 的话，考虑到 ipv6 有时候会自作主张地选择他觉得合适的前缀，这并不一定合适，如果出站连接的话路由器的路由表会帮他决策。

核心思想是路由器可以复杂，下面的接入层必须简单。

我自己是所有猫桥接+核心软路由+ap
但是建议考虑自己的需求实现，现代软硬件在家用环境不差几个 nat

@malusama 当时你可以选水货用 wifi ，现在无路可逃

@nkloveni
@beyondstars
那些隧道都是到某个地方的出口，比如到日本的出口，到香港的出口。
下面可能是 hy ，也可能是 xray ，也可能是 l2tp
连能不能 ping 都不知道，更别说 bfd 了

买数据库
这个肉眼看就是蜂窝，整个 223.104 全是各地移动的出口
p.s. 蜂窝和家宽的 mtu 差挺多的

其实早期只需要规划好用电还是用光（我用电）
然后 1G 还是 2.5G 还是 10G 以后都能升级（光也是类似的情况）
因为墙里的线是难以更换的，但是一个交换机是很容易更换的

之后就是交换机，我用的是网管交换机（ tl-sg2008mp ），但是现在都是当傻瓜交换机用
为啥？线插多了就乱了，即使我有标签有配线架
能不用 access 口解决的就别用，vlan 倒是可以，反正智能家居都在 wifi 上，给不同的 ssid 就是了
就算我家房子小也可以上两个 ap ，这不就自然互备了嘛（实际上 ap 也没坏过）

软件层面，我是坚定的核心路由器主义，路由器就是路由器，唯一主路由，其他东西尽量放到其他设备上
要开 docker 路由上指静态下去，bgp 就算了（因为还是需要手工配 peer ，也没地方飘）
墙内不过梯，即使是 dae 也不愿意过（我做的时候还没有 dae ）
梯子故障有监控有降级

至于很多故障，emmm
网线没办法，开发商/装修队的锅，根本没法处理，监控发现了又能如何，我选择眼不见为净。
交换机坏了可以换一个，但是我现在还放着一个没上电的交换机（好的），啥都没发生过。
个人以为有的时候不用为了每年一次或者更低频率的故障设计那么复杂的方案，特别是硬件故障。

p.s.我家是双线的，至于详细的方案我发过。