如果是家用网络，那软路由的确是足够了。只要规模稍微大一点，谁敢用软路由啊...

原来工作的地方用的是 ASR 9006，供 40000 多人同时上网，跑 Full BGP，多条 10Gbps 光纤接入然后用 100Gbps 的线卡连接内网：

1. 内存大存储大没什么用。路由做为转发设备，把包用最快的速度发出去才是王道，buffer 太大只是在增加转发延迟，内存的用处主要也就是存一存有限的路由表信息，不是越大越好。而 ASR 的包 buffer 用的是 SDRAM，虽然比较小但是速度要比 x86 的 DRAM 快了太多。另外 ASR 的路由查询是通过 TCAM 这种专门的内存进行的，只需要一个时钟周期就可以搜寻完整个路由表，试问 x86 有什么算法能做到这种效率？这也是为什么硬路由可以轻松做到小包线速，而 x86 就很难的原因。
2. CPU 给力同理，专用转发硬件基本上都是 ASIC 处理的转发，追求 CPU 性能意义不大。
3. 硬路由支持各种高级的防灾措施，比如带电带流量更换线卡，路由卡，电源等等。而硬件也都有冗余，就算一张卡坏了，另一张会自动顶上，用户甚至都不会察觉。x86 如果 CPU 坏了或者主板、网卡坏了就只能哭了。
4. 硬路由总线带宽大，ASR 9006 这种比较低端的型号吞吐都已经 12 Tbps 了，x86 还没有发布的 PCI Express 5.0 x16 也只有 63GB/s 的带宽，差不多 0.5Tbps。而 ASR 9922 这种顶尖型号已经能达到了 160Tbps。对这种用户来说，x86 根本就无法考虑。

当然软路由也不是没有意义。如果对成本比较敏感，流量没有到一定规模，偶尔宕机可以接受，那是完全可以考虑的。

有 ASN 跟 IP 多少没关系，更多的是为了能够部署高级的路由策略。

若干年前（> 5 年）去过一次 Genius Bar，他们是把电脑连到了一根特殊的网线上，然后系统通过那根网线 Netboot 到了一个特殊的硬件检查镜像里。很久没去了不知道现在是怎么做的。

当然可以。就算不重置密码也可以，用户不会知情。

https://developers.google.com/admin-sdk/email-audit/

@dbow 正解。

1、3 是冲突的。

想要稳定，可以考虑买 Juniper SRX300 这种，两年不重启都没事。再外挂个 AP 当 Wifi 即可。

这都是人家 90 年代玩剩下的技术：

https://en.wikipedia.org/wiki/Hashcash

Oracle 也是这样，按核心收费。

ssl_certificate 不支持变量解析，因为是在 config 阶段就读取了证书文件，没有运行时的动态行为。

据我所知，目前开源的项目里能达到你要的效果的只有 OpenResty 的 [ssl_certificate_by_lua_block]( https://github.com/openresty/lua-nginx-module#ssl_certificate_by_lua_block)，可以做到同一个 server 根据 SNI server_name 使用不同的证书。

@ryd994 然而并不是，Google Apps 的管理员最起码是可以在用户不知情的情况下访问用户邮件数据的，详见：

https://developers.google.com/admin-sdk/email-audit/

不仅是你当前 Inbox 的内容，甚至已经删除的 Draft 和 Inbox 都可以下载得到，而且用户不会得到任何的通知。

当然了，如果只用 GDrive 而且只存加密数据那也无所谓了，最大风险也就是某天突然无法访问了。

IBM 表示这都是人家 Mainframe 60 年代玩剩下的东西。

@flyingfz 正解，这么简单的需求用 OpenResty 几行 Lua 代码就搞定了，可以在握手前就断开连接，也不会发送证书。

https://github.com/openresty/lua-nginx-module#ssl_certificate_by_lua_block
https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ssl.md#raw_client_addr

对的。IPv6 使用 SLAAC 才会启用 Privacy Extensions，而 SLAAC 只有在 /64 或者更大的 block 上才可以使用。如果小于 /64 则只能走 DHCPv6，这种情况下 Privacy Extensions 不会（也没有必要）启用。

@s82kd92l 别的不知道，JunOS 早都支持 IPv6 Router Advertisement Guard 和 DHCPv6 Snooping 了所以就算 IPv6 环境下也可以防范类似攻击。

上企业级三层交换，将所有客户端的端口设为 DHCP untrusted。这种攻击对于三层交换机处理起来都是小菜一碟。不仅会过滤而且还会记录具体哪个端口发的包的日志。

比如 Juniper 对此的文档介绍：
https://www.juniper.net/documentation/en_US/junos/topics/example/port-security-protect-from-rogue-dhcp-servers.html

打开看一眼就知道了，就是用汇编实现的：

https://golang.org/src/runtime/asm_amd64.s#L2174

不太正常，有没有开 -j 选项？

你这么做，人家 D 还是成功的达到目的了。

Cisco ASA 带 Cisco Anychoonect，Juniper SRX 带 Pulse Secure 不过似乎都超过了预算…