还是之前的项目，在进行Oracle 的切换测试时，当把已经绑定成bond0的两个网卡上的网线都拔掉，发现系统会丢失网关，并增加了一条指向心跳网卡bond1的新路由，必须手动调整才能恢复。经过多方面的排查，最后发现是Oracle RAC 中VIP（浮动IP）属性设置不正确导致的问题，经用srvctl modify nodeapps调整后，问题解决。
一、系统环境
操作系统： 红旗 DC Server 5.0 for x86_64 SP2
应用： Oracle RAC 10.2.0.4
外网： 两块 Broadcom 5706 绑定为 bond0
内网心跳： 两块 InfiniBand: Mellanox Technologies MT25204 卡 绑定为 bond1
外网是普通的以太网卡，以标准的ifcfg-bond0 方式，把eth0、eth1绑定成bong0设备；
内网心跳是InfiniBand卡，因系统核心为2.6.9-42.7AXlargesmp，根据The OpenFabrics Alliance上的说明，该核心只能使用OFED-1.4版本。在/etc/rc.local 中，以下面的方式进行绑定：
ib-bond –bond-name bond1 –bond-ip 192.168.1.11/24 –slaves ib0,ib1
※ 注意：
根据OFED-1.4的说明，ib-bond支持ifcfg-bond1的方式绑定，但经测试1.4实际并不支持这种方式，只能以ib-bond命令来实现。
（OFED-1.5支持ifcfg-bond1 方式的绑定，但OFED-1.5必须在DC 5.0 SP3以上运行。）
二、故障现象
进行Oracle RAC 切换测试前，路由表如下：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.242.1.0 0.0.0.0 255.255.255.128 U 0 0 0 bond0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 bond1
0.0.0.0 10.242.1.52 0.0.0.0 UG 0 0 0 bond0
把已经绑定成bond0的两个网卡上的网线都拔掉，发现会丢失网关，及增加了一条指向心跳网卡的新路由：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.242.1.0 0.0.0.0 255.255.255.128 U 0 0 0 bond1
10.242.1.0 0.0.0.0 255.255.255.128 U 0 0 0 bond0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 bond1
三、问题分析及故障解决
1、临时方法
出现问题后，执行以下命令可临时恢复正常的路由表：
route add default gw 10.242.1.52
2、驱动问题
根据1.4版本的说明，编辑生成ib-bonding包，安装后会自动替换系统上自带的bonding：
/lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko
/usr/bin/ib-bond
/usr/share/doc/ib-bonding-0.9.0/ib-bonding.txt
# find /lib/modules/2.6.9-42.7AXlargesmp/ -name ‘bonding.ko’
/lib/modules/2.6.9-42.7AXlargesmp/kernel/drivers/net/bonding/bonding.ko
/lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko
# modinfo bonding
filename: /lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko
author: Thomas Davis, tadavis@lbl.gov and many others
description: Ethernet Channel Bonding Driver, v3.2.3
version: 3.2.3 A55A046AA99EE9DFBE71CAB
license: GPL
parm: fail_over_mac:For active-backup, do not set all slaves to the same MAC. 0 of off (default), 1 for on.
parm: arp_ip_target:arp targets in n.n.n.n form
parm: arp_interval:arp interval in milliseconds
parm: xmit_hash_policy:XOR hashing method: 0 for layer 2 (default), 1 for layer 3+4
parm: lacp_rate:LACPDU tx rate to request from 802.3ad partner (slow/fast)
parm: primary:Primary network device to use
parm: mode:Mode of operation : 0 for balance-rr, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb
parm: use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default)
parm: downdelay:Delay before considering link down, in milliseconds
parm: updelay:Delay before considering link up, in milliseconds
parm: miimon:Link check interval in milliseconds
parm: num_grat_arp:Number of gratuitous ARP packets to send on failover event
parm: max_bonds:Max number of bonded devices
depends:
vermagic: 2.6.9-42.7AXlargesmp SMP gcc-3.4
可见，当前核心有两个bonding.ko模块，正在使用的是由ib-bonding包提供的，已经替换kernel 包自带的bonding.ko文件。
因为从故障现象分析，问题应该是断开两外网网卡的网线后，bond0设备所触发的动作，故怀疑与bonding.ko模块有关。手动修改updates目录下的bonding.ko文件，令当前模块恢复kernel 的bonding.ko，重新测试，故障消失。（注意：这时ib-bond不能使用该模块来绑定为bond1）
3、Oracle RAC VIP 属性
由于（1）的方式使用的是kernel 提供的bonding.ko模块，不支持InfiniBand 卡的绑定，所以不能彻底解决问题。后经过仔细的测试和分析，发现Oracle RAC 的VIP属性设置有问题：
即同时监控bond0、eth0、eth1。
后修改为：
再进行拔网线的测试，问题彻底解决。
综合分析，bonding.ko模块只是一个更新，并不是根源，Oracle RAC VIP 的属性才是导致故障的根本原因。
三、遗留问题
测试时发现，使用OFED-1.4（包括1.5）提供的bonding.ko模块，虽可支持以太网设备：
bond0: e4:1f:13:1e:2a:1c 10.242.1.78/25
slave0: eth0
slave1: eth1 *
bond1: 80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:29:99:75 192.168.1.11/24
slave0: ib0 *
slave1: ib1
但是，当重启网络服务时，不会自动重新激活bondx设备的子网卡：
日志显示：
May 18 00:18:44 gdracdb1 kernel: ip_tables: (C) 2000-2002 Netfilter core team
May 18 00:18:43 gdracdb1 network: 正在关闭接口 bond0： succeeded
May 18 00:18:43 gdracdb1 network: 正在关闭接口 eth0： succeeded
May 18 00:18:43 gdracdb1 network: 正在关闭接口 eth1： succeeded
May 18 00:18:44 gdracdb1 network: 关闭环回接口： succeeded
May 18 00:18:44 gdracdb1 network: 弹出环回接口： succeeded
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: link status definitely down for interface eth0, disabling it
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: link status definitely down for interface eth1, disabling it
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: now running without any active interface !
May 18 00:18:44 gdracdb1 kernel: ip_tables: (C) 2000-2002 Netfilter core team
May 18 00:18:48 gdracdb1 ifup: 将 eth0 归属于 bond0
May 18 00:18:48 gdracdb1 ifup: 将 eth1 归属于 bond0
May 18 00:18:48 gdracdb1 network: 弹出界面 bond0： succeeded
这时，eth0、eth1网卡不会自动激活：
Link detected: no
# ethtool eth1|grep Link
Link detected: no
必须手动启动：
日志显示：
May 18 00:19:26 gdracdb1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
May 18 00:19:28 gdracdb1 kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
May 18 00:19:28 gdracdb1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: link status definitely up for interface eth0.
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: making interface eth0 the new active one.
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: first active interface up!
May 18 00:19:28 gdracdb1 kernel: bnx2: eth1: using MSI
May 18 00:19:28 gdracdb1 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
May 18 00:19:31 gdracdb1 kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex
May 18 00:19:31 gdracdb1 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
May 18 00:19:31 gdracdb1 kernel: bonding: bond0: link status definitely up for interface eth1.
网卡状态：
Link detected: yes
# ethtool eth1|grep Link
Link detected: yes
该问题，暂时没有找到彻底的解决办法，只能手动激活网卡。
配置双网卡绑定bonding
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/104526.html