The initial status of Linuxbonding and its solution

The initial status of Linuxbonding and its solution: start a bonding Nic and add two NICs with no network cable inserted into it. after pulling the bonding, ifconfig finds that it has a RUNNING mark, then plug in a slave and unplug it. ifconfig does not... linux bonding initial status problem and solution problem: start a bonding Nic and add two NICs with no network cable inserted into it. after pulling the bonding, ifconfig finds that it has a RUNNING mark, then, plug in the network cable of an slave and unplug it. ifconfig does not have the RUNNING flag. Analysis: The Problem of www.2cto.com is actually harmless, but it is only the first time to cheat the OS, but it will affect the track_interfaces configuration of keepalived, thus affecting hot standby switching based on VRRP, as a result, the hot standby status of several machines in the hot standby group with no network cables inserted will be chaotic once the machine is restarted. A machine without a plug-in cannot be a MASTER in any case, but keepalived sees the RUNNING mark of the bonding Nic and mistakenly thinks it can be used, which may become the MASTER state. Resolution and correction: to solve the current problem in a short and fast manner, replace the RUNNING-based judgment in keepalived with the LOWER_UP judgment, LOWER_UP is used to identify whether the NIC has a plug-in (but not absolute, it may be affected by other factors, but in most cases-obviously not all cases can think so). It turns out that this is completely possible, the problem is solved. But it violates the original intention of track_interfaces, so this change is not good! Www.2cto.com needs to know the status and layers of the NIC before Thoroughly correcting this problem. In general, the NIC state is divided into management state and Operation state. Manage state: This state is configured from top to bottom, indicating the administrator's willingness to operate state: This state indicates the current situation of the NIC, indicating whether the NIC is ready and capable of serving users. Now let's take a look at the various states of the network adapter in Linux: IFF_LOWER_UP-the cable has been connected and the IFF_RUNNING-Operation state is UP (when will the operation state be DOWN? 1. when the management state is DOWN, the administrator uses the command to down the NIC; 2. after the network adapter has no plug-in to understand these statuses, even if there is no keepalived, the status does not exist. this is not a hot standby switchover problem. there is no error in keepalived, even if the keepalived is corrected, so bonding will still affect other programs that use it... it is the bug driven by bonding that leads to incorrect state judgment. The return value of bond_open is 0, so the bonding Nic is in the START state by default, because the bonding Nic is in the IF_UP state when the physical Nic enslave is in the bonding Nic. You can see a frequently called function at the end of bond_enslave: bond_set_carrier. This function determines the status of all slave of the bonding Nic. If all the statuses are DOWN, the bonding itself is also set to DOWN. This should be a function called cyclically. The Call cycle depends on bonding's miimon parameter. In addition, bond_set_carrier will be called at several key points. for example, when a new slave is bongding, that is, when bond_enslave is called. Basically, the logic of bond_set_carrier is as follows: [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); // traverse all slave. as long as there is one UP, bonding will 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 ;}no problem. In periodic detection, all slave statuses are set: [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; // Set the status to FAIL, later, when bond_set_carrier is called, the bonding Nic slave-> link = BOND_LINK_FAIL ;... what's wrong ?? Why is the netif_carrier_off at the end of bond_set_carrier clearly absent from a physical network adapter? the reason is obvious: netif_carrier_ OK does not pass the judgment and does not pass the judgment, the reason is that the state of bonding does not involve the initialization of the bit _ LINK_STATE_NOCARRIER on the date of creation! What? This error occurs in the kernel! After changing it, add [cpp] netif_carrier_on (bond-> dev) before return 0 at the end of bond_open to correct this error. In addition, you need to modify the bond_set_carrier function: [cpp] www.2cto.com if (bond-> slave_cnt = 0) goto down. if slave_cnt is 0, you need to call netif_carrier_on to pull bonding, so that you can add a new slave to it later. the preceding statement is changed to: if (bond-> slave_cnt = 0) {netif_carrier_on (bond-> dev) goto down ;} this change is only for the sake of insurance. it is not necessary in essence. is it necessary to make this change? I have not tested it, as long as the initial status is correct, however, I still don't trust these people in the kernel community. Otherwise, how can I forget to initialize the carrier status? Www.2cto.com: This problem was encountered in my project. to catch up with the schedule, the leader decided to release the problem first and solve the problem quickly, I also had a conflict with the leaders, because I felt that a product would really need to be perfect and there would be no legacy problems to be solved when the users really needed them, it would be better to extend the product to perfection. this is my logic. As for why I didn't distribute the product, it was because the last moment of product release was reached, as the leader said, who is familiar with what is done? I think I am familiar with the network and kernel in the project team. Therefore, this problem can only be solved quickly, it's my fault, so I chose to work overtime to solve it. this is what I did when I got back to my house. this is the only way to ensure that the product is released on schedule. The key issue is whether or not the product release time should be subject to the product's perfection level. What if I select the latter?