oracle rac私网mtu必须全节点停集群后统一设置，因lms进程仅在启动时硬读mtu值；若未统一停启，将触发ora-15032及mtu mismatch错误，且需验证驱动、交换机、内核参数与oracle协议栈四者协同生效。
Oracle RAC私网MTU必须全节点停集群后统一设置
改 ip link set dev eth1 mtu 9000 后不重启集群，LMS 进程根本不会读新值——它只在启动时硬加载一次接口 MTU。曾有实例：节点1改完没停 CRS，重启后 ASM 直接报 ORA-15032: not all alterations performed，alert 日志明确提示 remote interconnect MTU mismatch: local=9000, remote=1500。
正确做法是：
- 所有节点先执行
crsctl stop crs（不能用crsctl stop cluster -all，它不强制停本地资源） - 再逐节点执行
ip link set dev <private_if> mtu 9000</private_if>（禁用ifconfig，部分内核下不持久且不生效） - 确认
/sys/class/net/<private_if>/mtu</private_if>显示 9000 - 启动前运行
cluvfy comp nodecon -n all -verbose，检查输出中所有节点的 MTU 值与连通性是否一致
验证不是“配了就行”，而是“UDP真走巨帧”
MTU 设成 9000 ≠ Oracle 的 GCS/GES 流量自动变大包。默认仍可能被拆成多个 UDP 小包，尤其当内核 net.core.rmem_max/wmem_max 太小，或 Oracle 隐含参数未调。
抓包验证才是关键：
- 在私网接口上用
tshark -i eth1 -f "udp port 61000" -Y "frame.len > 8900"（RAC 默认使用高端口，可查lsof -i :61000确认） - 若几乎看不到 >8900 字节的 UDP 包，说明流量没走巨帧——回头查
net.core.rmem_max是否 ≥ 9000、oracle用户进程是否继承新缓冲区值（需重启数据库实例） - 别只信
ping -M do -s 8972成功就收工；它只测 ICMP，而 RAC 用的是 UDP，协议栈路径不同
网卡驱动和硬件链路层支持比配置更难搞定
很多团队在 ip link set 后就以为完成，结果 ping -M do -s 8972 -I eth1 <remote_node></remote_node> 直接失败。问题不在配置层，而在链路层。
必须逐项确认：
- 用
ethtool eth1查Supports jumbo frames: Yes—— 若为No，得换驱动或网卡（如老版e1000e默认关 jumbo） - 查驱动参数：
modinfo ixgbe | grep jumbo应输出含jumbo_frames且默认启用；若未启用，加options ixgbe jumbo_frames=1到/etc/modprobe.d/ixgbe.conf并dracut -f -
cat /sys/class/net/eth1/mtu只反映内核允许设的值，不等于网卡能收发 9000 字节帧；必须配合ping -M do -s 8972实测
私网必须关 IP 转发，否则 UDP 包可能被误路由
RAC 私网是点对点直连通信，net.ipv4.ip_forward = 1 会打开三层转发，导致 UDP 包被错误地从私网接口转发出去，尤其在多网卡混用场景下极易丢包。
检查并固化：
- 执行
sysctl net.ipv4.ip_forward，输出必须为0 - 若为
1，立即执行sysctl -w net.ipv4.ip_forward=0，并写入/etc/sysctl.conf持久化 - 注意：某些 Linux 发行版（如 RHEL 8+）默认启用
nf_conntrack，也可能干扰 UDP 流量路径，必要时加net.netfilter.nf_conntrack_udp_be_liberal = 1
mtu 值。
