AF透明双机模式注意事项

场景：双机主主聚合虚拟网线模式

AF双主部署在上下链路聚合环境，会存在数据从AF-1发出请求，走AF-2收到回包，导致来回数据包在AF上的连接跟踪不一致而被AF丢包。通过配置双机聚合可让两台AF设备在数据传输时同步两边流量数据，避免出现数据来回路径不一致从而影响正常业务传输。

原理：

利用报文的三元组（源目的IP, 协议号）计算哈希值，该哈希值对应唯一的AF设备（0， 1），将报文发送到该AF设备上处

理。处理完成后，根据traffic开关判断是否需要反送回原收包设备发送。

注意事项：

1、数据同步口和心跳口的速率选择一定要大于等于业务口

如果业务口选择万兆，同步口和心跳口选择了千兆口，即使当时没有异常那么后期业务流量增大后一定会出现网络丢包异常的情况。（心跳口作为数据口的备用所以也选择大速率口）

原因：同开开头提到的原理

2、HA Traffic 功能在上下是三层接口的环境下要打开，上下是纯二层环境不用打开。

原因: 二层口不校验目MAC，三层口会校验目MAC。

如上图所示， AF1和AF2主主透明部署，上下游设备为二层交换机，为避免二层环路，上下游交换机分别配置eth1和eth2为聚合

口。因聚合口造成了非对称流量，所以配置业务口为虚拟网线口，每台AF的eth2和eth3为一组虚拟网线，开启双机聚合功能。存

在TCP报文流量走向如下：

TCP请求报文从LSW1的eth1口发送到AF1设备eth2口，此时报文的源MAC是AR1的eth0口MAC, 目的MAC是AR2的eth0口

MAC；

AF1设备使用自己的心跳口IP和报文的三元组计算哈希值，得出结果1，代表需要发送到对端设备处理；

AF1封装报文，通过数据口将报文发送到AF2；

AF2接收报文后，按照从自己的业务口收包处理，走正常处理流程；

AF2设备使用自己的心跳口IP和报文的三元组计算哈希值，得出结果0，代表本端处理，继续走之后的处理流程；

AF2处理完成后，指定发包口eth3, 走发包流程，从eth3口发包；

LSW2的eth2收包，因为是二层口，所以并不校验目的MAC，所以报文可正常转发；

综上，保证了一条流只在一台设备上处理，同时流量可通， 所以该场景无需打开Traffic功能；

3、双机聚合后性能不等于“1+1”

原因：同开头提到的原理

4、心跳口和数据口开巨帧

忽略最后一张图，，，，，最后一张图我删掉了怎么还在，重新编辑也删不掉。。。。