路由过滤器概述
如果由于跨多个策略术语拆分路由筛选器而担心策略性能,请使用步行功能。walkup 功能支持将路由过滤器整合到一个策略术语下。
默认情况下,Junos 会评估策略语句术语中的多个路由过滤器,方法是首先查找最长匹配前缀,然后评估附加到路由过滤器的条件(例如前缀范围)。如果路由过滤器条件为 false(例如,前缀不在指定范围内),则整个术语为 false,即使可能存在 true 的较短路由过滤器前缀也是如此。由于此行为,如果将路由过滤器拆分为单独的策略语句术语,则可能会出现性能问题。步行功能更改默认路由筛选器行为。
由于默认路由过滤器行为,某些自动化策略工具(例如,用于边界网关协议 (BGP) 中的自治系统边界路由器的工具)将路由过滤器分解为多个术语。路由过滤器还用于 BGP 以外的路由协议;漫游功能不仅限于 BGP 路由过滤器。
从技术上讲,BGP 处理路由的方式与 OSPF 或 IS-IS 不同。BGP“路由”更恰当地称为网络层可达性信息 (NLRI) 更新。但是,术语“路由”在大多数文档中使用,并在此处使用。
路由过滤器由三个主要部分组成:
前缀和前缀长度(例如
10.0.0.0/8
)匹配条件(例如
exact
)如果前两个部分(前缀和匹配条件)的计算结果均为 true(例如,
accept
)
因此, 10.0.0.0/8 exact accept
当且仅当考虑 10.0.0.0/8
的前缀完全相同时,路由过滤器才会成功。此路由过滤器拒绝具有所有其他较长前缀的路由,例如 10.0.0.0/10
,尽管策略链 10.0.0.0/10
中可能还有其他路由过滤器术语接受路由。
10.0.0.0/8
尽管路由和变体不是专门为文档保留的,但由于此地址空间提供的灵活性和现实方案,本主题中使用了专用 RFC 1918 10.0.0.0/8
地址空间。
路由过滤器可以组合在单个策略语句术语中。在这种情况下,评估变得更加复杂。请考虑以下路由策略:
[edit policy-options] policy-statement RouteFilter-A { term RouteFilter-1 { from { route-filter 10.0.0.0/16 prefix-length-range /22-/24; route-filter 10.0.0.0/8 orlonger; } then accept; } term default { then reject; } }
请注意, 10.0.0.0/8 orlonger
筛选器在其范围内包含 10.0.0.0/16 prefix-length-range /22-/24
筛选器。也就是说,前缀为 8 位或更长的任何 10.0.0.0
路由也可能是前缀在 22 到 24 位范围内的路由。
缺省情况下,评估具有多个路由过滤器的策略语句术语的过程分为两步:
策略框架软件根据前缀和前缀长度值对列表执行最长匹配查找。
软件会考虑路由过滤条件(
orlonger
、exact
等)。路由满足路由筛选条件(成功)或与路由筛选条件不匹配(失败)。
根据这两个步骤的结果,由匹配或失败确定的操作将应用于路由。在 中 Route-Filter-A
,这意味着任何“真”的路由都会被接受,而任何在该项中 RouteFilter-1
为“假”的路由都会被拒绝。此路由将成为隐藏(过滤)路由。
例如,考虑当策略语句RouteFilter-A
评估路由10.0.0.0/18
时会发生什么:
首先, 10.0.0.0/18
按 RouteFilter-1
术语评估路由。因为 长于 10.0.0.0/8
,所以10.0.0.0/16
路由匹配10.0.0.0/18
更长、更具体的路由前缀。接下来,匹配失败,因为 10.0.0.0/18
路由与条件不匹配 prefix-length-range /22-/24
。因此,路由匹配在术语中 RouteFilter-1
失败,策略会检查下一个术语,即默认术语。10.0.0.0/18
路由被默认术语拒绝。
因此, 10.0.0.0/18
路由将被隐藏(过滤)。10.0.0.0/18
(仍可使用命令找到show route hidden路由。
问题是用户可能实际上希望 10.0.0.0/18
路由被接受,而不是被拒绝。当然,可以添加具有配置的 10.0.0.0/18 exact
路由过滤器。但是,在具有 100,000 个或更多条目的主干路由表中,无法配置针对添加到网络中的每个可能路由或每个可能的新路由进行调整的路由过滤器。
要从示例路由策略中实现正确行为,默认解决方法是为每个路由过滤器配置一个单独的术语。这经常进行,如下所示:
[edit policy-options] policy-statement RouteFilter-A { term RouteFilter-1 { from { route-filter 10.0.0.0/16 prefix-length-range /22-/24; } then accept; } term RouteFilter-2 { from { route-filter 10.0.0.0/8 orlonger; } then accept; } term default { then reject; } }
现在, 10.0.0.0/18
路由被接受,因为尽管它仍然不符合 RouteFilter-1
匹配条件,但它与新 RouteFilter-2
项匹配(10.0.0.0/8
是最长匹配,并且 orlonger
条件为 true)。此方法的问题在于,与对多个路由过滤器进行分组时相比,现在评估完整路由策略所需的时间更长。这种方法也使维护更加复杂。
每个路由一个术语筛选器方法的问题已通过 walkup 语句和功能得到解决。Walkup 会全局或基于策略更改路由过滤器评估的默认行为。
步行功能允许具有多个路由筛选器的术语“上行”评估过程,以包括不太具体的路线以及最长的匹配。换句话说,步行旋钮将默认行为从“如果一个失败,则术语失败”更改为“如果一个匹配,则术语匹配”。
考虑将逐步执行功能应用于示例策略语句(您还可以将逐步执行全局应用于配置的所有策略):
[edit policy-options] policy-statement RouteFilter-A { defaults { route-filter walkup; } term RouteFilter-1 { from { route-filter 10.0.0.0/16 prefix-length-range /22-/24; route-filter 10.0.0.0/8 orlonger; } then accept; } term default { then reject; } }
这是当策略语句RouteFilter-A
评估路由前缀10.0.0.0/18
时发生的情况:
默认行为由步行旋钮更改。和以前一样,路由匹配10.0.0.0/18
更长和更具体的路由前缀,因为10.0.0.0/16
比 长。10.0.0.0/8
和以前一样,此匹配失败, 10.0.0.0/18
因为路由与条件不匹配 prefix-length-range /22-/24
。但是,这一次该过程继续“向上走”并检查不太具体的 10.0.0.0/8
路由过滤器。的 orlonger
路由条件与此过滤器匹配,因此术语接受 RouteFilter-1
路由。
这可以通过命令进行 show route protocol bgp 10.0.0.0/18 验证(对于 BGP 路由)。这一次,路由没有隐藏。
如果全局启用步行功能,则可以使用该语句在每个 [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup]
策略的基础上在本地覆盖该功能。