上一篇文章我们讲到,如果客户在有很多 IP 段的且需求繁多的时候,使用单纯的路由过滤器 ( Route-filter ) 粗暴的进行路由管理,管理起来很麻烦且浪费时间,所以本篇文章将带你初步了解使用 community 进行管理路由条目,了解 community 的魅力。
接上篇所述,我们需要在路由器上配置 community 来进行路由管理,在配置之前,我们先需要一些准备工作。
拓扑整图如下:
我们要事先准备的事项有:
- 一张已经配置好基本 BGP 的网络
- 确认客户已经发送路由过来并且已经接受该路由
首先,我们需要验证客户发送的路由条目:
root@Littlewolf-Backbone> show route receive-protocol bgp 10.0.0.0 inet.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 45.0.0.0/24 10.0.0.0 0 65535 I inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
没有问题。客户发来的 45.0.0.0/24 被正常接收,BGP 连接正常。
过了一星期后,客户从他人手里购买到了大量的 /24 IP 段,且提出了很多的要求,要求如下:
- 需要公告 45.1.1.0/24 – 45.1.10.0/24 共 10 个段
- 45.1.1.0/24 – 45.1.5.0/24 这五个段需要外部访问路由为 Telia 优先
- 45.1.6.0/24 – 45.1.8.0/24 这三个段需要外部访问路由为 NTT 优先
- 45.1.9.0/24 这个段我需要自己按情况调整
- 45.1.10.0/24 这个段只能发送给 NTT,不发送给 Telia,就算 NTT 断了也不要发 (常见于有限广播)
那么,如果按照传统的 route-filter 方式进行过滤 + aspath-prepend,因为需要维护多张策略表,所以会导致管理非常麻烦。这时候,我们的 community 就派上用场了。
在编写配置前,我需要先解释下 community 的原理。
Community 除了公认的属性( no-export, not-advertise 等等 )外,其余的默认为只传递而不采取动作(可选可过渡),而 community 的运作方式有点类似于 Linux bash 的 if 语法(其实 policy-statement 也差不多),如果 match,则 take an action. 比如这样:
#!/bin/bash count=100 if [ $count -eq 100 ] then echo "Count is 100" fi
如上所示,如果变量 $count ( if ) 值等于100则用 echo 命令显示 “count is 100” 这行字 ( take an action )。是不是很明了?再举个与 community 有关的例子:
[edit policy-options] + policy-statement community-example { + term first-one { + from community reject-trigger; // 匹配路由条目里的 community value,若匹配上,就执行动作 + then reject; // 如果接收的路由含有上面定义的 community value,则直接拒绝该路由 + } + } [edit policy-options] + community reject-trigger members 666:6666; [edit]
首先我们先定义 community value 为 666:6666,再在 policy 里面写上以上的语句,并在邻居的 bgp session 上应用该策略,那么逻辑就是:
- 如果对方发过来的路由含这个 community ( 666:6666) ( match ),那么路由器就会拒收该路由条目 ( take an action ).
- 如果对方发过来的路由不含这个 community,那么就不匹配这一条 term,进入下一条。下一条 term 为空,放行该路由。
怎么样,是不是很简单?使用 community 只需要两步骤,1匹配,2执行动作。
话不多说,我们来解决客户的需求吧!
我们使用 community 之前,首先我们需要先定义它的值。我们这个实验内定义的 community 值如下:
community list, 格式为 4B-ASN:NN, NN 为任意值 65535:6661 不要将路由发送给 Telia 65535:6662 不要将路由发送给 NTT 65535:7771 调低 Telia 的优先级,实现方法为 ASPATH-PREPEND, 具体可参照上篇文章所述的 BGP 属性 65535:7772 调低 NTT 的优先级,实现方法同上 65535:888 内部用 community,若有路由匹配上该 community,则向上游发送该条目。
定义完成后,我们开始配置它!
Littlewolf config:
[edit policy-options] // 定义 community value,community 实现功能请看上面 + community advertise members 65535:888; + community lower-priority-ntt members 65535:7772; + community lower-priority-telia members 65535:7771; + community no-ntt members 65535:6662; + community no-telia members 65535:6661; [edit policy-options] + policy-statement ntt-filter { // 定义"拒绝发送"规则,若匹配到 no-ntt (65535:6662) 这个 community 则直接丢弃该路由 + term filter-term { + from community no-ntt; + then reject; + } + } + policy-statement ntt-prepend { // 定义"降低优先级"规则,若匹配到 lower-priority-ntt (65535:7772) 这个 community 则 prepend 这个路由 aspath 属性3次,再进行下一步 + term prepend-term { + from community lower-priority-ntt; + then { + as-path-prepend "138667 138667 138667"; + next term; // 匹配完后进入下一个 policy,而不是直接跳出 + } + } + } + policy-statement telia-filter { // 定义"拒绝发送"规则,若匹配到 no-telia (65535:6661) 这个 community 则直接丢弃该路由 + term filter-term { + from community no-telia; + then reject; + } + } + policy-statement telia-prepend { // 定义"降低优先级"规则,若匹配到 lower-priority-telia (65535:7771) 这个 community 则 prepend 这个路由 aspath 属性3次,再进行下一步 + term prepend-term { + from community lower-priority-telia; + then { + as-path-prepend "138667 138667 138667"; + next term; // 匹配完后进入下一个 policy,而不是直接跳出 + } + } + } + policy-statement bgp-announce { // 定义"发送路由"规则,若匹配到 advertise (65535:888) 这个 community 则发送至上游 + term announce-bgp { + from community advertise; + then accept; + } + term default-reject { // 默认拒绝发送所有路由,防止路由泄漏 + then reject; + } + } + policy-statement customer-import { // 定义客户侧接收路由的规则 + term lower-ntt { // 客户这些段需要 telia 优先,所以我们对 ntt 降低优先级 (aspath prepend) + from { + route-filter 45.1.1.0/24 exact; + route-filter 45.1.2.0/24 exact; + route-filter 45.1.3.0/24 exact; + route-filter 45.1.4.0/24 exact; + route-filter 45.1.5.0/24 exact; + } + then { + community add advertise; // 打上该 community 路由器则认为该路由合法(联动上面 policy) + community add lower-priority-ntt; // 打上 ntt 低优先级 community + accept; + } + } + term lower-telia { // 客户这些段需要 ntt 优先,所以我们对 telia 降低优先级 (aspath prepend) + from { + route-filter 45.1.6.0/24 exact; + route-filter 45.1.7.0/24 exact; + route-filter 45.1.8.0/24 exact; + } + then { + community add advertise; // 打上该 community 路由器则认为该路由合法(联动上面 policy) + community add lower-priority-telia; // 打上 telia 低优先级 community + accept; + } + } + term accept-rest { // 客户这个段他需要自己调整,所以我们不做额外处理 + from { + route-filter 45.1.9.0/24 exact; + } + then { + community add advertise; // 打上该 community 路由器则认为该路由合法(联动上面 policy) + accept; + } + } + term no-telia { // 客户这个段不愿意发送到 telia (只发送到 NTT,所以我们打上 no-telia community 来禁止向 telia 发送 + from { + route-filter 45.1.10.0/24 exact; + } + then { + community add no-telia; // 打上该 community 则路由器在向 telia 发送路由时匹配到预置规则后丢弃 + community add advertise; // 打上该 community 路由器则认为该路由合法(由于这条 term 只是禁止了向 telia 发送,所以 ntt 还是会发送的,只有 telia 被拒绝) + accept; + } + } + term reject-rest { // 默认拒绝所有,防止接收到不法路由后泄漏给邻居 + then reject; + } + } [edit protocols bgp group upstream neighbor 47.0.0.1] - export export-client; // 删除旧的 export 规则 + export [ telia-prepend telia-filter bgp-announce ]; // 按顺序写上规则排列,从左往右生效 [edit protocols bgp group upstream neighbor 74.1.0.1] - export export-client; // 删除旧的 export 规则 + export [ ntt-prepend ntt-filter bgp-announce ]; // 按顺序写上规则排列,从左往右生效 [edit protocols bgp group downstream neighbor 10.0.0.0] - import export-client; // 删除旧的 import 规则 + import customer-import; // 按客户需求调整后的 policy
不错,我们都写完了这些冗长的规则了!可能对于新手来说会有点难以理解,所以这里给大家画一张图来解释一下吧!
看完这张图,你是不是稍微有点理解了呢?虽说使用 community 开头难且配置较多,但是习惯后,你会发现真的好用,后续的维护非常简单,只需要维护一个规则就够了!不多说了,配置已经提交给路由器了,我们来验证对端接收路由的情况吧!
验证 Internet-Routes 接收路由的状态:
Internet-Routes#show ip bgp Status codes: s suppressed, d damped, h history, * valid, > best, i - internal * 45.1.1.0/24 101.1.0.1 0 2914 138667 138667 138667 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i * 45.1.2.0/24 101.1.0.1 0 2914 138667 138667 138667 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i * 45.1.3.0/24 101.1.0.1 0 2914 138667 138667 138667 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i * 45.1.4.0/24 101.1.0.1 0 2914 138667 138667 138667 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i * 45.1.5.0/24 101.1.0.1 0 2914 138667 138667 138667 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i *> 45.1.6.0/24 101.1.0.1 0 2914 138667 65535 i * 101.0.0.1 0 1299 138667 138667 138667 138667 65535 i *> 45.1.7.0/24 101.1.0.1 0 2914 138667 65535 i * 101.0.0.1 0 1299 138667 138667 138667 138667 65535 i *> 45.1.8.0/24 101.1.0.1 0 2914 138667 65535 i * 101.0.0.1 0 1299 138667 138667 138667 138667 65535 i * 45.1.9.0/24 101.1.0.1 0 2914 138667 65535 i *> 101.0.0.1 0 1299 138667 65535 i *> 45.1.10.0/24 101.1.0.1 0 2914 138667 65535 i
不错嘛!根据检查 BGP Table 的情况来看,可以见得 internet-router 做出了以下选路规则:
- 45.1.1.0/24 – 45.1.10.0/24 共 10 个段全部接收到了
- 45.1.1.0/24 – 45.1.5.0/24 这五个段现在为 Telia 链路优先 ( “>” 符号指向的路由为最优路由 )
- 45.1.6.0/24 – 45.1.8.0/24 这三个段需要为 NTT 链路优先
- 45.1.9.0/24 这个段也收到了,公认属性没有改变
- 45.1.10.0/24 这个段只从 NTT 接口收到了,Telia 接口没收到该条目
客户的需求全部实现了,大功告成!可以休息一段时间了~
话说没过几天,客户火急火燎的跑过来大喊 “小狼,我的服务器被攻击了,现在我的网络处于完全瘫痪状态,快帮帮我!”
小狼立即为其启动了 RTBH (Remote Triggered Black Hole) 技术… 这个技术是啥,到底能不能成功救回因大流量而被堵到瘫痪的网络呢?
欲知后事如何,且听下回分解。