Linux bonding网卡与其slave共同使用

在昨天的一文中，我吐槽了Linux各种虚拟网卡设计的不完备，也只是吐槽，其实我并没有别的意思，我也懒得去做一些hack型的配置去规避这些不完备，我只是吐槽而已。

昨晚，有网友要求我给出一些解法，因为他也遇到了这个问题：

• 他希望被bonding的eth0可以独立工作，是的，作为管理口。

于是，这位朋友要求我给出一个解法，我意识到这个需求的普遍性，而且不是每个人都想去配置什么macvlan，ipvlan的，于是，我就想再写点。

在我的环境中：

• enp0s9被bonding到bond0。
• 我希望bond0处理2.0.0.0/8的流量。
• 我希望enp0s9处理1.0.0.0/8的流量。
• 我不希望以上通信受制于bonding的mode。

那么开始吧。

先看下为什么在enp0s9被bonding之后不通，stap一下子就看出来了，先看下现象：

[root@localhost bond]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.1             ether   0a:00:27:00:00:00   C                     enp0s8
[root@localhost bond]# ping 1.1.1.2
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
From 1.1.1.1 icmp_seq=1 Destination Host Unreachable
From 1.1.1.1 icmp_seq=2 Destination Host Unreachable
From 1.1.1.1 icmp_seq=3 Destination Host Unreachable
From 1.1.1.1 icmp_seq=4 Destination Host Unreachable
^C
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms
pipe 4
[root@localhost bond]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
1.1.1.2                          (incomplete)                              enp0s9
192.168.56.1             ether   0a:00:27:00:00:00   C                     enp0s8

很清晰是不是？

再看下stap的输出：

[root@localhost bond]# stap -e 'probe kernel.function("arp_process"){name = kernel_string($skb->dev->name); printf("%s\n", name);}'
bond0
bond0
bond0

Oh，yes！arp被bond0接管了，enp0s9作为slave不再呈现独立的网卡。

怎么办？改了便是！

这里我觉得就是bonding本身以及其rx_handler实现有问题！！用MAC地址区分一下不就得了？？
master把slave屏蔽本身就不合理！！

好，我就按照我的使用场景，改了它，首先，我把作为master的bond0和作为slave的enp0s9的MAC地址区分开，分别设置，然后再修改arp_process的处理逻辑：

%{
#include 
#include 
%}

function change_indev:long(skb:long)
%{
	struct sk_buff *_skb = (struct sk_buff *)STAP_ARG_skb;

	STAP_PRINTF(" aa :%s\n", _skb->dev->name);
	if (!strcmp(_skb->dev->name, "bond0")) {
		struct bonding *bond = netdev_priv(_skb->dev);
		struct slave *curr = bond->curr_active_slave;
		STAP_PRINTF(" aa :%s\n", curr->dev->name);
		// 更换一下接收device即可
		_skb->dev = curr->dev; 

	}
%}

probe kernel.function("arp_process")
{
	change_indev($skb);
}

probe begin
{
}

OK，再来一次：

[root@localhost bond]# stap -g ./probe.stp
WARNING: side-effect-free probe: keyword at ./probe.stp:27:1
 source: probe begin
         ^
 aa :bond0
 aa :enp0s9
^C^[[A[

开始ping吧：

[root@localhost bond]# ping 1.1.1.2
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.480 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.417 ms
^C
--- 1.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.417/0.448/0.480/0.037 ms

通了。

这种问题都是小问题，很容易就能解决，有人可能会说，配置一个macvlan不香吗？呵呵，我觉得这根本就不是一个问题。

我只管痛则不通，通则不痛，不通的给整通了就行，别的什么，我才不关心。

你能说出1000个理由证明这么做不合理，你也能说出1000个理由维护这么做的合理性，怎么说呢？都归于皮鞋吧。

---

浙江温州皮鞋湿，下雨进水不会胖！