bigsheng2的博客

支持nat-t的tunnel要么是标准的C/S模型，能够从墙内发起建立tunnel隧道，且有保活机制使防火墙上的ct持久生效。要么像IPSec一样，能够在协议层面支持，知道tunnel是经过nat的。linux gre 和 vxlan 作为常用的tunnel口是无法过nat的，但其性能和复杂度比ssl，ipsec这些能够过nat的tunnel要好很多。做了些gre/vxlan过nat的测试，做了些记录：GRE过nat如果网关设备为ovs，直接通过流表学习到nat过的gre头即可，如果网关设备为li

openflow流表的mac地址match项支持对mac地址做掩码，如同ip地址的掩码一般，就想着既然ip路由可以只使用一条路由表转发到网段内所有主机的报文，那么利用这个特性，二层也可以做到相同的效果，正好工作中也在用ovs做骨干测的转发，同时也存在流表的性能问题，就想着使用这种方法优化一下。工作业务上的细节不便描述，这里只简单描述一下思路，总体思路就是模仿ip网段和ip三层路由，将同一ovs设备背后的设备的mac地址配置为同一mac地址网段内且全网唯一的地址，从而利用ovs流表mac地址match项支持

接口限速功能测试的时候发现一个问题，使用iperf3打流总是打不满接口上配置的速率，而使用iperf却可以。而且在使用iperf3 的时候，我尝试过调大接口限速所使用的令牌桶的桶深，发现桶深达到一定程度的时候，流量可以达到接口速率。很容易让人想到突发流量导致丢包，从而导致无法打满接口速率。令牌桶算法的桶深就是为突发流量提供一个缓冲，以使限速可以更加平滑，一般至少大于接口MTU，一些厂家会提供一些计算方式，如juniper就有一段描述（https://www.juniper.net/documentatio

strongswan进程启动后只运行在一个net namespace中，后面ike协商出来的所有sa都只存在于一个namespace，对于一个多用户的系统，不同用户的网络可能有重叠，使用namespace做用户隔离是常用手段，对于ipsec，如果使用strongswan做ike协商就有如果使其支持namespace的问题。开始通过修改strongswan的源码使其支持namespace，原理也比较简单，主要使strongswan于内核通讯（下policy，state表项）的netlink支持namespa

Linux IP Tunnel有IPIP、Gre、Sit，使用虚拟网络中常用的overlay技术，一般需要直接配置local 和 remote address，但是在一些SDN的虚拟网络中常常会存在大量的对端，这就需要配置很多Tunnel口。管理起来比较麻烦。解决这个问题的一个办法，就是在配置IP Tunnel时，不指定remote address，而是在指向Tunnel口的路由中通过Nexthop指定remote address。这种tunnel在linux 内核代码的注解中叫NBMA Tunnel。

记录一段代码，从中可以很清晰的看出qemu-kvm的初始化以及虚拟机的运行过程。原文见参考资料链接，这里记录阅读过程中的一些批注和总结。#include <stdio.h>#include <stdlib.h>#include <fcntl.h>#include <inttypes.h>#include <pthread.h>#include <sys/mman.h>#include <linux/kvm.h>

传统的交换机设备都是支持VLAN隔离的，OpenvSwitch作为一个主流的虚拟交换机，自然也是支持VLAN相关的实现的。OVS交换机内部也可以通过VLAN ID来隔离交换机的各个端口。如果一个OVS交换机的端口设置了tag标签（该端口处于access模式），数据包从该端口进入到交换机内部时，该数据包就会被打上对应的tag，于是该数据包也就只能从设置了相同tag的端口发出，而在出交换机的时候，数据包上的tag会被删除。这样就实现了交换机内部的一个隔离。但是流表就像三体中的归零者一样，可以打破物理定律，在

IPSec协议帮助IP层建立安全可信的数据包传输通道。当前已经如strongswan、openswan等比较成熟稳定的开源项目做协议层的控制。但他们最终都是使用的内核的XFRM框架做报文的封装发送和接收解封，只不过内核的转发表项数据是由他们生成的。XFRM，是transfrom的简写。######IPSec收包解封流程流程路径：ip_rcv() --> ip_rcv_finish() --> ip_local_deliver() --> ip_local_deliver_fini

本文记录一下vxlan接口内核收发包处理。VXLAN(Virtual Extensible LAN, 虚拟局域网扩展)是一种网络虚拟化技术，一种大二层隧道技术，将二层包封装在UDP中来构建虚拟的二层网络。设备厂商特别是大厂vxlan的配置和应用场景要丰富和复杂的多，linux上相对简单，在一些SDN网络，如云计算和容器的一些虚拟化网络中经常用到，还有vxlan上相关的一些支持的特性，如arp proxy、l2miss、l3miss、router等还是比较有意思的。#####先介绍一下几个重要的数据结构

macvlan是linux的一种虚拟网络接口，macvlan 允许你在主机的一个网络接口上配置多个虚拟的网络接口，这些网络 interface 有自己独立的 mac 地址，也可以配置上 ip 地址进行通信。macvlan 下的虚拟机或者容器网络和主机在同一个网段中，共享同一个广播域。macvlan 和 bridge 比较相似，但因为它省去了 bridge 的存在，所以配置和调试起来比较简单，而且效率也相对高。除此之外，macvlan 自身也完美支持 VLAN。macvlan 虚拟网卡设备包括5种模式：

