linux的proxy_arp和arp_filter参数解释

proxy_arp和arp_filter用来控制是否对arp请求作出响应,在正常情况下,如果收到arp请求,且请求的ip地址为网卡自身的ip地址时都会回复。那么当ip地址不是网卡自身的ip地址时是否进行回复则取决于这两个参数的配置,使用网卡自身的mac地址回复。两个参数的官方文档解释如下: arp_filter 1 – 允许主机上拥有同一个子网的多个网卡,对于每个接口上收到的arp请求是否进行回复取决于当本机向发出arp请求的那个客户端的源ip发数据包时,这个数据包是否会从当前接收到请求的接口发出。如果是则回复,否则不回复。 0 – 本机有那个ip地址的话则会回复(其实是看路由,网卡配置ip地址后再local表里自动创建一条路由)。 proxy_arp 是否开启arp代理,开启arp代理的话则会以自己的mac地址回复arp请求,0为不开启,1则开启。 在开启了proxy_arp的情况下,如果请求中的ip地址不是本机网卡接口的地址:但是有该地址的路由,则会以自己的mac地址进行回复;如果没有该地址的路由,不回复。 如果开启了arp_filter,请求中的ip地址是本机接口的地址:如果且当我们向发起arp请求的客户端回复的包也通过当前网卡出去的话则进行回复;如果回包时不走当前网卡则不会进行回复。 下面通过一小段命令来测试,首先准备一个veth-pair和netns。 ip netns add test1 ip link add name veth0 type veth peer name host-veth0 ip link set host-veth0 up ip link set veth0 netns test1 ip netns exec test1 ip link set veth0 up ip netns exec test1 ip addr add 10.0.0.1 dev veth0 ip netns exec test1 ip route add default dev veth0 ip link add…

kubernetes网络 – cni与pod网络

pod网络 kubernetes中每个pod都拥有自己的ip地址,pod内的所有容器实例都共享同一个网络命名空间,因此容器实例之间可以通过localhost地址进行通信,并且他们都可以看到同样的ip地址和mac地址。 kubernetes对于pod的网络定制了下列三个要求,所有网络插件支持这几个要求即可: 所有节点上所有的pod可以互相通信,并且不依赖NAT 节点上的进程可以和该节点上的所有pod通信 运行在主机网络空间下的pod可以和所有节点上的所有pod互相通信,并且不依赖NAT 网络插件 cni代表容器网络接口,是CNCF社区下的一个项目,定义了一系列的接口格式,来规范容器的网络接口的配置。 kubernetes支持两种网络插件配置模式,分别为 cni kubenet kubenet 其中kubenet是一个非常简单的网络插件,并且只支持linux。本身不提供跨节点的网络通信以及网络策略功能。通常是要和云控制器结合起来去使用的。kubenet模式下,kubelet会创建一个叫做cbr0的网桥设备,并未每个pod创建一个veth-pair(虚拟接口对),一端在容器内,一端在容器外,在容器外的接口加入到这个网桥(二层)中。节点上所有的pod都通过主机上的接口连接到网桥,因此针对单个节点上的pod是可以互相通信的。 可以通过以下示例进行简单测试验证: echo 1 > /proc/sys/net/ipv4/conf/all/accept_local echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 1 > /proc/sys/net/ipv4/conf/default/accept_local echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables ip link add testbr type bridge ip link set testbr promisc on ip link set testbr up ip netns add test1 ip netns add test2 ip link add veth1 type veth peer br-veth1 ip link add…