基于Linux内核新特性的网关设计实践

通过对上述三项新技术的研究，我们发现可以尝试设计一套基于路由的方式，实现多租户层叠网络的外网网关。在方案设计过程中，我们也碰到了诸如 lwtunnel 和流卸载功能不足，以及 VRF 和流卸载不能一起有效的工作等问题。最终我们都设法解决了，并针对这些内核的不足提交补丁给 Linux 内核社区。

1、lwtunnel 发送报文 tunnel_key 丢失

问题描述：我们利用 lwtunnel 路由方式发送报文时，创建了一个 external 类型的 gretap 隧道，我们将命令设置了 id 为 1000，但是发送成功报文中没有 tunnel_key 字段。

# ip l add dev tun type gretap
# ifconfig tun 1.1.1.7/24 up
# ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1

问题定位：我们研究 iproute2 代码，发现由于 TUNNEL_KEY 的标志并没有开放给用户态，所以 iproute2 工具并没有对 lwtunnel 路由设置 TUNNEL_KEY，导致报文不会创建 tunnel_key 字段。

提交补丁：我们给内核和用户态 iproute2 分别提交补丁来解决这一问题：

• iptunnel: make TUNNEL_FLAGS available in uapi
• iproute: Set ip/ip6 lwtunnel flags

提交补丁后，可以通过以下方式设置路由：

ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

2、lwtunnel 对指定密钥的 IP 隧道无效

问题发现：为了能有效隔离租户路由，我们给每个租户创建一个基于 tunnel_key 的 gretap 隧道设备。如下图，创建一个 tunnel_key 1000 的 gretap 隧道设备，把隧道设备加入租户所属 VRF，隧道设备能有效地接收报文，但并不能发送报文。

# ip l add dev tun type gretap key 1000
# ifconfig tun 1.1.1.7/24 up
# ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

问题定位：研究内核发现，IP 隧道在非外部模式下即使指定了轻量级隧道路由，发送报文也没有使用它，导致报文路由错误被丢弃。

提交补丁：

• ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel

提交补丁后，在未指定 tunnel_dst 的非外部模式 IP 隧道下，，能使用轻量级隧道路由进行发送报文。

3、外部 IP 隧道 ARP 无法正常运行

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!