菜单




[ SR-TE ] 使用 BGP Auto-Steering 对内网流量进行路径调度

2021年6月13日 - BGP, Cisco, Segment Routing

上篇文章我们讲了，SR ( segment routing ) 可以实现更低的拓扑维护开销，且无需像 RSVP-TE 一样维护极为庞大的网状 TE 数据库，管理起来也很方便。那么这篇文章我们来讲一下比较基础的 SR-TE 使用方案，其中一个就是 BGP 的 Auto-steering 操作，可以很方便的实现内网的流量控制与调度。

在讲 SR-TE 之前，我们先需要介绍一下 SR-TE 的一些特点。

1.什么是 SR-TE？为什么要选择它？

思科院士 Clarence Filsfils 在 2013 年发明了 Segment Routing（SR）技术。SR 具有源路由和状态只存在于边缘的特点，使其可以支持超大规模的流量工程，同时原生就适合与 SDN 结合，实现应用驱动的网络。

而相比于 RSVP-TE 来说，RSVP 因为是基于电路的思想，用 IP 来模拟电路。其中一个典型表现是编码路径时需要把路径上沿途经过的每台设备的每跳接口的地址/标签都包括进来，而不能像 SR 一样使用 Prefix-SID，通过少数 Segment 即可编码路径。

RSVP-TE 需要建立和维持全网状互联隧道，数量是 k×N2 条，其中 N 为网络中节点数量，k 为等价路径数量。这是一个很严重的可扩展性问题（RSVP 的软状态协议特征，更加剧了问题的严重性），事实上这对所有 RSVP-TE 用户都造成了十足的困扰，有些用户甚至最后不得不拆除所有的 RSVP-TE 隧道。

引用自《新一代 Segment Routing 流量工程体系 – SR Policy》 ，点击此处访问源链接

从中可得出以下几点关于 RSVP-TE 的弱点总结：

而对于这些问题来说，SR-TE Policy 则有极大的改善，具体总结如下：

根据特点总结可得知，SR-TE 是未来流量工程的主流。但是在使用之前，我们需要了解以下最基础的概念。

2.SR-TE Policy 的基础组成部分以及概念

SR Policy 由（头端，颜色，端点）三元组标识。在给定的头端节点上，SR Policy 由（颜色，端点）二元组标识。在生成路径时，需遵从约束条件来计算。常用的约束条件有 metric type，链路亲和属性（affinity），延迟，最大堆栈列表等条件，本文中只使用 TE Metrics + Affinity 来作为 TE Cpath 计算时候的约束条件。

3.开始配置 SRTE Policy

网络拓扑如下：

图中已经标明了 affinity，TE metric，IGP Metric 值，我们需要建立 SRTE Policy 来使去往 100.64[1-3].0/24 这三个段走不同的路径。其中需要走的路径如下所示：

在配置之前，我们已经预先配置好了链路上的所有 Metric 值（包括 TE Metric，IGP Metric），且 R1 <-> R8 建立了 iBGP 的邻居关系，并传递了路由。下面我们开始配置 SR Policy.

由于 SRTE 只需要在头端路由器配置，所以我们想调度 R1 -> R8 的流量，需要在 R1 上配置 SR Policy 来对流量进行调度。请注意，该调度是单向的，若想控制 R8 -> R1 的流量，则需要在 R8上也配置 SR Policy 来控制回程流量。

给链路打上颜色（亲和属性，实际上你想怎么命名都行）
每台路由器上都要按照自己的规划给链路打上亲和属性。

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/1
   affinity
    name BLUE
   !
   affinity-map
   name BLUE bit-position 0

在配置之前，必须将链路状态重分布进 SR TEDB，不然无法计算出路径！！！
重分布在路由进程下面做，你使用什么协议作为 IGP 底层，就进入什么进程配置！

RP/0/RP0/CPU0:R1#show run router isis
router isis 1
{..snip..}
 distribute link-state
开始配置 SR Policy

segment-routing
 traffic-eng
  policy blue // 定义 Policy name 为 blue（走蓝色的隧道，实际取什么名字都可以）
   binding-sid mpls 15555 // 手工从 SRLB 里面取一个标签指定 BSID，用于引流流量进入隧道。建议每个 Policy 使用同一个 BSID
   color 10 end-point ipv4 10.0.0.8 // 定义终点地址
   candidate-paths
    preference 100 // 定义优先级。若同一个 Policy 有多个优先级的 SID-List，则选择最大的
     dynamic
      metric
       type te // 使用动态计算方式来生成 SR Policy，计算时使用 TE 的 Metric 进行计算
      !
     !
     constraints // 约束条件的配置
      affinity // 链路亲和属性
       include-all // 计算中只允许亲和属性为 BLUE 的链路被计算进去
        name BLUE
       !
  !
  policy orange // 同上
   binding-sid mpls 15556
   color 20 end-point ipv4 10.0.0.8
   candidate-paths
    preference 100
     dynamic
      metric
       type te
      !
     !
     constraints
      affinity
       include-any
        name ORANGE
       !
  !

