arp代答观察

代答和代理简述

ARP（地址解析协议）是在局域网中用于将IP地址映射到MAC地址的协议。在理解 ARP 代答和 ARP 代理之前，让我们先澄清一下 ARP 的基本工作原理。

• ARP 代答（ARP Reply）：ARP 代答是指设备在收到 ARP 请求后向请求者发送的响应。当一个设备需要将 IP 地址解析为 MAC 地址时，它会在局域网上广播 ARP 请求，请求与目标 IP 地址对应的 MAC 地址。目标设备收到请求后，如果拥有对应的 IP 地址，会发送 ARP 代答，将自己的 MAC 地址发送给请求者，从而建立 IP 到 MAC 的映射关系。

• ARP 代理（ARP Proxy）：ARP 代理是指网络设备（通常是路由器或者交换机）在局域网内代表其他设备响应 ARP 请求。当一个设备无法直接解析某个IP地址的MAC地址时，它会向本地网络内的所有设备发送ARP请求。在某些情况下，网络设备可以充当 ARP 代理，接收到 ARP 请求后代替目标设备进行回应。这样可以在某些网络拓扑结构下提供更高效的 ARP 解析服务。

因此，ARP 代答和 ARP 代理的区别在于：

• ARP 代答是指设备直接响应 ARP 请求，提供自己的 MAC 地址（具体请看文末的总结）。
• ARP 代理是指网络设备代表其他设备响应 ARP 请求，帮助解析 IP 地址和 MAC 地址之间的映射关系。

实验前提

用namespace模拟vtep下挂的虚拟机，同时又尽可能模拟我们已有的环境中的配置

项目代码中arp代答部分的配置如下

  cmd = "ip link add %s mtu %s type vxlan id %s proxy %s %s %s" % \
          (tun_name, vxlan_mtu, tun_key, _nolearning, _l2miss, _l3miss)

以上配置中的proxy即为arp代答的配置。
注：arp代答和arp代理是不一样的两个东西勿混淆。

先不开启proxy代答的配置

1. 准备对应的namespace和bridge等

   root@i-l185a7rl:~# cat test.sh
   #!/bin/bash
   sysctl -w net.ipv4.ip_forward=1
   ip netns add ns1
   ip link add veth1 type veth peer name eth0 netns ns1
   ip netns exec ns1 ip link set eth0 up
   ip netns exec ns1 ip link set lo up
   ip netns exec ns1 ip addr add 3.3.3.3/24 dev eth0
   ip link set up dev veth1
   ip link add br1 type bridge
   ip link set br1 up
   ip link set veth1 master br1
   ip link add vxlan100 type vxlan id 100
   ip link set vxlan100 master br1
   ip link set up vxlan100
   

   #!/bin/bash
   sysctl -w net.ipv4.ip_forward=1
   ip netns add ns1
   ip link add veth1 type veth peer name eth0 netns ns1
   ip netns exec ns1 ip link set eth0 up
   ip netns exec ns1 ip link set lo up
   ip netns exec ns1 ip addr add 3.3.3.4/24 dev eth0
   ip link set up dev veth1
   ip link add br1 type bridge
   ip link set br1 up
   ip link set veth1 master br1
   ip link add vxlan100 type vxlan id 100
   ip link set vxlan100 master br1
   ip link set up vxlan100
   

   左边为host1，右边为host2
   
   这个时候在3.3.3.3上ping3.3.3.4，肯定ping不通
   
   原因在于，Host1的3.3.3.3接口需要先发送ARP广播包查询3.3.3.4的MAC地址。ARP广播包到达接口vxlan100之后，根据FDB表项无法找到VTEP地址,因而ARP广播包无法发出。

   然后在Host1上手动增加VXLAN FDB表项:

   bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.100.2
   bridge fdb append 2a:e7:fc:de:91:f7 dev vxlan100 dst 192.168.100.2
   

   然后在Host2手动增加VXLAN FDB表项:

   bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.100.3
   bridge fdb append ea:ec:1b:c8:cb:07 dev vxlan100 dst 192.168.100.3
   

   
   可以看到arp广播泛洪的流量到达了host2上的vtep口，这个时候没有开启代答，符合预期的。

开启代答

配置如下
host1调整如下

root@i-l185a7rl:~# cat test_arp.sh
#!/bin/bash
ip link del vxlan100
ip link add vxlan100 type vxlan id 100 proxy
ip link set vxlan100 master br1
ip link set up vxlan100
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.100.2
bridge fdb append 2a:e7:fc:de:91:f7 dev vxlan100 dst 192.168.100.2

host2调整如下

!/bin/bash
ip link del vxlan100
ip link add vxlan100 type vxlan id 100 proxy
ip link set vxlan100 master br1
ip link set up vxlan100
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.100.3
bridge fdb append ea:ec:1b:c8:cb:07 dev vxlan100 dst 192.168.100.3

图中的proxy即为新增的代答参数

先删除之前没有开启arp代答的时候，产生是arp条目

再来ping，可以看到开启代答后，只有本地的vtep才会收到arp广播包了，host2上的vtep已经没有收到广播包了。并且这个时候是ping不通3.3.3.4的

为啥ping不通3.3.3.4呢，因为host1上的vtep上没有3.3.3.4的条目

手动将3.3.3.4的arp信息加入到host1上的vtep上

ip neighbor add 3.3.3.4 lladdr 2a:e7:fc:de:91:f7 dev vxlan100
ip netns exec ns1 ip neigh delete 3.3.3.4 dev eth0
ip netns exec ns1 ip neigh flush all

host2

ip neighbor add 3.3.3.3 lladdr ea:ec:1b:c8:cb:07 dev vxlan100

再次ping可以看到arp泛洪广播，只停留在了本地vtep

总结

可以看到proxy用来让vtep代答。代答的主要目的是减少泛洪流量，将泛洪范围控制在本地vtep口，如果不用proxy，则需要将流量泛洪到所有相关的vtep口。但是要提前把将对应的arp配置到vtep上，这个动作可以用我们其它的辅助程序完成