踩坑瞎记录
个人无前因后果的踩坑瞎记录。
有时候累了并不想深入分析，或者是懂了但懒得系统的写出来，所以就瞎记录一下，排版也懒得排，也懒得翻译。
因此本文可能存在未经核实的内容。
也可能顺便记录下偶尔会用到的东西。
随着时间推移，内容可能越来越多，桌面端请查看页面左边的页面导航。
DELL 服务器使用第三方 PCIe 设备后风扇转速高（90%）
反正就是非 DELL 认证设备，由于没有热量信息，服务器直接给你风扇拉到 90 来保证散热。
yum install OpenIPMI OpenIPMI-tools将第三方 PCIe 卡默认冷却响应逻辑设置为禁用（风扇正常）:
ipmitool -I lanplus -H -U -P raw 0x30 0xce 0x00 0x16 0x05 0x00 0x00 0x00 0x05 0x00 0x01 0x00 0x00将第三方 PCIe 卡默认冷却响应逻辑设置为启用（风扇拉满）:
ipmitool -I lanplus -H -U -P raw 0x30 0xce 0x00 0x16 0x05 0x00 0x00 0x00 0x05 0x00 0x00 0x00 0x00-H 填 iDRAC IP 地址
-U 填 iDRAC 用户名
-P 填 iDRAC 密码
如果关了散热不够，可以去 iDRAC 里面加个正向 offset。
网卡能识别，但不通，网卡灯不亮
反正就是系统里看着一切正常，ip a、ifconfig、lspci 都能识别，但就是不能用。
或者是全速跑一段时间后断开，端口完全无反应。
可能是网卡过热了，自动保护。
我有一张 X540-AT2 是这样的，这东西似乎也没有温度传感器，连 I350 都有。
Openwrt IPv6 不通
表现为能正常获取地址，但是从路由器 ping IPv6 显示 network unreachable，从 Windows ping IPv6 显示 网络不可达。
可能原因：
网络 -> 负载均衡（MultiWAN 管理器）-> 策略 -> 备用成员是 unreachable（不可达）而不是 default （默认使用主路由表）
所以把所有策略的备用成员都改成 default 就行了。
具体干嘛的没研究过，因为我也没使用多播、多 WAN。然而这居然会影响网络，不好评价。
另外我不确定默认是否开了 IPv6 MSS 钳制。（IPv6 包头长度和 IPv4 不一样，不开 MSS 钳制容易导致 PMTU 黑洞）
MSS 钳制在（不确定下面这个 MSS 钳制是否适用 IPv6）
网络 -> 防火墙 -> 区域 -> 编辑 -> MSS 钳制
不确定的话直接在启动脚本里面手动加一下
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o 接口名 -j TCPMSS --clamp-mss-to-pmtu
#例如
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe0 -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o wan -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o wan6 -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o wan6_6 -j TCPMSS --clamp-mss-to-pmtu
#不指定接口
ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuWindows 系统修复命令组
遇事不决修一下
sfc /SCANNOW
Dism /Online /Cleanup-Image /ScanHealth
Dism /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-image /RestoreHealth
sfc /SCANNOW在 pg_dumpall 或 pg_dump 中使用 .pgpass 无效
我是服气的，反正文档没说。
pg_dumpall 提到支持使用 .pgpass 文件，然后 .pgpass 提到使用方法是放到默认路径或者环境变量指定路径。
比如：
export PGPASSFILE=/somewhere/.pgpass然后 .pgpass 的格式是 hostname:port:database:username:password ，前四位可以使用 * 作为通配符，且必须用 chmod 0600 保护。
例如：
localhost:5432:postgres:postgres:verysecuritypassword那么你是不是觉得该这样使用 pg_dumpall：
export PGPASSFILE=/somewhere/.pgpass && pd_dumpall > foobar.sql这样你只会得到：pg_dumpall: 错误: 连接到套接字"/run/postgresql/.s.PGSQL.5432"上的服务器失败:致命错误: 角色 "root" 不存在
怎么回事呢？
原来 .pgpass 可以包含多行，于是 pg_dumpall 会去扫描每一行，和你提供的命令行参数匹不匹配。
比如，如果 .pgpass 中的 hostname 匹配 pg_dumpall --host 并且 .pgpass 中的 port 匹配 pg_dumpall --port ……，那么它将使用此文件中提供的密码。
如果某些内容不匹配，pg_dumpall 将忽略 .pgpass 里的该行内容。
所以实际上，你需要至少在命令行中指定用户名和主机名：
export PGPASSFILE=/somewhere/.pgpass && pd_dumpall -U postgres -h localhost > foobar.sql因此 .pgpass 前几个值可以使用通配符：
*:*:*:postgres:verysecuritypassword路由追踪有一跳的 IP 属于 DoD Network Information Center — defense.gov 但延迟很低
从阿里云、腾讯云等云追踪路由，发现其中一跳的 IP 的拥有者 AS749 是美国国防部 defence.gov？
# nexttrace 119.29.29.29
NextTrace v1.2.9 2024-03-04T14:32:40Z f96c3e5
[NextTrace API] preferred API IP - 45.88.195.154 - 1495.89ms - DMIT.LAX
IP Geo Data Provider: LeoMoeAPI
traceroute to 119.29.29.29, 30 hops max, 52 bytes packets
1 11.2.19.129 * DOD
0.62 ms / 0.49 ms / 0.49 ms
2 11.2.58.98 * DOD
0.64 ms / 0.66 ms / 0.60 ms
3 10.196.24.85 * RFC1918
100.75 ms / 100.72 ms / * ms
4 10.162.34.113 * RFC1918
4.67 ms / 4.03 ms / 3.93 ms
[MPLS: Lbl 53380, TC 5, S 0, TTL 1]
[MPLS: Lbl 49167, TC 5, S 1, TTL 1]
5 10.200.8.249 * RFC1918
5.58 ms / 4.58 ms / 4.79 ms
[MPLS: Lbl 48045, TC 5, S 0, TTL 1]
[MPLS: Lbl 49167, TC 5, S 1, TTL 2]
6 119.29.29.29 AS132203 [TencentCloud] DNSPod Public DNS+ tencent.com
pdns.dnspod.cn 8.26 ms / 8.23 ms / 8.23 ms
MapTrace URL:
可见前两跳 11.2.19.129 和 11.2.58.98 都属于 AS749，而 AS749 所有者为 DoD Network Information Center，IP 位置判断为 美国 堪萨斯州。
但从可见延迟非常低，看起来像内网。
这是因为这些公有云内网地址不够用，所以把美国国防部所有的地址拿来当内网地址使用了，并不是真的在美国，实际属于内网地址。
为什么用美国国防部的地址？
因为美国国防部没有在公网上宣告/使用这些地址，所以理论上不会影响联网。
Alpine Linux 启用 IPv6
Alpine 为了轻量化，默认没有开启 IPv6，接口也是在执行安装脚本的时候设置的。
按照官方文档
要自动设置 IPv6：
打开 /etc/network/interfaces ：
添加一行 iface eth0 inet6 auto 就可以了？
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 auto
auto eth1
iface eth1 inet dhcp
iface eth1 inet6 auto
然而当你 service networking restart 后发现并没有 IPv6 地址。
其实文档里还说
IPv6 DHCP Configuration
Alpine's use of ifupdown-ng supports three DHCP clients: udhcpc, dhclient, and dhcpcd. Of these, only dhcpcd can interact with both DHCP and DHCPv6 from the same process, which ifupdown-ng requires. Thus the IPv4 DHCP configuration given above will also result in the use of DHCPv6, but only if you install the dhcpcd package. (The ifupdown-ng scripts prioritize dhclient over udhcpc, and they prioritize dhcpcd over dhclient; see /usr/libexec/ifupdown-ng/dhcp.)
IPv6 DHCP 配置Alpine 使用 ifupdown-ng 支持三种 DHCP 客户端：udhcpc、dhclient 和 dhcpcd。其中，只有 dhcpcd 可以从同一进程与 DHCP 和 DHCPv6 交互，这是 ifupdown-ng 所需要的。因此，上面给出的 IPv4 DHCP 配置也将导致使用 DHCPv6，但前提是您安装了 dhcpcd 软件包。 （ifupdown-ng 脚本优先考虑 dhclient 优先于 udhcpc，并且优先考虑 dhcpcd 优先于 dhclient；请参阅/usr/libexec/ifupdown-ng/dhcp。）
摘自 https://wiki.alpinelinux.org/wiki/Configure_Networking（经过机器翻译）
所以你还需要 apk add dhcpcd 再重启网络应该就能拿到 IPv6 地址了。
802.3ad LACP 链路聚合也可以在接口间平衡流量？
RedHat Insights 告诉我：
Decreased network performance when using an incorrect LACP hash in networking bonding
In bonding mode 2 or 4, network traffic is not distributed to all port interfaces due to an incorrect hash policy. This results in decreased network performance.
These systems are affected by this issue because an incorrect LACP hash bundled with mode 2 or mode 4 is detected.
在网络绑定中使用不正确的 LACP 哈希时，网络性能会降低在绑定模式 2 或 4 下，由于哈希策略不正确，网络流量未分配到所有端口接口。 这会导致网络性能下降。
这些系统受此问题影响，因为检测到与模式 2 或模式 4 捆绑的不正确的 LACP 哈希。
摘自 https://console.redhat.com/insights/advisor/recommendations（经过机器翻译）（个性化内容）
详见：https://access.redhat.com/solutions/666853
模式 4 就是 802.3ad，根据知识库文章，就是加上 xmit_hash_policy=layer2+3 就行了
BONDING_OPTS="mode=802.3ad lacp_rate=fast miimon=100 xmit_hash_policy=layer2+3"但是不要用 layer3+4 因为不符合 802.3ad 规范。
然后单流（单会话）是不可能在多个接口上平衡的。因为交换机中没有任何东西可以保证到达多个交换机端口的流量按传输或接收的顺序传递。这种流量重新排序会严重损害 TCP 提高 TCP 窗口以实现良好性能的能力，并且会导致 TCP 拥塞控制激活，从而缩小 TCP 窗口，从而导致性能不佳。流量重新排序还会导致接收方无序接收 UDP 流量。如果接收应用程序没有预料到这一点和/或应用程序协议未实现数据排序，则可能会出现数据错误。
无评论