定义了一个策略组,策略组里面有多个策略,每个策略存在不同的出口路径和匹配规则。为了提高转发模块的处理性能,加速匹配过程,在配置阶段,我们创建了一个 BiHash 数据结构来存储所有规则。当进行匹配时,BiHash 库能够快速找到对应的规则,并返回一个组合结果,即策略组 ID 与策略索引。这种方法通过单次查询即可完成匹配,极大地提高了系统的响应速度和处理能力。
在阅读 VPP 原生 ABF 模块的实现时,发现其路由相关配置分为两部分:配置数据和转发 DPO 数据。在配置 ABF 策略时,会设置路由路径数据;而在接口绑定策略时,则通过反查路径配置数据来生成转发 DPO 数据。这种设计感觉不够友好。
建议在配置数据阶段就直接生成转发 DPO 数据。当接口绑定策略时,仅需启用 ABF 处理节点。这样做的好处是,策略数据的配置是线程安全的,而在接口绑定时则无需担心线程安全问题。
这一思路借鉴了 Flexiwan 公司开源项目中新增的 fwabf 插件实现方式。如果大家有更好的方案,欢迎在评论区留言交流。
下面介绍一下fwabf插件中定义路径标签功能,感觉实现挺有创意的。
flexiWAN 提供了一种强大的方式来组织网络和隧道,这便是路径标签(Path Labels)。通过路径标签,用户可以定义独特的底层网络功能,包括:
这在下面的例子中有说明。在下图中,绿色和蓝色标签代表两个独立的底层网络,每个标签可以代表一个ISP或任何逻辑上的底层网络。
每个物理WAN接口都可以通过分配一个或多个路径标签来关联到一个底层网络。虽然也可以不为接口分配任何路径标签,但是许多高级特性如路径选择是依赖于路径标签的。结合路径标签和路径选择功能,可以配置跨越互联网出口接口或特定隧道的流量路由。
路径标签有两种类型:
通过引入路径标签,隧道的功能得到了极大的增强。当创建隧道时,可以选择特定的或所有路径标签。例如,可以根据以下情况对接口进行标签化:
此外,即使没有路径标签,flexiWAN 也能在两个或多个设备之间建立隧道,但在使用路径标签时,用户可以对用于隧道的接口有更多的控制权。未分配路径标签的接口被视为未标记的底层网络的一部分。虽然可以在未标记的接口之间建立隧道,但不可能将带有路径标签的接口与未标记的接口组合在一起使用。
在未来的版本中,flexiWAN 计划进一步增强路径标签的功能,增加更多SD-WAN能力,如用于启用流量分类和过滤(三层/四层以及七层/应用层)的策略。用户将能够根据应用使用路径标签来进行路由、故障转移或负载均衡。
上图是添加一个路径标签,填写名称和描述,选择一种颜色,甚至可以添加您自己的颜色(用十六进制表示)。需要注意的是“直接互联网访问”选项,它允许将标签严格保留用于互联网出口。这意味着所有通过这个路径标签的流量都将使用互联网出口,而不会经过隧道。如果一个接口被分配了“直接互联网访问”路径标签,那么就不可能将此接口用于隧道。
下面是一个配置路径标签的例子,其中创建了路径标签以区分不同的ISP以及连接类型。
为了举一个现实世界的例子,假设有几个远程站点(商店)和一个数据中心站点。我们希望将每个远程站点连接到数据中心。按照下图所示创建路径标签。
在这个例子中,各个远程站点和数据中心站点都有两个WAN连接,每个连接到不同的ISP。在站点和数据中心之间创建隧道之后,隧道页面将显示6条隧道。
创建路径标签(Path Labels)后,将其分配给设备接口,以便将它们关联到底层网络(underlay network)。如下图所示,wan接口ens192和ens256分别绑定了ISP1和ISP2。
接下俩就是基于路径标签来创建隧道了。我们有两个 flexiEdge 设备,每个设备有两个 WAN 接口。在每个设备上,WAN1 分配了 ISP1 标签,而 WAN2 使用的是 ISP2。我们将在接下来的三个示例中使用这些设备。
使用特定路径标签创建隧道:选择一个特定的路径标签将为所有分配了所选标签的设备创建一个全网状隧道。在这种情况下,我们使用 ISP1 标签添加了一个隧道,而 ISP2 路径标签和接口未被使用。
将创建隧道抽象的东西,给具象化了,flexiwan公司基于vpp实现SDWAN产品还是蛮有意思的,fwabf插件后续就会使用路径标签来实现策略路由的功能。后续我们将继续研究其实现。
本文分享自 DPDK VPP源码分析 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!