上一篇文章我们讲到，如果客户在有很多 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) 技术… 这个技术是啥，到底能不能成功救回因大流量而被堵到瘫痪的网络呢？
欲知后事如何，且听下回分解。