Linux bonding的初始状态问题以及解决

发布时间：2014-09-05 15:19:46作者：知识屋

问题：

启动一个bonding网卡，往其里面添加两个根本就没有插着网线的网卡，拉起该bonding后，ifconfig发现其有RUNNING标志，然后将其一个slave插上网线再拔掉，ifconfig就没有RUNNING标志了。

分析： www.zhishiwu.com

这个问题实际上无伤大雅，只是在第一次欺骗一下OS而已，然而却会影响到keepalived的track_interfaces配置，进而影响基于VRRP的热备切换，导致拥有没有插着网线的机器的热备组中的若干台机器一旦重启，其热备状态就会混乱。没有插线的机器无论如何也不能是MASTER，可是keepalived看到了bonding网卡的RUNNING标志，误认为其已经可以使用，进而可能成为MASTER状态。

解析与修正：

如果仅仅为了短平快的解决当下问题，那么最简单不过的就是将keepalived中基于RUNNING的判断换成基于LOWER_UP的判断，LOWER_UP就是标识网卡有没有插线的（但不绝对，还可能受别的因素影响，但是大多数情况-显然并非全部情况下可以这么认为），事实证明这是完全可以的，问题解决了。但是却违反了track_interfaces的初衷，因此这种改法不好！ www.zhishiwu.com

在彻底修正这个问题之前还是需要了解网卡的各种状态以及层次。总体来讲，网卡state分为管理state和操作state。

管理state：这个状态是自上而下配置的，表示管理员的意愿

操作state：这个state是网卡自身现状，表示网卡目前是否已经准备好并且有能力为用户服务。

现在看看Linux系统中网卡的各种state：

IFF_LOWER_UP-线缆已经接好且上电

IFF_RUNNING-操作state是UP（那么什么时候操作state会是DOWN呢？1.在管理state为DOWN的时候，即管理员用命令down了网卡；2.网卡没有插线

理解了这些状态之后，即使没有keepalived，状态也不会，这就不是热备切换的问题了，keepalived并没有错，即便是修正了keepalived，那么bonding还是会影响到其它使用它的程序的...正是bonding驱动的bug导致了状态判断错误。

bond_open的返回值是0，因此bonding网卡默认就是START状态的，因为在物理网卡enslave进bonding网卡的时候需要bonding网卡是IF_UP状态的。可以在bond_enslave的最后看到一个频繁调用的函数：bond_set_carrier。该函数判断bonding网卡的所有slave的状态，如果全部为DOWN，则将bonding本身也设置成DOWN。这应该是一个周期调用的函数，调用周期取决于bonding的miimon参数，另外在几个关键点也会调用bond_set_carrier，比如在新的slave被bongding的时候，即调用bond_enslave的时候。基本上bond_set_carrier的逻辑是这样的：

[cpp]

static int bond_set_carrier(struct bonding *bond)

{

struct slave *slave;

int i;

if (bond->slave_cnt == 0)

goto down;

if (bond->params.mode == BOND_MODE_8023AD)

return bond_3ad_set_carrier(bond);

//遍历所有的slave，只要有一个UP，那么bonding就UP

bond_for_each_slave(bond, slave, i) {

if (slave->link == BOND_LINK_UP) {

if (!netif_carrier_ok(bond->dev)) {

netif_carrier_on(bond->dev);

return 1;

}

return 0;

}

down:

if (netif_carrier_ok(bond->dev)) {

netif_carrier_off(bond->dev);

return 1;

}

return 0;

}

没有任何问题。在周期性检测中，会设置所有slave的状态：

[cpp]

bond_for_each_slave(bond, slave, i) {

slave->new_link = BOND_LINK_NOCHANGE;

link_state = bond_check_dev_link(bond, slave->dev, 0);

switch (slave->link) {

case BOND_LINK_UP:

if (link_state)

continue;

//将状态设置为FAIL，此后再调用bond_set_carrier时可能会off掉bonding网卡

slave->link = BOND_LINK_FAIL;

...

到底哪里出了问题？？为何一块物理网卡明明是没有插线的，却没有调到bond_set_carrier最后面的netif_carrier_off，原因很显然了，因为netif_carrier_ok判断没有通过，为何没有通过，原因在于bonding自创建之日，其state根本就没有涉及__LINK_STATE_NOCARRIER这个bit的初始化！什么？这等错误竟然在内核里面出现！改了它便是，在bond_open的最后，return 0之前，加上一句：

[cpp]

netif_carrier_on(bond->dev);

即可修正这个错误。另外要修改的是bond_set_carrier函数：

[cpp] www.zhishiwu.com

if (bond->slave_cnt == 0)

goto down;

如果slave_cnt为0，那么就要调用netif_carrier_on将bonding拉起来，以便于后面往其加入新的slave，那么上述语句改为：

if (bond->slave_cnt == 0) {

netif_carrier_on(bond->dev)

goto down;

}

关于这个修改，我只是为了保险起见，实质上并无必要，到底有没有必要进行这个修改，我并没有实测过，话说只要初始状态正确，后面的只是按照既有的逻辑来过，不可能有任何问题，话虽如此，可我还是不信任kernel社区的这帮人，要不然怎么会忘记初始化carrier状态呢？ www.zhishiwu.com

插曲：

这个问题是我项目中遇到的，因为要赶工期，领导决定先把这个问题放一下，抓紧主要问题解决，我因此也和领导有了一次冲突，因为我觉得做一个产品，真的就需要完美无缺，不能有遗留问题等到用户真的需要的时候再解决，宁可延期也要完美，这是我的逻辑，至于说我为何没有把这事情分发下去，是因为到了产品发布的最后关头，正如领导说的，谁熟悉什么谁做什么，我自认为在项目组对网络，对kernel比较熟悉，因此这个问题只有我能快速解决，如果说我因为解决这个问题而耽误了项目进度，那是我的错，因此我选择在工作时间外加班解决它，这是我回到家里搞定的，也只能这样才能保证产品的按期发布。关键问题是，到底应该以产品发布的时间点为准呢还是应该以产品的完美程度为准。我选择后者，你们呢？

（免责声明：文章内容如涉及作品内容、版权和其它问题，请及时与我们联系，我们将在第一时间删除内容，文章内容仅供参考）