MTU不一致会直接破坏RAC私网通信可靠性，导致UDP包被静默丢弃、LMS收不到心跳或GC消息，70秒后触发实例驱逐；需停集群统一配置、验证端到端巨帧支持并检查交换机设置。
MTU 不一致会直接破坏 RAC 私网通信的底层可靠性，不是“连不上”，而是“看似通、实则断”——UDP 包在链路某处被静默丢弃，LMS 进程收不到心跳或 GC 消息，70 秒后触发实例驱逐。
私网 UDP 包被静默截断或分片失败
Oracle RAC 的 GCS/GES 流量（如 gc cr block、gc current block）默认走 UDP，单个消息可达 64KB。当节点 A 的 mtu=9000、节点 B 的 mtu=1500 时：
- 节点 A 发出一个 8972 字节有效载荷的巨帧（9000 − 28），但节点 B 网卡驱动/内核拒绝接收 >1500 字节的帧，直接丢弃，不回 ICMP error
- 若中间交换机未启用巨帧，也会在转发时分片；而 UDP 分片极易因任意一片丢失导致整包失效，
netstat -s | grep "reassembles failed"会持续上涨 -
ping -M do -s 8972 -I eth1 nodeB_private_ip在节点 A 上失败，就是最直接证据
HAIP 和集群初始化阶段立即报错
HAIP（169.254.x.x）依赖底层二层可达性，arping -I eth1 169.254.10.10 失败即表明链路不通。更严重的是 CRS 启动时硬读 MTU 值：
- 节点 A 启动时读到
mtu=9000，节点 B 读到mtu=1500，CRS 日志立刻报ORA-15032: not all alterations performed和remote interconnect MTU mismatch: local=9000, remote=1500 -
oifcfg getif显示子网与ip addr show实际 CIDR 不一致，会导致PROC-44: Error in network address and interface operations，OCR 初始化卡死 - 此时
crsctl check cluster可能仍显示 “online”，但 LMS/LMD 已 hung，AWR 中gc cr block lost暴涨
缓冲区与协议栈无法补偿 MTU 错配
调大 net.core.rmem_max 或启用 rds 协议，都建立在“链路能收发完整帧”的前提上。MTU 错配时：
- UDP 接收缓冲区再大也收不到被网卡丢弃的帧
-
rds模块加载成功、lsmod | grep rds有输出，但实际流量仍 fallback 到 UDP，因为底层连基本帧都通不过 -
tcpdump -i eth1 udp port 12560会发现：一端有发包，另一端完全无收包；或只收到零星 1500 字节分片，且reasm fails持续增长
验证和修复必须端到端闭环
改 mtu 不是改一个节点、不重启服务就能生效的事。关键动作缺一不可：
- 停全部节点：
crsctl stop cluster -all，不能滚动重启 - 统一设 MTU：
ip link set dev eth1 mtu 9000（禁用ifconfig），并写入网卡配置文件（如/etc/sysconfig/network-scripts/ifcfg-eth1加MTU=9000） - 检查硬件支持：
ethtool eth1 | grep "Jumbo frames"必须为Yes；若为No，需更新驱动或换网卡 - 验证物理链路：
ping -M do -s 8972+tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u，必须看到8972出现
最容易被忽略的是交换机端口——它不看你的 Linux 配置，只认自己是否全局启用了巨帧。哪怕所有节点 MTU 都对了，交换机 MTU=1500，故障照旧。