配置完成后，我们来检查以下 Policy 的生效情况：

Policy BLUE:

RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy name srte_c_10_ep_10.$
Sun Jun 13 12:13:15.812 UTC

SR-TE policy database
---------------------

Color: 10, End-point: 10.0.0.8
  Name: srte_c_10_ep_10.0.0.8
  Status:
    Admin: up  Operational: up for 21:40:04 (since Jun 12 14:33:11.720)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: blue
      Requested BSID: 15555
      Constraints:
        Protection Type: protected-preferred
        Affinity:
          include-all:
          BLUE
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 23
          16002 [Prefix-SID, 10.0.0.2]
          16003 [Prefix-SID, 10.0.0.3]
          15003 [Adjacency-SID, 10.10.34.3 - 10.10.34.4]
          16008 [Prefix-SID, 10.0.0.8]
  Attributes:
    Binding SID: 15555 (SRLB)
{..snip..}
Policy ORANGE:

RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy name srte_c_20_ep_10.$
Sun Jun 13 12:13:20.586 UTC

SR-TE policy database
---------------------

Color: 20, End-point: 10.0.0.8
  Name: srte_c_20_ep_10.0.0.8
  Status:
    Admin: up  Operational: up for 21:23:54 (since Jun 12 14:49:26.513)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: orange
      Requested BSID: 15556
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 20
          16002 [Prefix-SID, 10.0.0.2]
          16003 [Prefix-SID, 10.0.0.3]
          15001 [Adjacency-SID, 10.10.38.3 - 10.10.38.8]
  Attributes:
    Binding SID: 15556 (SRLB)
{..snip..}

查看结果可得知，BLUE 的路径经过了 R2 -> R3 -> R4 -> R8, 而 ORANGE 的路径经过了 R2 -> R3 -> R8， 两个 Policy 计算出来的路径均符合要求。

但是，为什么会出现 Adjacency-SID？这就需要从 SRTE 的计算原理来讲了，我们这里以 Policy BLUE 为例，讲一下路由器是怎么计算出该路径的。

首先， SRTE 会使用 TE Metric 计算出期望的路径值，这里图中标出来了，R2 -> R3 -> R4 -> R8 是 Metric 最优先且包含 亲和属性 BLUE 的路径。计算出来后，使用 IGP cost 计算并生成 SID-list （生成路径时用的是 IGP Cost，一定要注意）

到这里，路径计算就完成了，Policy ORANGE 也是一样的计算过程，这里就不再做赘述。

计算完 SID-list，Policy 生效后，我们需要对 BGP 的流量进行引流。这里我们使用 Color community 的方式来实现自动引流，操作方便易上手。

在默认环境下，只有 BGP 路由的 next-hop 以及 color 值和 SRTE Policy 的 color + endpoint 匹配才会引流，否则不会引流。

extcommunity-set opaque ORANGE
  20
end-set
!
extcommunity-set opaque BLUE
  10
end-set
// 定义 Color community，需要和 SR Policy 的 color 值一样，你想引流到哪个 Policy，就定义什么 color 值

route-policy import-from-GRT
  if destination in (100.64.1.0/24) then
    set extcommunity color BLUE additive // 对路由进行染色（按照上文需求来）
    pass
  else
    if destination in (100.64.2.0/24) then
      set extcommunity color ORANGE additive // 同上
      pass
    else
      pass // 其他路由不染色，follow igp
    endif
  endif
end-policy

router bgp 65000
 {..snip..}
 !
 neighbor 10.0.0.8
 {..snip..}
  address-family ipv4 unicast
   route-policy import-from-GRT in // 在接收对端发过来的路由的时候进行路由染色

我们对路由染色完毕，现在检查下对应的 BGP 表和 FIB：

RP/0/RP0/CPU0:R1#show bgp
{..snip..}
   Network            Next Hop            Metric LocPrf Weight Path
*> 100.64.0.0/24      0.0.0.0                  0         32768 i
*>i100.64.1.0/24      10.0.0.8 C:10            0    100      0 i // 100.64.1.0/24 已经染色 BLUE
*>i100.64.2.0/24      10.0.0.8 C:20            0    100      0 i // 100.64.2.0/24 已经染色 ORANGE
*>i100.64.3.0/24      10.0.0.8                 0    100      0 i

