如何在路由策略匹配条件中评估 BGP 社区和扩展社区
当您将 BGP 社区和扩展社区用作路由策略中的匹配条件时,策略框架软件会按如下方式对其进行评估:
在路由策略
from
语句中针对每个命名社区评估每个路由。如果路由与语句中的from
某个指定社区匹配,则将继续评估当前术语。如果路由不匹配,则结束对当前术语的评估。将根据指定社区的每个成员评估路由。所有成员的评估必须成功,指定的社区评估才能成功。
命名社区中的每个成员都由文本社区值或正则表达式标识。将根据与路径关联的每个社区评估每个成员。(社区是路线的无序属性。例如,1:2 3:4 与 3:4 1:2 相同。只需路由中的一个社区进行匹配,成员评估即可成功。
社区正则表达式是逐字符评估的。例如,如果路由包含社区 1234:5678,则正则表达式将看到九个离散字符,包括冒号 (:),而不是用冒号分隔的两组数字(1234 和 5678)。例如:
[edit] policy-options { policy-statement one { from { community [comm-one comm-two]; } } community comm-one members [ 1:2 "^4:(5|6)$" ]; community comm-two members [ 7:8 9:10 ]; }
如果社区成员是正则表达式,则进行字符串匹配而不是数字匹配。
例如:
community example1 members 100:100 community example2 members 100:1..
给定社区值为 1100:100 的路由,此路由匹配但不匹配
community example2
example1
。要匹配路由策略
one
,路由必须匹配comm-one
或comm-two
。要匹配
comm-one
,路由必须具有匹配 1:2 的社区和匹配 4:5 或 4:6 的社区。要匹配
comm-two
,路由必须具有匹配 7:8 的社区和匹配 9:10 的社区。
多场比赛
找到多个匹配项时,不会发生标签聚合。请考虑以下配置:
family inet-vpn { unicast { aggregate-label { community community-name; } } }
family inet-vpn { labeled-unicast { aggregate-label { community community-name; } } }
例如,假设接收了两个具有社区属性 target:65000:1000 origin:65200:2000
的路由,并且社区名称为 "5...:.*"
。在这种情况下,扩展社区属性 target:65000:1000
和 origin:65200:2000
与社区名称的正则表达式匹配。在这种情况下,不会发生标签聚合。在以下示例中,该 Label operation
字段显示未聚合标签。
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: target:65000:1000 origin:65200:2000
您可以通过以下任一方式解决此问题:
如果源站点扩展社区属性不与目标属性重叠,则在正则表达式中更具体。
在社区名称中指定源站点。
以下示例显示了这两种方法。
在正则表达式中更具体
user@host# set policy-options community community-name members "52..:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
在社区名称中指定源站点
user@host# set policy-options community community-name members "origin:65...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
反转社区匹配
community
匹配条件定义正则表达式,如果它与收到的前缀的社区属性匹配,Junos OS 将返回 TRUE 结果。否则,Junos OS 将返回 FALSE 结果。该 invert-match
语句使 Junos OS 的行为与此相反。如果存在匹配项,Junos OS 将返回 FALSE 结果。如果没有匹配项,Junos OS 将返回 TRUE 结果。要反转社区表达式匹配的结果,请将语句 invert-match
包含在社区配置中。
[edit policy-options community name] invert-match;
扩展社区类型
正则表达式不考虑扩展社区类型。例如,请考虑以下社区属性和社区名称。
社区:
-
5200:1000
-
target:65000:1000
-
origin:65200:2000
社区属性:
-
社区名称成员 “5...:.*”
在这种情况下,扩展社区属性 5200:1000
和扩展社区属性 origin:65200:2000
都与社区名称的正则表达式匹配。因此,不会发生标签聚合,如下所示:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: 5200:1000 target:65000:1000 origin:65200:2000
您可以使用更具体的正则表达式来解决此问题。例如,您可以使用锚点字符 (^
) 绑定数字的位置,如下所示:
user@host# set policy-options community community-name members "^5...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000
随着版本 17.3 中大型社区功能的实现,Junos OS 会进行检查,以防止扩展或大型社区与基本 BGP 或基本 BGP 正则表达式社区进行匹配。换言之,接收的群落只能与适当的野生群落模式相匹配,就像正常群落对抗简单野生,扩展群落对抗扩展野生,大型群落对抗大型野生模式。例如,要允许通告承载源扩展社区的路由, origin:*:65020
请使用表达式。
多个社区与 EX-OR 逻辑匹配
这与 BGP 中用于非扩展社区的 AND 匹配逻辑不同。
例如,如果接收到具有两组社区属性的四个路由,则正则表达式可能与两个社区属性匹配。请考虑以下示例:
社区 - 5200:1000 目标:65000:1000
社区—目标:65000:1000 来源:65200:2000
社区属性 - 社区社区名称成员 [ “^5...:.*” 来源:65.*:.* ]
两个标签都是聚合的,如下所示:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.16/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000 10.1.1.20/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000
此处显示了社区值的更完整示例:
user@host> show policy-options community community-name members [ "(^1...:*)|(^3...:*)|(^4...:*)" origin:2.*:* origin:3.*:* origin:6.*:* ]
此正则表达式匹配以 1、3 或 4 开头的社区值,并匹配管理值以 2、3 或 6 开头的源类型的扩展社区值。
在路由策略匹配条件中包括 BGP 社区和扩展社区
要在路由策略匹配条件中包含 BGP 社区或扩展社区,请在策略术语的语句中包含from
条件community
:
from { community [ names ]; }
此外,您可以使用该 none
选项显式排除具有静态路由的 BGP 社区信息。在 route
部分中配置单个路由以覆盖部分中指定的 defaults
社区选项时,请包括此选项。
您可以在匹配条件中包含 community
多个社区的名称。如果这样做,则只需匹配一个社区即可进行匹配(匹配实际上是逻辑 OR 操作)。