本来想将macvlan和ipvlan放一起写，但是在测试过程中发现，ipvlan使用起来还是挺复杂的，于是单独作为一章来写。ipvlan 和 macvlan 类似，都是从一个主机接口虚拟出多个虚拟网络接口。一个重要的区别就是所有的虚拟接口都有相同的 macv 地址，而拥有不同的 ip 地址。ipvlan 有两种不同的模式：L2 和 L3。一个父接口只能选择一种模式，依附于它的所有虚拟接口都运行在这个模式下，不能混用模式。L2 模式和 macvlan bridge 模式工作原理很相似，父接口作为交换机来

ovs，全名openvswitch，是一个高质量的、多层虚拟交换机，相对于bridge的一些优势：1）方便网络管理与监控。OVS 的引入，可以方便管理员对整套云环境中的网络状态和数据流量进行监控，比如可以分析网络中流淌的数据包是来自哪个 VM、哪个 OS 及哪个用户，这些都可以借助 OVS 提供的工具来达到。2）加速数据包的寻路与转发。相比 Bridge 单纯的基于 MAC 地址学习的转发规则，OVS 引入流缓存的机制，可以加快数据包的转发效率。3）基于 SDN 控制面与数据面分离的思想。上面两点其实

bridge 是linux上的虚拟交换机，具有交换机的功能。网卡收到包后，走到__netif_receive_skb_core后，剥完vlan找到vlan子接口（如果有的话），如果skb->dev是bridge成员口，就会走到bridge成员口的接收处理函数。static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc){...... /* bridge、ovs的接口，都会走到。 如果一个dev被添加到一

邻居，可以简单理解为三层上的一跳距离。路由的下一跳可以不是直连的一跳距离（迭代路由），但最终走到邻居子系统的时候就是一跳距离。linux 迭代路由的用法： https://www.jianshu.com/p/070202b6d3ca邻居子系统，提供三层地址到二层地址之间的映射，提供二层首部缓存加速二层头的封装，提供二层报文头的封装。如下，邻居表信息，表达了IP地址是x.x.x.x的下一跳，它的mac地址是xx:xx:xx:xx:xx:xx，通过出接口ethx能够到达。#ip neigh172.16

Linux 内核中的 ct 系统，本身从不改变/操纵数据包。通常也不会丢弃数据包，只可能在极少数情况下发生这种情况。ct更多的是为其他内核组件提供决策。如 NAT 子系统以及Iptables和Nftables 的状态包过滤模块。连接跟踪最重要的使用场景就是 NAT，NAT 依赖连接跟踪的结果。所以，即使存在established 状态的 ct，数据包还是会经过各个hook点，各个内核组件，还是会查找路由表、neighbor表等。如下，nat流程中，nf_nat_packet 调用 nf_nat_man

注： 内核代码是 4.9 版本协议栈从报文接收说起，报文接收从网卡驱动说起。两种方式，NAPI 和 非NAPI。NAPI(New API) 是Linux内核针对网络数据传输做出的一个优化措施。其目的是在大量数据传输时， 在收到硬件中断后，通过poll方式将传输过来的数据包统一处理， 通过禁止网络设备中断以减少硬件中断数量((Interrupt Mitigation)，从而实现更高的数据传输。其中要点：1、硬件中断后开始处理报文。中断处理函数只是触发软中断准备接收报文；2、软中断中通过pool

Linux 的迭代路由的支持不像传统路由器那么好，用法比较特别。如果这么配置，会提示网络不可达。#ip addr1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0025: veth1@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu

ipvlan 三种模式，l2、l3、l3s，前两种网上资料很多，但第三种却很少，自己看了下代码记录一下。为什么要看ipvlan？它特别适合做多租户nat场景，这种场景下，用户的内网VPC地址网段可能是重叠的，需要使用net namespace、vrf等手段隔离路由，但通常公网网卡和公网网关就一个，且网关地址和用户公网地址通常不是一个网段的，也就是说不能放到一个二层中。但使用ipvlan l3 mode可以解决这个问题。到此为止，有时间写一下用法，继续l3s mode。附英文注释：4.1 L2 mode

##物理口###client端设置：######1、sysctl 修改内核参数，使能接口ipv6，是能全局ipv6转发，使能接口 accept_ra。# 是能接口ipv6，默认 disablenet.ipv6.conf.eth2.disable_ipv6 = 0# 允许接口接受ra报文，Obtain IPv6 address on wan interface by Stateless autoconfiguration (SLAAC)net.ipv6.conf.all.forwarding =

linux网络虚拟化经常会用到network namespace，将一些创建完成的虚拟接口加入到另一个namespace实现网络隔离。既然接口已经属于另一个namespace，为什么报文仍然能够在创建接口的ns和切换后的ns之间收发呢？这是因为接口无论怎么切换netns都会在创建接口所在的netns中留下一些痕迹，将创建接口所在netns和接口关联起来。拿最简单的ip gre口举例。ip gre接口是一个三层的ip tunnel接口，外层dst ip通常是本地物理口的ip地址，即协议认为报文是送往本机