第一次完整的LVS数据旅行格式 首先我们定义一下IP报文的格式： 源MAC地址:目的MAC地址/源IP地址：目的IP地址 客户机需要发出一个IP报文(客户机MAC地址:目的MAC地址/客户机IP地址：
第一次完整的LVS数据旅行格式
首先我们定义一下IP报文的格式： 源MAC地址:目的MAC地址/源IP地址：目的IP地址
客户机需要发出一个IP报文(客户机MAC地址:目的MAC地址/客户机IP地址：VIP)，这里对于客户机MAC地址，客户机的操作系统本身是知道的，而客户机的IP地址，客户机的操作系统
也是知道的，VIP地址客户机的浏览器上有，现在不确定的是目标MAC地址，因此客户机的这个请求报文没法发出去，那该怎么办呢？
客户机就会先发一个广播报文，这报文的格式是这样的 客户机MAC地址:客户机IP地址/ ×××××：VIP地址
这个广播报文会发送给所有的局域网终端，意思是 ：我的MAC地址是这个，我的IP地址是这个，请问VIP地址是这个的机器，你的MAC地址是什么？
这个数据被广播到交换机上，交换机一看，马上会把"客户机MAC地址:客户机IP地址"记录在自己的缓存里面，记住，这一点很重要
我们希望这个数据被发送到Director上去，所以Director上应该正常配置这个VIP地址，以便响应这个ARP数据报文，因此在Director上配置这个VIP
现在Director上有VIP了，它会响应客户机的ARP请求，他响应客户的ARP请求：我的mac是这个，我是VIP
现在客户机可以发送报文(客户机MAC地址:Director的MAC地址/客户机IP地址：VIP),这个报文被直接发给了Director
第一步完成
Director收到报文之后，查看报文的目的IP地址，发现是发给它的，于是根据调度算法，选出一台realserver，假设是rs1，想把报文转发给rs1，于是director会怎么做呢？
director发送报文(director的MAC地址:目的MAC地址/客户机IP地址：VIP)，注意，这里所有的IP都没有变化，只是mac地址有变化。
在这里，遇到一个问题，目的MAC地址该填什么呢？
我们希望director把这个报文转发给rs1，因此，目的MAC地址应该是rs1的目的地址，但是，rs1的MAC地址不知道啊？怎么办呢？
director是知道rs1的真实ip地址的(当然知道啊，director一定要清楚自己集群里面都有哪些节点嘛)，所以director就发一个arp请求
director的MAC地址：VIP/*****:rs1的真实地址，这意思就是说，我的VIP地址是这个，我的MAC地址是这个，请问rs1真实地址是这个的机器，你的mac地址是什么？
这个数据被广播到交换机上，交换机一看，马上会把"director的MAC地址:VIP"记录在自己的缓存中。注意，现在交换机中的VIP地址对应的是director的MAC地址，这很重要
rs1早就配置好了真实地址，因此它会响应director的arp请求：我的mac是这个，我是rs1真实IP
现在director可以把数据转发给rs1了(director的MAC地址:rs1的MAC地址/客户机IP地址：VIP) 注意这里IP层地址都没有变化，只有MAC地址发生了变化
第二步完成了
rs1收到数据之后，它会判断是否处理这个数据报文。判据是什么呢？是报文的目的IP地址，如果该报文的目的IP地址是自己，它就会处理，否则不处理
我们知道，这个从director转发过来的数据的目的IP是VIP，但是rs1现在可没有VIP，因此rs1是不会处理这个数据报文的，那该怎么办呢？
办法就是给rs1配置一个VIP，那就应该在rs1的eth0上再配置一个VIP吗？(因为eth0上已经有一个真实IP了嘛)，好的，我们配一个试试看
配完之后，发现rs1上的VIP和director上的VIP发生IP地址冲突了(因为在第一步的客户机请求VIP的mac地址时，rs1和director都会响应这个arp请求)，这下完蛋了。
因此，VIP需要配置到rs1的lo接口上。那么，为什么设置到rs1的lo接口上就不会有问题呢？
首先，lo接口是个逻辑接口，这个接口根本不会收到arp请求，收不到arp请求也就不会发送arp响应，再说lo这种逻辑接口根本就不会有MAC地址，但是请注意，它可以收到IP数据报文
其次，在第一步中，客户机对VIP这个地址的MAC的ARP请求是会被广播给rs1的eth0接口的！此时eth0上有真实IP，没有VIP，lo接口上有VIP。在arp_ignore为0的情况下(这是默认情况)，
eth0网卡收到了对lo上的VIP的arp请求，eth0也是会响应的，它很热情，它会把lo的mac地址(其实就是自己的MAC地址响应出去)--------0对应的是“回应任何网络接口上对任何本地IP地址
的arp查询请求”，因此我们需要禁止eth0的这种热情的行为，使用arp_ignore = 1
1对应的是 “只回答目标IP地址是来访网络接口本地地址的arp查询请求”，也就是说，如果arp请求是询问eth0上的那个真实地址的mac，eth0才会响应(如果这个都不响应，director
就没法把报文转发给rs1了)，对于其他的对lo上的VIP的arp的请求，根本不响应。
通过“在lo上配置VIP，在eth0上arp_ignore = 1”这两种手段，解决了VIP冲突的问题
现在rs1解开数据包，发现目标地址是VIP，而自己配置了VIP地址，因此它会处理这个数据包。
处理完之后，它会把自己的响应数据返回给客户机，这个数据报文是这样的
rs1的eth0的mac地址：目标MAC地址/rs1的IP(这里是VIP)：客户机IP 注意这里IP层地址都没有变化，只有MAC地址发生了变化
对于rs1的eth0的mac地址，rs1操作系统自己是知道的，IP层的两个IP，也都是知道的，现在问题就是目标MAC地址，这个目标MAC地址应该填什么呢？
这个IP报文应该直接发给客户机，因此目标MAC地址应该是客户机的。但现在rs1并不知道客户机的MAC地址是什么，它该怎么办呢？
按照惯例，rs1应该发一个arp请求来获取客户机的MAC地址，下面的话很重要
这个arp请求里面包括了自己的ip地址和Mac地址，按照linux的默认设置，默认是将IP报文中的源IP地址作为arp请求中的源地址的。
我们可以看到IP报文中的源IP地址是VIP，因此arp请求报文的数据是这样的
eth0的MAC地址:VIP/ ×××××：客户机IP
这意思就是说：我的ip是VIP，我的mac地址是这个，我想问一下，客户机IP是这个的机器，你的mac是什么？
结果这个arp请求一发出去，交换机一看，咦，VIP对应的MAC地址好像有变化啊，我要更新MAC地址表--------完蛋了
那该怎么办？
当内网的机器要发送一个到外部的ip包，那么它就会请求路由器的Mac地址，发送一个arp请求，这个arp请求里面包括了自己的ip地址和Mac地址，
而linux默认是使用ip的源ip地址作为arp里面的源ip地址，而不是使用发送设备上面的，
如果设置 arp_announce 为2，则使用发送设备上的ip。
arp_announce = 0 在任意网络接口上的任何本地地址 (默认)
arp_announce = 2 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.
首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的
发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送
对查询目标使用最适当的本地地址，意味着对客户机IP这个查询目标使用最适当的本地地址，最适当的本地地址就是eth0上的地址啊。因为数据最后是从这个
接口发出去的，eth0上的本地地址当然是最适当的，这个地址是rs1的真实IP地址。
于是arp请求报文是这样样子的：eth0的MAC地址:rs1的eth0上的真实IP地址/ ×××××：客户机IP
这时候就不会发生VIP地址冲突了，客户机也会顺利的响应这个arp请求，rs1收到了arp响应之后，
就可以把IP响应数据返回给客户机了
一次完整的数据流程结束
