我试图通过VPN（GRE-TAP）使Linux绑定工作。 有趣的是，它只有当我在两台主机上运行tcpdump时才起作用，但是稍后会有更多…
有两台机器，分别叫做pxn1和pxn2 。 它们通过eth1使用简单的开关连接在一起。
pxn1 has IP address 10.1.1.197 pxn2 has IP address 10.1.1.199
为了获得安全的连接，所有IP通信都使用IPsec进行encryption。 这工作 ，我可以ping两台机器之间没有任何问题， tcpdump只显示encryption的数据包。
然后在两个方向上build立GRE-TAP （ 通过IP隧道以太网帧 ）接口，因为稍后将需要一个虚拟networking接口：
ip link add vpn_gre_pxn2 type gretap local 10.1.1.197 remote 10.1.1.199 dev eth1
ifconfig显示：
vpn_gre_pxn2 Link encap:Ethernet HWaddr 1a:73:32:7f:36:5f inet6 addr: fe80::1873:32ff:fe7f:365f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1462 Metric:1 RX packets:19 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294 (1.2 KiB) TX bytes:1916 (1.8 KiB)
这是pxn1 。 在另一台主机上，另一个方向上设置了相同的接口。
目前仅使用GRE-TAP设备build立桥接。
我需要这座桥，因为后来我想增加更多的机器（我的计划是将所有的GRE隧道连接在一起）。 最终结果应该成为VPN网状networking（每个主机 – 主机组合都有一个专用的GRE-TAP接口）。 但是现在我只是用两台机器进行第一次testing，这个桥当然是没有用的，但是对testing本身来说却是非常重要的。
brctl addbr vpn_br brctl addif vpn_br vpn_gre_pxn2
因为当我激活vpn_br接口并设置一些IP地址（仅用于testing网桥），ICMP PING就能正常工作。
vpn_br Link encap:Ethernet HWaddr 02:00:0a:01:01:c5 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1462 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:448 (448.0 B) TX bytes:468 (468.0 B)
Linux绑定界面现在已经build立。 再一次，因为这只是概念testing的第一个certificate，所以我只会添加一个奴隶到债券。
稍后还会有一个真正独立的Gbit网卡，其中一个专用交换机将作为主从设备（VPN只是一个备份），但现在绑定接口将仅使用VPN。
modprobe bonding mode=1 miimon=1000 ifconfig bond0 hw ether 02:00:0a:01:01:c5 # some dummy MAC ifconfig bond0 up ifconfig bond0 mtu 1462 ifenslave bond0 vpn_br # as said, only a single slive at the moment ifconfig bond0 172.16.1.2/24 up
HWaddr 02：00：0a：01：01：c7将另一台主机设置为172.16.1.1/24。
这导致理论上有效的接合界面：
bond0 Link encap:Ethernet HWaddr 02:00:0a:01:01:c5 inet addr:172.16.1.2 Bcast:172.16.1.255 Mask:255.255.255.0 inet6 addr: fe80::aff:fe01:1c5/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1462 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:448 (448.0 B) TX bytes:468 (468.0 B)
这个状态对我来说也很好：
# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: vpn_br MII Status: up MII Polling Interval (ms): 1000 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: vpn_br MII Status: up Speed: Unknown Duplex: Unknown Link Failure Count: 0 Permanent HW addr: 1a:73:32:7f:36:5f Slave queue ID: 0
…和路由表一样：
# ip route show 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 172.16.1.0/24 dev bond0 proto kernel scope link src 172.16.1.2 10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.197 default via 10.1.1.11 dev eth1
注意： eht0是一个单独的活动NIC（以太网交叉电缆），但eht0是恕我直言。
设置看起来不错，但是，PING不起作用（这是在pxn1运行）：
# ping 172.16.1.1 PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data. From 172.16.1.2 icmp_seq=2 Destination Host Unreachable From 172.16.1.2 icmp_seq=3 Destination Host Unreachable From 172.16.1.2 icmp_seq=4 Destination Host Unreachable
当ping时， 另一台机器上的 tcpdump （ pxn2 ）说：
# tcpdump -n -i bond0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:45:13.013791 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28 17:45:13.013835 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28 17:45:14.013858 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28 17:45:14.013875 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28 17:45:15.013870 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28 17:45:15.013888 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28
但是，当我还在另一个terminal上运行pxn1上的tcpdump时，我突然得到了我的ICMP回复！
... From 172.16.1.2 icmp_seq=19 Destination Host Unreachable From 172.16.1.2 icmp_seq=20 Destination Host Unreachable 64 bytes from 172.16.1.1: icmp_req=32 ttl=64 time=0.965 ms 64 bytes from 172.16.1.1: icmp_req=33 ttl=64 time=0.731 ms 64 bytes from 172.16.1.1: icmp_req=34 ttl=64 time=1.00 ms 64 bytes from 172.16.1.1: icmp_req=35 ttl=64 time=0.776 ms 64 bytes from 172.16.1.1: icmp_req=36 ttl=64 time=1.00 ms
这只有在两台机器都运行tcpdump才有效。 我可以启动/停止tcpdump并且只有同时在两台机器上运行程序时才能看到回复。 我试试哪台机器并不重要。
这是一个内核错误还是（更可能）有我的configuration一些问题？
这是否正常，桥接和绑定接口都显示相同的MAC地址？ 我只手动configuration它的键合接口，这显然也改变了桥梁..
FYI，configuration概述：
当我将网桥接口设置为promiscous模式（ ifconfig vpn_br promisc ）时，我得到一个工作设置。 我不太确定这是否正常需要。 OTOH我不认为它有任何缺点…
顺便说一句，有一个类似的RedHat的错误报告存在，但设置bond0向下/向上不利于我的情况..
它没有粘合片吗？ 我怀疑这个问题是LACP信息没有通过桥梁，直到你把它放在混杂模式。
如果您使用的是3.5或更高版本的内核，那么也可能有助于为桥接接口启用IGMP查询的传输。 这可以帮助网桥订阅LACP组播组。
echo -n 1 > /sys/devices/virtual/net/vpn_br/bridge/multicast_querier