必须全集群统一私网网卡MTU值并重启所有节点，否则CSSD等底层进程仍沿用旧MTU参数导致ORA-27550或ORA-27303；查所有节点ASM alert.log中ORA-27550、ORA-27303及MTU数值对比，确认后永久修改并重启集群。
oracle rac节点挂起（如cssd无法启动、asm报ora-27550或ora-27303）若由mtu不一致引发，**必须全集群统一私网网卡mtu值，并重启所有节点**——临时ifconfig或ip link set修改后不重启，rac底层进程（如css、gmon、lms）仍会沿用旧mtu握手参数，问题不会消失。
查alert日志确认是MTU不匹配而非其他网络故障
直接看ASM或数据库实例的alert.log，重点搜以下错误：
-
ORA-27550: Target ID protocol check failed—— 典型MTU协商失败 -
ORA-27303: Remote port MTU does not match local MTU. [local: 1500, remote: 9000]—— 明确指出两端MTU值 -
IPC Send timeout+lmon/lmdtrace中反复出现超时 —— 常伴随MTU不一致的通信卡顿
注意：不要只查一个节点。必须在所有节点上分别检查grid用户的ASM alert日志（路径类似$ORACLE_BASE/diag/asm/+asm*/trace/alert_+ASM*.log），因为节点间MTU差异是双向的，错误可能只显现在“接收方”日志里。
验证并统一所有节点私网网卡MTU值
先确认哪张网卡是私网（interconnect），通常不是eth0，而是eth1、enp0s8或明确标注为private的接口。执行：
ip link show <iface> | grep mtu
常见问题场景：
- 节点1显示
mtu 9000，节点2仍是mtu 1500→ 必须统一为9000（推荐）或都回退到1500 - 交换机端口未开启Jumbo Frame支持 → 即使OS设了9000，实际包仍被丢弃，需同步配置交换机
- 使用bonding或teamd聚合口 → 必须在slave接口和master接口上都设置MTU，且顺序不能错（先设slave，再设master）
永久生效（以RHEL/CentOS为例）：
echo "MTU=9000" >> /etc/sysconfig/network-scripts/ifcfg-<iface>
然后systemctl restart network，但仅此不够——见下一条。
为什么改完MTU还必须重启节点？
RAC的底层通信栈（CSS、CRS、ASM）在进程启动时硬编码读取当时网卡的MTU值，后续运行中不会动态重载。即使你用ip link set dev eth1 mtu 9000在线改了，crsd.bin、cssdmonitor等进程仍按旧值建链，导致：
- 心跳包被截断或丢弃，CSSD反复尝试重连后超时退出
- ASM实例启动时校验远端MTU失败，直接报
ORA-27550并终止 - 集群资源状态卡在
STARTING或INTERMEDIATE，crsctl stat res -t -init可见ora.cssd1长期OFFLINE
MOS文档Doc ID 947223.1明确说明：“After correct MTU issue, a node reboot is required to bring up CRS stack and ASM instance”。滚动重启不可行，必须停掉整个集群再逐节点启动。
容易被忽略的关键点
MTU不一致问题常被误判为“网络不通”，但ping通不代表RAC通信正常——因为ICMP默认小包（
- 用
ping -s 8972 -M do <peer_private_ip>（8972 = 9000 - 28字节IP+ICMP头），-M do禁止分片，失败即说明链路不支持该MTU - 检查交换机端口是否启用Jumbo Frame（如Cisco:
system jumbomtu 9000；HPE Aruba:jumbo） - AIX系统需额外检查
no -o ipqmaxlen和no -o rfc1323等TCP参数，MTU变更后这些也可能需调优
最稳妥的做法：所有节点停机 → 统一修改网卡MTU配置 → 启动交换机Jumbo Frame → 开机启动集群。别省那几分钟重启时间，否则问题会反复出现在alert日志里，直到你看到cssd真正进入ONLINE状态。