Processed 4 prefixes, 4 paths

RP/0/RP0/CPU0:R1#show cef 100.64.1.0/24
Sun Jun 13 12:46:44.518 UTC
100.64.1.0/24, version 449, internal 0x5000001 0x40 (ptr 0xd7adf38) [1], 0x0 (0xe339f48), 0x0 (0x0)
 Updated Jun 12 14:57:39.356
 Prefix Len 24, traffic index 0, precedence n/a, priority 4
   via local-label 15555, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xd8f44c8 0x0]
    recursion-via-label
    next hop via 15555/1/21
     next hop srte_c_10_ep labels imposed {ImplNull} // 转发时将压入 Policy BLUE 的 BSID，流量将使用 SR Policy BLUE 进行转发

RP/0/RP0/CPU0:R1#show cef 100.64.2.0/24
Sun Jun 13 12:46:46.637 UTC
100.64.2.0/24, version 451, internal 0x5000001 0x40 (ptr 0xd7ad698) [1], 0x0 (0xe33a458), 0x0 (0x0)
 Updated Jun 12 14:57:39.356
 Prefix Len 24, traffic index 0, precedence n/a, priority 4
   via local-label 15556, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xd8f3960 0x0]
    recursion-via-label
    next hop via 15556/1/21
     next hop srte_c_20_ep labels imposed {ImplNull} // 转发时将压入 Policy ORANGE 的 BSID，流量将使用 SR Policy ORANGE 进行转发

OK，看起来没有问题了，转发表显示也正常，我们来看看从 Client-A 跟踪 Client-B 3个 IP 的路径：

root@Client-A:~# mtr 100.64.1.2 -n --report
Start: 2021-06-13T12:57:48+0000
HOST: Client-A                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 100.64.0.1                 0.0%    10    3.4   3.3   2.1   6.3   1.2
  2.|-- 10.10.12.2                 0.0%    10   10.5  11.4   6.3  16.3   3.4
  3.|-- 10.10.23.3                 0.0%    10    6.8   6.1   3.3   8.8   1.8
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 10.10.48.8                 0.0%    10    9.3  11.6   5.9  20.7   5.1
  6.|-- 100.64.1.2                 0.0%    10   11.9   7.2   3.3  12.5   3.2
// Policy Blue，路径：R1 -> R2 -> R3 -> R4 -> R8，符合需求

root@Client-A:~# mtr 100.64.2.2 -n --report
Start: 2021-06-13T12:59:58+0000
HOST: Client-A                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 100.64.0.1                 0.0%    10    4.2   7.0   2.3  19.4   6.1
  2.|-- 10.10.12.2                 0.0%    10    5.4   8.2   5.2  13.4   3.3
  3.|-- 10.10.23.3                 0.0%    10    7.0   4.0   2.8   7.0   1.1
  4.|-- 10.10.38.8                 0.0%    10    3.7   9.1   3.6  17.4   4.4
  5.|-- 100.64.2.2                 0.0%    10    3.3   6.4   3.3   9.6   2.1
// Policy Orange，路径： R1 -> R2 -> R3 -> R8，符合需求

root@Client-A:~# mtr 100.64.3.2 -n --report
Start: 2021-06-13T13:00:18+0000
HOST: Client-A                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 100.64.0.1                 0.0%    10    2.9   4.7   2.1   9.6   2.6
  2.|-- 10.10.15.5                 0.0%    10    8.1   7.1   2.9  10.9   2.6
  3.|-- 10.10.56.6                 0.0%    10    3.1   4.8   3.1   7.7   1.8
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 10.10.78.8                 0.0%    10    3.9   6.6   3.7  10.1   1.9
  6.|-- 100.64.3.2                 0.0%    10    3.4   5.4   3.4  12.8   2.9
// Follow IGP，下面的路径最优，路径： R1 -> R5 -> R6 -> R7 -> R8，符合需求

到这里我们就完成了 BGP 路由内网路径的调度，全部符合需求，实验完成。

下次讲一下 On-demand SR Policy 以及与 RSVP-TE 的互操作。

参考资料：

《[ SR-TE ] 使用 BGP Auto-Steering 对内网流量进行路径调度》有1个想法

chaselian

你好，你用的也是EVE吗，用的思科的XRV的镜像是哪个哈，我用EVE，用 思科的XRV镜像跑SR policy，配置完了之后没有生效。谢谢您

回复 ↓

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。