这还只是锐捷的普通园区网型号。

拆风扇应该是可行的，以前见过锐捷的 PoE 交换机风扇全坏带着一堆 AP 上在没有空调的楼层弱电间机柜里上下 unit 除了配线架都是贴着上的交换机，系统一直告警告了几年屁事都没有，拿出来表面是真的烫手，不是热，用手托着往出抱抱都抱不住。

直接改个车载蓝牙或者 CarPlay 不香吗？

Oops, something went wrong, please try again later.
+1

不是说滴滴就是 K8s 升崩了么

「喜欢折腾配置环境，除了去做运维和自己接单有什么继续提高能力的方法吗」
😂主动揽下公司的屎山，敢为人先主动整改一步到位直接退烧。

"依据国家发票管理有关规定，铁路行业发票实行专业管理。原国务院铁路主管部门对铁路运输票据的式样、印制标准以及填写、使用方法有较为严格的规章制度，铁路部门出具的车票、区段票、代用票、客运运价杂费收据、退票费报销凭证、退票报销凭证、定额票、手续费等运输票据，具有发票属性，可用于报销。"

"如需报销凭证，应在开车前或乘车日期之日起 180 日内，凭购票时所使用的有效身份证件原件，到车站售票窗口、自动售/取票机换取报销凭证。办理改签后，可重新打印报销凭证。"

—— 12306.cn

很普遍，一线的水平其实是取决于客户的水平和 vendor 的强势程度的，客户水平垃圾、vendor 自己又不够强势，那一线只能被拖成复读机和工具人，二线才能处理真正意义的“故障”。

ThinkVision T27p-30 / P27u-20
这两个具体型号没用过，但是 T/P 系列的 USB-C 都用过，兼容性没有任何问题，定位都是商用产品，参数标得很直白透明，莱茵认证啥的该有的都有。

FortiGate 90G 或者 FortiGate 100F, 非常适合做多业务网关。

@solos #16 堆叠的可靠性和业务连续性能力不能满足数据中心需求是业界共识，就算不上全路由，vPC/M-LAG/MC-LAG + FHRP 也是基础，青云 2015 年因为 H3C 堆叠故障出过大事故。

@solos #14 青云……就是那个数据中心“汇聚层交换机”用堆叠的厂商。

看着成双成对的小情侣卿卿我我。

可以去中学门口的奶茶店，看着小情侣们，就回忆起自己的青春，当时候的我也是这样，

DisplayLink 和雷雳 4 扩展坞都不便宜，体验也未必有预期的那么好，不如再买个 C 口显示器。ThinkVision T 系列和 P 系列我都搭配过 MacBook, 连接性体验方面没有任何问题。

国内电话拨打 12308

如您的中国籍亲属在国外下落不 明，领事官员可以向您提供当地报警方式 及其他获取救助的渠道。所在国警方立案 的，可以敦促所在国警方及时妥善处理。
——中华人民共和国外交部领事保护中心《中国领事保护与协助指南》(2023 年 9 月)

性价比：肯德基 K 咖啡，咖啡包月卡 5 元/杯。

@CharonVIII #2 我测试下来，是 Windows 上的 nslookup 实现在通过 UDP 收到 Truncated 置位的应答、转而使用 TCP 并完成 TCP 的 3-way 握手后，会紧接着（也就是在这个 TCP 连接的第 4 个包）发送一个带有 PSH 置位的、仅有 2 bytes 的 TCP payload 的 TCP segment, 我不知道这个 2-byte 载荷的意义是什么（但猜测是用作一个什么出于性能或可用性目的的什么前导？），然后紧接着就收到了来自 223.5.5.5 的 TCP RST (我也不知道 223.5.5.5 为什么要 reset, 但是我猜测是 223.5.5.5 收到了这个不明所以的 TCP 分段，出于节省资源开销/防攻击的目的主动 reset 掉了这个 TCP 连接)，然而按照 Windows nslookup 的预期（这一「预期」我使用了其他使用 Windows nslookup 可以正常解析的 DNS 服务器进行了验证），这第 5 个包本应是来自服务端的正常 ACK, 然后 nslookup 再紧接着发送可以和第 4 个包进行 TCP segment reassemble 从而组成一个完整 DNS 请求的 TCP 分段，但是此时 TCP 连接已经被 223.5.5.5 给 reset 掉了。

目前的判断：Windows 的 nslookup 实现和 223.5.5.5 的某些策略性表现在 TCP 解析时存在兼容性问题。

目前的建议：在 Windows 上，在 PowerShell 中使用 Resolve-DnsName 能够获得比 nslookup 更接近 Windows DNS 客户端真实表现的测试结果。换言之，在 Windows 上，仅是 nslookup 失败不代表浏览器等真实用户访问行为调用的 DNS 解析也会失败。

「照理说 A 记录太多的网站肯定不止这一家...」
对于一般 web 服务的 GSLB, 国内一般都是地理+运营商分区解析，每个分区最终的 A/AAAA 记录真的远没这么多；对于国际化服务，虽然会使用 anycast, 但是 ADNS 会控制每次返回给 recursive DNS 的权威结果数量，也不会一次性返回好几十个 anycast 地址的 A 记录。

权威解析给这个 CNAME 配的 A 记录太多了，dig 在请求的时候携带了 UDP payload size (比如我的 macOS 的默认是 4096), 所以 223.5.5.5 会直接使用 UDP 返回这个八百多字节的递归解析结果； nslookup 默认没有在请求里携带 UDP payload size 信息，223.5.5.5 默认按 512 对待，返回了 Truncated flag 置位，让客户端去用 TCP 再请求一次。

至于楼主的 nslookup 为什么没有成功通过 TCP 解析，就要检查 nslookup 的实现、DNS 客户端的配置和 TCP 的联通性了（比如 telnet 223.5.5.5 53 ）。我的 macOS 的 nslookup 是会在这样输出之后正确显示最终的 A 记录的：
nslookup www.ai2moe.org 223.5.5.5
;; Truncated, retrying in TCP mode.

至于为什么阿里的 DoH 没问题，因为 DoH 和使用 53 端口的 DNS 是两个完全不同的协议，不存在这个默认最大 512 字节的限制。

至于为什么 119.29.29.29 和 114.114.114.114 和运营商 DNS 使用相同的 nslookup 和相同的 DNS 协议也没问题，因为它们直接无视了来自 DNS 客户端的 DNS 请求中携带的 UDP payload size, 偷偷把超长递归解析结果裁剪到不超过 512 字节（在本例中，是通过随机丢弃 A 记录的方式）通过 UDP 直接返回了。