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 <linux/module.h>
#include <net/bonding.h>
%}

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个理由维护这么做的合理性,怎么说呢?都归于皮鞋吧。


浙江温州皮鞋湿,下雨进水不会胖!

猜你喜欢

转载自blog.csdn.net/dog250/article/details/106802154