网卡绑定mode0和6的区别

CentOS双网绑定有7种模式（即mode=0,1,2,3,4,5,6）：0（balance-rr模式）网卡的负载均衡模式。
特点：(1)所有链路均处于负载均衡状态，消息以数据方式和分组方式发送到各链路。
在文化中Ping相同的地址：1.1.1.1两个网卡都有重复的网络流量。
负载施加到两条链路上，表明轮询是以分组方式进行的。
(2)该模式的特点是增加带宽并支持容错。
当出现连接问题时，流量将被重定向到正常连接。
1（active-back模式）是一种容错能力更强的网络模式。
特点：一个端口处于主状态，一个端口处于从状态，所有流量都在主连接上处理，永远不会有任何流量。
当主人进入港口时，奴隶就占有了主人的港口城市。
2（libra-xor模式）需要switch支持。
特点：此模式将限制流量始终从同一设备到达特定对等点。
由于目的地是由MAC地址确定的，因此该方法在“本地”网络上运行良好。
如果所有流量都经过单一路径（例如“网关”网络配置，只有一个网关，源和目标mac是固定的，则该算法计算出的线路将始终相同，则该模型不适用）很有道理）这种方法不是最好的选择与balance-rr一样，传输端口必须配置为“portchannel”。
此方法使用源MAC和目标MAC的因子对选定的路由执行异或算法。

centos双网卡绑定mode哪种好些

CentOS双网卡绑定有7种模式（即mode=0,1,2,3,4,5,6）：0（balance-rr-mode）是网卡的负载均衡模式。
特点：(1)所有链路均处于负载均衡状态，消息以轮询方式、按包方式发送到各链路。
在服务上Ping同一个地址：1.1.1.1双网卡的两个网卡都有流量发出去。
负载施加到两条链路上，表明轮询是基于perpacket方法进行的。
(2)该模式的特点是增加带宽、支持容错。
当链路出现问题时，流量将切换到正常链路。
1（主动备份模式）网卡容错模式。
特点：一个端口处于主状态，一个端口处于从状态，所有流量都在主链路上处理，永远不会有任何流量。
当主端口down时，从端口接管主端口状态。
2（平衡异或模式）需要交换机支持。
特点：此模式将限制流量，以确保到达特定对等点的流量始终从同一接口发送。
由于目的地是由MAC地址确定的，因此该模式在“本地”网络配置中运行良好。
如果所有流量都经过单个路由器（例如“网关”网络配置，当只有一个网关时，源和目标mac是固定的，那么通过该算法计算出的路由将始终相同，因此该模型没有多大意义），那么这种模式就不是最好的选择。
与balance-rr一样，交换机端口必须配置为“portchannel”。
该模式利用源MAC和目的MAC的哈希因子进行异或算法来选择路由。
3（广播模式）。
特点：该模式的特点是绑定时会向两个接口分别发送两份消息。
这种方法的模式具有良好的容错性。
这种模式适合金融行业，因为它们需要高度可靠的网络，不允许出现问题。
4（IEEE802.3ad动态链路聚合模式）需要交换机支持。
特点：802.3ad模式是IEEE标准，允许所有实施802.3ad的对等方良好地协同工作。
802.3ad协议包括聚合的自动配置，因此只需很少的交换机手动配置（需要注意的是，只有某些设备可以使用802.3ad）。
802.3ad标准还要求帧按顺序传送（在某种程度上），因此单个连接通常不会看到乱序的数据包。
802.3ad也有一些缺点：该标准要求所有设备在聚合时以相同的速度和双工模式运行，并且与除balance-rr模式之外的其他bond负载平衡模式一样，任何连接都不能使用多个接口带宽。
此外，linuxbonding的802.3ad实现通过对等点分配流量（通过MAC地址的XOR值），因此在“网关”配置中，所有传出流量将使用同一设备。
传入流量也可能在同一设备上终止，具体取决于对等802.3ad实施的平衡策略。
在“本地”配置中，路径将分布在绑定中的整个设备中。
5传输的自适应负载平衡模式。
特点：balance-tlb模式通过peer平衡传出流量。
由于它基于MAC地址进行平衡，因此在“网关”配置（如上所述）中，此模式将通过单个设备发送所有流量，但在“本地”类型的网络配置中，此模式将相对智能。
方法（不是802.3ad模式中提到的balance-xor或XOR方法）来平衡多个本地网络对等体，以便那些数字不吉利（例如XOR得到相同值）的MAC地址不会在同一接口上收集。
与802.3ad不同，可以该模式下的接口具有不同的速度，并且不需要特殊的交换机配置。
缺点是此模式下的所有传入流量都会流向同一接口。
6.网卡虚拟化方法。
特点：该模式包括balance-tlb模式，加上IPV4流量的接收负载平衡（rlb），并且不需要交换机支持（switch）。
接收负载均衡这是通过ARP协商来实现的。
Bonding驱动程序拦截本机发送的ARP回复，并将源硬件地址重写为bond中从机的唯一硬件地址，以便不同的对等体使用不同的硬件地址进行通信。
所有端口都会收到对端的arp请求报文，并会发送arp应答报文。
源mac改为对应端口mac。
从抓包分析，响应报文是第一个从端口1发出的，第二个是从端口2发出的。
以此类推。
具体选择取决于您自己的需求和交换机的情况，一般情况下Mode=0和Mode=1比较常见，两种网卡都工作。

