ON THIS PAGE
使用基于 cRPD 的路由服务器
本章介绍使用 cRPD 实例或实例作为路由服务器的一些特殊配置注意事项。
在下面的示例中,我们将使用以下属性:
Docker 桥接 IP 子网为 198.51.100.0/24
IXP LAN 子网 192.0.2.0/24
已在 IXP LAN 上为路由器服务器分配了 192.0.2.254 IP 地址
IXP BGP AS 100
此部署的特殊注意事项示例:
由于 EBGP 客户端与 IXP LAN 处于不同的 IP 子网上,因此 EBGP 会话必须为多级跳。这是因为容器在 Docker 桥接子网上运行。
’使用 cRPD 时,您不会配置接口。接口地址从 Docker 容器中读取。
路由服务器本地地址示例:
root@rs0> show interfaces routing Interface State Addresses eth0.0 Up MPLS enabled ISO enabled INET 198.51.100.2 lo.0 Up MPLS enabled ISO enabled INET 127.0.0.1
CRPD 路由-服务器配置示例:
IXP 客户端-路由器配置:
应注意的是,本示例’没有涵盖应在实时网络中与运营路由服务器在客户端路由器对等方上配置的所有内容。可在以下部分找到在运行 Junos OS 参与 IXP 操作的客户端设备上应配置的内容的一个很好示例:https://www.ams-ix.net/ams/documentation/config-guide.
数据和控制平面同步
IXP Lan 具有挑战性的问题,即路由服务器在 IXP 成员客户端之间的数据平面中不处于活动状态,’因此,在客户端之间的数据平面在路由服务器上的 EBGP 会话保持开启的情况下可能会停机。您可以想象,这会创建一个 blackhole – 3 层认为目的地可到达,因此客户端在第 2 “层电路”关闭时发送信息流。
在 IETF 中完成工作,以利用 BFD (https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/)解决此问题。
上述拔模状态的摘要:
使用 BGP 路由服务器时,数据平面不与控制平面配合。因此,Internet 交换的对等方可能会丢失数据连接,而不了解其控制平面,并且数据包将丢失。本文档建议使用新定义 BGP 后续地址族标识符(SAFI),以允许路由服务器请求其客户端使用 BFD 跟踪到其对等方’地址的数据平面连接,并让客户端将连接状态发送回路由服务器。
在撰写本书时,目前尚无此草稿的可用或可互操作的实施。HealthBot 的外部应用程序可以发现并缓解此问题,这是 IETF 草稿中建议的本机 BGP 扩展的替代方法。
HealthBot 解决方案
HealthBot 解决方案首先通过关联多个数据块来检测条件。HealthBot 收集和/或接收以下数据:
从路由服务器 EBGP 下一个跃点
EVPN MAC 路由(从路由收集器)
数据平面 OAM PE 路由器之间的统计信息
要纠正此事件,这不是简单的,HealthBot 执行以下操作,如Figure 2中所示:
仅在受修改实例导入策略影响的路由服务器客户端之间限制路由分配。
现在,’让我们来探索工作示例;考虑中Figure 3的示例拓扑。
第一 HealthBot 订阅 BGP 遥测传感器,并从路由服务器(vRR)和路由收集器收集数据。在此示例中,路由服务器也充当路由收集器。此外,HealthBot 还会订阅 MPLS iAgent 传感器,并从 PE 路由器 R1、R6 和 R7 中收集标签交换路径(LSP)统计信息。
查找每个路由服务器客户端 CLI 的路由实例名称示例:
regress@RS1> show route instance summary | match C Instance Type Primary RIB Active/holddown/hidden C1 non-forwarding C1.inet.0 93/0/0 C2 non-forwarding C2.inet.0 62/0/0 C3 non-forwarding C3.inet.0 62/0/0
查找 IXP 客户端路由器 IP 地址(BGP 下一跳跃)示例:
请参阅Figure 4以确保 PE 路由器之间的数据平面保持不变,HealthBot 将监控所有 IXP pe 路由器之间的 RSVP-TE lsp 状态:
regress@R6> show mpls lsp | match Up Ingress LSP: 2 sessions To From State RtP ActivePath LSPname 192.0.2.1 192.0.2.6 Up 0 * to-r1 192.0.2.2 192.0.2.6 Up 0 * to-r2 regress@R7> show mpls lsp | match Up Ingress LSP: 2 sessions To From State RtP ActivePath LSPname 192.0.2.1 192.0.2.7 Up 0 * to-r1 192.0.2.6 192.0.2.7 Up 0 * to-r6 regress@R1> show mpls lsp | match Up Ingress LSP: 2 sessions To From State RtP ActivePath LSPname 192.0.2.6 192.0.2.1 Up 0 * to-r6 192.0.2.7 192.0.2.1 Up 0 * to-r7
在正常运行期间,将根据基于社区的输出策略在 IXP 成员之间交换路由。在这里,我们可以看到 C1 正在从 C2 (198.51.100.0/24)和 C3 (203.0.113.0/24)接收路由,分别是:
regress@C1> show route protocol bgp 198.51.100.1 inet.0: 96 destinations, 96 routes (95 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 198.51.100.0/24 *[BGP/170] 2d 23:20:23, localpref100, from 192.0.2.254 AS path: 2 I, validation-state: unverified > to 192.0.2.2 via ge-0/0/1.0 regress@C1> show route protocol bgp 203.0.113.0 inet.0: 96 destinations, 96 routes (95 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 203.0.113.0/24 *[BGP/170] 3d 00:46:29, localpref100, from 192.0.2.254 AS path: 3 I, validation-state: unverified > to 192.0.2.3 via ge-0/0/1.0
但是,如果某个 RSVP-TE Lsp 由于某种原因导致数据平面在 R1 和 R6 之间中断,但路由服务器仍从连接到这些 PE 路由器的 IXP 成员接收路由,则是怎样的?
关闭 LSP .。。
regress@R6# run show mpls lsp Ingress LSP: 3 sessions To From State RtP ActivePath LSPname 192.0.2.1 0.0.0.0 Dn 0 - to-r1 192.0.2.7 192.0.2.6 Up 0 * to-r7 Total 3 displayed, Up 1, Down 2
但 .。。
regress@C1> show route protocol bgp 198.51.100.1 inet.0: 96 destinations, 96 routes (95 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 198.51.100.0/24 *[BGP/170] 2d 23:20:23, localpref100, from 192.0.2.254 AS path: 2 I, validation-state: unverified > to 192.0.2.2 via ge-0/0/1.0 regress@C1> show route protocol bgp 203.0.113.0 inet.0: 96 destinations, 96 routes (95 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 203.0.113.0/24 *[BGP/170] 3d 00:46:29, localpref100, from 192.0.2.254 AS path: 3 I, validation-state: unverified > to 192.0.2.3 via ge-0/0/1.0
HealthBot 将发现这种情况,显示仪表板报警,并修改路由服务器策略配置,以限制受影响的 IXP 成员路由器之间的路由分配。
修改后的路由服务器配置:
IXP 成员路由器 C1 上的验证。您可以看到,从成员 C2 中不再接收路由:
regress@C1> show route protocol bgp 198.51.100.1 egress@C1> show route protocol bgp 203.0.113.0 iet.0: 68 destinations, 68 routes (67 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 203.0.113.0/24 *[BGP/170] 3d 01:10:07, localpref100, from 192.0.2.254 AS path: 3 I, validation-state: unverified > to 192.0.2.3 via ge-0/0/1.0
数据平面恢复后,HealthBot 将清除报警并恢复策略配置。
动态和自动化最大接受前缀解决方案
如前所述, Internet Exchange Point Overview一章中的安全注意事项部分,确定、监控和维护每个路由服务器最大前缀对于 IXP’的路由服务器部署而言可能有些困难。提供了几种解决方案,包括用于确定价值的各种乘法系数。HealthBot 网络提供另一种解决方案,包括从路由服务器提取实时流遥测、根据路由服务器客户端接受的前缀计数以及在 vales 更改时动态修改路由服务器策略。中Figure 7描述了两个路由服务器客户端的此工作流。
让’我们来看一个真实示例。在下面的 CLI 输出中,您可以看到路由服务器客户端 C1。路由服务器正在接收并接受来自客户端 C1 的10个前缀。您还可以看到路由服务器配置为最多接受来自客户端 C1 的15个前缀:
root@rs> show bgp summary | match “Peer |C1.inet.0” Peer AS InPkt OutPkt OutQ Flaps Last Up/DwState|#Active/ Received/Accepted/Damped... C1.inet.0: 10/10/10/0
另请注意 HealthBot 仪表板;客户端 C1 在Figure 8下面选择,我们可以看到,对于最后的统计时间间隔,HealthBot 确定的最大前缀策略没有变化。这由客户端表中‘的’绿色状态和消息表示。什么是统计间隔,您可能会问什么?在此 HealthBot 解决方案中,我们应用了一个非常简单的用户定义的时间间隔,用于收集每个路由服务器客户端的接受前缀数。在每个统计信息间隔后,HealthBot 将接受前缀的当前值,将其与1.5 相乘,也可由用户配置,并用新值更新路由服务器客户端策略。
现在,让’我们的客户端 C1 向路由服务器通告几个路由,再将两个静态路由添加到’C1 s BGP 导出策略:
我们可以在下面的输出中看到路由服务器收到并接受附加前缀:
root@rs> show bgp summary | match “Peer |C1.inet.0” Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/ Received/Accepted/Damped... r1001.inet.0: 12/12/12/0
但现在请查看 HealthBot 仪表板。客户端 C1 的图标已变为红色。这是因为接受的前缀数超过了90% 的阈值,也是用户可配置的。
在统计收集间隔结束时,我们还可以看到 C1’s 图标现在已变为黄色,这表示 HealthBot 正在为路由服务器上的客户端 C1 更改最大前缀策略。HealthBot 仪表板将再次显示 C1’s 图标为绿色,因为它在策略内且不超过任何阈值
您可以看到,路由服务器配置已用新值(12个接受前缀 * 1.5)更新为18:
最后,可以单独监控每个’路由服务器客户端接受的前缀和对应的最大前缀值。在Figure 12中,您可以看到客户端 C1 接受的前缀数以及统计时间间隔内配置的最大前缀策略值。
摘要
作者希望本书提供的信息将帮助您开始设计、测试和部署基于 Junos OS 的路由服务器。本书中讨论的配置和设计注意事项只是让您入门。最终,每个 IXP 都是唯一的,并将在实施策略时考虑其自己的注意事项。