路由过滤器概述
如果您因为跨多个策略条款拆分路由过滤器而对策略性能存有疑虑，请使用查看功能。演练功能支持在一个策略期限下整合路由过滤器。
默认情况下，Junos 在策略语句术语中评估多个路由过滤器，首先查找最长的匹配前缀，然后评估附加到路由过滤器的条件（如前缀范围）。如果路由过滤器条件为 false（例如，前缀不在指定范围内），则整个术语为 false，即使存在可能较短的路由过滤器前缀也是如此。由于这种行为，如果路由过滤器被拆分为单独的策略语句术语，可能会有性能问题。了解功能可更改默认路由过滤器行为。
由于默认的路由过滤器行为，某些自动化策略工具（例如，用于边界网关协议 （BGP） 中的自治系统边界路由器的策略工具将路由过滤器分解为多个术语。除 BGP 以外的路由协议中也使用路由过滤器;了解功能不仅限于 BGP 路由过滤器。
从技术上说，BGP 处理路由的方式与 OSPF 或 IS-IS 不同。BGP“路由”更恰当地称为网络层可访问性信息 （NLRI） 更新。但是，术语“路由”在大多数文档中使用，此处也使用。
路由过滤器由三个主要部分组成：
前缀和前缀长度（例如
10.0.0.0/8）匹配条件（例如
exact）如果前一部分（前缀和匹配条件）都评估为真，将执行一个操作（例如
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 位或 8 位以上的任何 10.0.0.0 路由也可能是前缀在 22 位到 24 位之间的路由。
默认情况下，包含多个路由过滤器的策略语句术语评估过程分两步完成：
策略框架软件会基于前缀和前缀长度值对列表执行最长匹配查找。
软件会考虑路由过滤器条件（
orlongerexact等）。路由要么满足路由过滤器条件（成功），要么与路由过滤器条件（失败）不匹配。
根据这两个步骤的结果，由匹配或故障确定的操作应用于路由。在 Route-Filter-A中，这意味着接受任何“正确”路由，并且拒绝术语 RouteFilter-1 中为“假”的任何路由。此路由将成为隐藏（过滤）路由。
例如，考虑通过策略语句RouteFilter-A评估路由10.0.0.0/18时会发生什么：
首先，按10.0.0.0/18RouteFilter-1术语评估路由。因为 10.0.0.0/16 比路由长 10.0.0.0/8， 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条件为真）。这种方法的问题是，与对多个路由过滤器进行分组相比，评估完整的路由策略现在需要更多时间。此方法也使维护工作变得更为复杂。
每个路由过滤器一个术语的问题可通过 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 路由。
这可以通过命令验证（对于 BGP 路由 show route protocol bgp 10.0.0.0/18 ）。这一次，路由不会隐藏。
如果全局启用逐步功能，则可以使用 [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] 语句按策略在本地覆盖该功能。