一次UDP收不到包的问题排查

昨天接到同事电话，让我帮忙排查一个无法抓到UDP数据包的问题，​​他描述的问题是主机A通过UDP协议向主机B的10001端口发送了一条syslog消息，结果我们的Flume采集程序无法接收数据；然而，主机C也向主机B的10002端口发送syslog消息，但同一个flume收集程序可以照常接收消息。
双主机网卡B为：IP42，网口为eth0，网口为eth1；B对外使用的IP是134网段的IP，主机A和主机C都使用134网段的IP地址向主机B发送消息，示意图如下：我的第一反应是：是防火墙问题。
登录主机后，由于是centos7版本，所以使用showfirewallstatus命令检查防火墙是否关闭。
继续分析，然后考虑是否是防火墙问题，于是在接收主机B上使用tcpdump抓包，命令如下：发现数据包没问题，然后加上-vv选项，可以看到解析出来的信息，其中正确的就是我们要发送的消息，说明中间网络没有问题。
nc可以说是一款网络测试神器，它可以轻松创建监听端口并作为服务器工作，也可以作为客户端测试服务器。
具体测试步骤如下：1、停止B上的flume监听程序，然后在主机B上运行命令：结果：没有收到消息！！！我有点惊讶，我能抓到包，但是防火墙也关了，为什么收不到？如果不确定，继续使用nc，并在主机B上随机启动10009端口：使用nc命令连接并在服务器A上测试：输入消息进行测试，但仍然收不到消息。
2查看系统日志，没有报错。
进入深思……无论如何，我们都不能放弃。
我们打电话给主人，让主人说重新启动防火墙。
于是第二天一早我给同事打电话，重启防火墙，却发现错误依然存在。
接下来查看Flume启动的监听端口状态：监听IP配置为0.0.0.0，端口绑定10001，没问题。
虽然主机B有两个网卡和两个IP，但是我们监控所有的IP，要小心，我们将IP配置为抓包捕获的IP42，但是错误还是一样。
继续在主机B上抓包，发现主机A的IP是10网段，主机C的IP是134网段。
这说明源IP网段可能因为网段问题而不同？一次偶然的机会，我使用route-n查看路由信息，发现10网段的目标IP使用的是eth1网口，但是eth1网口配置的IP是72ip，与A发送给A的目标IP不一样B.A发送给B的目标IP是IP34。
我们来解决一下UDP数据包流程：一个UDP数据包从主机B（IP：10.x.x.x）发送到主机A的134.x.x.x。
UDP报文经过中间NAT转换后，目标IP变为x.x.x.42，通过网络端口eth0进入主机B，当主机B访问10.x.x.x时，根据已有的路由配置，从网络端口eth1退出，如果有一个返回数据包，则接收数据包的网络端口eth0和返回数据包的网络端口eth1是。
不是网卡相同的！我总觉得有些不对劲。
我手动删除了旧的10.x.x.x路由并添加了新路由。
通过eth0的新路由也接受它，问题解决了。
但我无法弄清楚从逻辑上讲，UDP消息不会受到目录路由的影响如果有人知道这一点，请告诉我。