Oracle RAC私网MTU不匹配一定会触发节点驱逐或CSSD启动失败，表现为ocssd.log中密集出现CRS-1611/1610/1607三连告警或CRS-7500超时，须端到端验证MTU一致性并抓包确认UDP心跳是否真实走巨帧。
Oracle RAC私网MTU不匹配不是“可能出问题”，而是**一定会触发节点驱逐或CSSD启动失败**——只要集群心跳流量经过分片，ocssd.log里就会密集出现CRS-1611/CRS-1610/CRS-1607三连告警，或GIPC连接超时（CRS-7500）。
查所有节点私网MTU是否真一致
别只信ifconfig或ip link show输出的数值，那是内核允许设的上限，不代表网卡能收发。必须端到端验证：
- 在每个节点执行
cat /sys/class/net/<private_if>/mtu</private_if>，确认值全为9000（或统一为1500） - 用
ping -M do -s 8972 -I <private_if><remote_node_private_ip></remote_node_private_ip></private_if>实测：若返回Frag needed and DF set (mtu = 9000)说明链路支持；若报Message too long，说明某处卡在1500 - 检查交换机端口MTU：Cisco用
show interface <port> | include mtu</port>，华为用display interface <port> | include MTU</port>，必须和服务器一致
抓包确认UDP心跳流量是否真走巨帧
MTU设对了，不代表Oracle的GCS/GES UDP包就自动变大。默认仍可能拆成多个1500字节小包，尤其当内核缓冲区太小或隐含参数未调。
- 在私网接口抓GIPC端口（通常是12560）：
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u - 若输出全是
1500或1514，说明链路某处强制分片（常见于交换机未开jumbo、网卡驱动不支持） - 若看到
8972或接近值（如8960~8980），才算真实走巨帧
看netstat -s里分片失败指标是否持续上涨
IpReasmFails是私网通信异常最敏感的早期信号，比AWR里的gc cr block lost更早暴露问题。
- 执行
netstat -s | grep -i "reassemble\|frag"，重点关注：IP: Reassemblies required、IP: Reassembly failures、IP: Fragments dropped after timeout - 若
Reassembly failures每分钟涨几十次，基本可断定MTU不匹配或链路丢包 - 注意：这个值在
/proc/net/snmp里是累计值，需对比两次采样差值，不能只看绝对数
停集群后统一改MTU，滚动生效会直接导致ORA-15032
Oracle Clusterware和LMS进程启动时硬读接口MTU值，运行中改ip link set完全无效，还可能引发ASM挂载失败。
- 必须先在所有节点执行
crsctl stop crs，再统一执行ip link set dev <private_if> mtu 9000</private_if> - 禁用
ifconfig：它不持久，且部分内核版本下ifconfig eth1 mtu 9000不生效 - 改完后启动前务必跑
cluvfy comp nodecon -n all -verbose，它会校验MTU一致性及私网连通性 - 若启动报
ORA-15032: not all alterations performed且alert日志提示remote interconnect MTU mismatch，说明有节点漏改或交换机没同步
真正难的不是改MTU，是确认从网卡DMA队列→驱动→内核协议栈→交换机ASIC→对端网卡，整条路径都支持并启用巨帧。任何一个环节掉链子，都会让gc cr block lost和节点驱逐反复发生。
