我们都知道 IDC 需要使用 BGP 协议来与上游交换路由表和发送自己的 IP Prefix，而且可以通过 BGP 来对路由属性对自己和客户的网段进行修改以达到控制路径的效果。但是有多少人知道其实 BGP 可以使用 community 来实现非常方便的路由路径调整呢？这篇文章将讲述如何使用 community 来打造适合机房的路由控制方案。
要想知道如何使用 BGP community，我们则先需要了解一下 BGP 的属性。
BGP 的属性分以下几种类型，分别是公认必遵，公认自决，可选可过渡，可选不可过渡 。而这些属性又有属于他们不同的特点。
公认必遵（Well-Known Mandatory） 是所有路由器都必须识别的属性，且这些属性必须出现在路由描述中并传递给 BGP 邻居。公认必遵的属性有以下几个：
ORIGIN（起源）：这个属性说明了源路由是怎样放到 BGP 表中的。 在路由选择的时候，ORIGIN中，IGP优于EGP，EGP优于INCOMPLETE。
AS_PATH（AS路径）：指出包含在 UPDATE 报文中的路由信息所经过的自治系统的序列。
Next_HOP (下一跳)声明路由器所获得的BGP路由的下一跳，对 eBGP 会话来说，下一跳就是通告该路由的邻居路由器的源地址。
公认自决（Well-Known Discretionary） 也是所有路由器必须识别的属性，但是可以让路由器自己决定该属性需不需要传递，以及出不出现在路由描述中。公认自决的属性有以下几个：
LOCAL_PREF (本地优先级)： 仅在IBGP对等体之间交换，不通告给其他AS。当BGP的路由器通过不同的IBGP对等体得到目的地址相同但下一跳不同的多条路由时，将优先选择LOCAL_PREF属性值较高的路由。
ATOMIC_AGGREGATE (原子聚合)：原子聚合属性指出已被丢失了的信息。
可选可过渡（Optional Transitive） 与 可选不可过渡（Optional Nontransitive） 并不要求所有运行BGP协议的系统都识别。如果属性是可选过渡的，那么，即使运行BGP的系统不能识别该属性，也要接受该属性并将其转发给它的对等体。而如果属性是可选不可过渡的，运行BGP的系统可以忽略包含该属性的消息并且不向它的对等体转发。 这两种类型的属性分别有以下几个：
COMMUNITY(团体) 是一组共享相同属性的目的地集合， 用来简化路由策略的应用和降低维护管理的难度，没有物理上的边界，与其所在的AS无关。
AGGREGATOR(聚合者) 该属性补充了路由信息在哪里丢失——它包含了发起路由聚合的AS号码和形成聚合路由的BGP发布者的IP地址。
MULTI_EXIT_DISC(多出口区分)被用来区分同一个邻接AS的多个接口。
ORIGINATOR_ID(起源ID) 用于标识路由反射器，防止引入路由反射器之后出现环路，增加ORIGINATOR_ID这个属性来标识，反射器在发布路由时加入ORIGINATOR_ID，当反射器收到的路由信息中的ORIGINATOR_ID就是自己的ROUTER_ID时，就可以发现路由环路的出现，将该路由丢弃，不再转发。
CLUSTER_LIST(簇列表) 用于标识路由反射器组 ，也是用来防止环路，在路由经过路由反射器时路由反射器会将自己的CLUSTER_ID添加到路由携带的CLUSTER_LIST中，当路由反射器发现接收的路由的CLUSTER_LIST中包含有自己的CLUSTER_ID，则将该路由丢弃，不再转发。
那么我们很清楚的看到了，公认属性已经被定义好了该属性所应发挥的作用，我们无法对其进行个性化修改来实现自己想要的效果。而可选属性大部分都是在多出口选路用以及网络内存在路由反射器 (Route reflector) 对其进行标识以起到防环的作用。而唯一的可自定义的属性则是 COMMUNITY（团体）属性了。要使用 COMMUNITY 来对路由路径进行控制，我们得先了解下该属性的定义。
团体属性可以添加在每一个路由前缀中，由RFC1997定义，是一个transitive optional属性。包含有团体属性的路由，表示该路由是一个路由团体中的一员，该路由团体具有某种或多种相同的特征。根据这些特征区分不同的路由，可以大大简化路由策略的配置工作，同时也增强路由策略的能力。
ref: 新华三技术官网
我们可以预先定义 community 来标识路由并管理路由。但是在这之前，我们需要一个 BGP 网络来进行操作。那么我们就先开始搭建一个数据中心的网络吧！
完整拓扑如下：
你需要准备的事项有：
一台 Juniper MX 路由器（本实验使用 Juniper 路由器进行模拟）
一位找你购买了 Transit 的客户
你向你的上游们购买了 Transit
我们向上游购买带宽后，运营商会为我们拉一条物理链路，并给我们 Transit info 来配置 BGP Peer，Transit info 如下所示：
（以下数据均为模拟环境数据，真实操作请使用运营商给予的信息进行配置）
Transit info：
[AS 1299] Telia carrier 47.0.0.1/31 <-> 47.0.0.0/31 LittleWolf Connect [AS 138667]
[AS 2914] NTT 74.1.0.1/31 <-> 74.1.0.0/31 LittleWolf Connect [AS 138667]
好了，我们现在已经索取到 BGP 信息，是时候开始组建网络了。话不多说，开始搭建！
LittleWolf Router conf:
root@Littlewolf-Backbone > show system rollback compare 2 0
+ ge- 0 / 0 / 0 { // 配置 telia 侧的 IP
+ ge- 0 / 0 / 1 { // 配置客户侧的 IP
+ ge- 0 / 0 / 2 { // 配置 NTT 侧的 IP
+ route 0 . 0 . 0 . 0 / 0 discard; // 手动汇总默认路由用于发给客户
+ group upstream { // 配置上游链路组，组名 upstream
+ type external; // 定义邻居类型为 ebgp 邻居
+ local-as 138667 ; // 本地 ASN 138667
+ neighbor 47.0 . 0.1 { // telia carrier bgp 配置文件
+ import accept- in ; // 定义收路由的策略
+ export export-client; // 定义发路由的策略，这里是将客户路由向外发送
+ peer-as 1299 ; // 对端 asn
+ neighbor 74.1 . 0 . 1 { // ntt bgp 配置文件
+ group downstream { // 配置与客户侧相连的下游链路组，组名 downstream
+ type external; // 定义邻居类型为 ebgp 邻居
+ local-as 138667 ; // 本地 ASN 138667
+ neighbor 10.0 . 0 . 0 { // 下游客户的配置文件
+ import export-client; // 过滤客户路由，只接受合法的 IP段，拒收其他的非客户IP的段（防止客户乱发路由）
+ export export-default; // 给客户发默认路由
+ policy-statement accept- in {
+ from protocol bgp; // 接受 bgp 路由
+ policy-statement export-client {
+ route-filter 45.0 . 0 . 0 / 24 exact; // 接受客户该合法IP段，若匹配，则存入转发表并发送给上游
+ then reject; // 拒绝其他路由，一定要写，不然会漏路由
+ policy-statement export-default {
+ route-filter 0 . 0 . 0 . 0 / 0 exact; // 将手动汇总的默认路由发送给客户，且只需要发这一条路由
+ then reject; // 拒绝其他路由，一定要写，不然会漏路由。真实环境中，客户的设备可受不了全表的轰炸！一定要小心！
配置完成了，我们来验证是否成功建立了 BGP 邻居吧！毕竟想要使用 community 必须要已经有正常工作的 BGP 网络呢。
验证骨干路由器的 BGP 邻居：
root@Littlewolf-Backbone > show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State |#Active/Received/Accepted/Damped…
10.0 . 0 . 0 65535 107 110 0 0 47 : 07 1 / 1 / 1 / 0 0 / 0 / 0 / 0
47.0 . 0.1 1299 112 109 0 0 48 : 13 3 / 3 / 3 / 0 0 / 0 / 0 / 0
74.1 . 0 . 1 2914 112 113 0 0 48 : 10 0 / 3 / 3 / 0 0 / 0 / 0 / 0
邻居关系建立正确，而且从上游已经收到了来自 Google, Microsoft, Apple 的路由条目。那么我们继续观察下路由表。
验证骨干路由器的路由表：
root@Littlewolf-Backbone > show route protocol bgp
inet. 0 : 11 destinations, 14 routes ( 11 active, 0 holddown, 0 hidden )
+ = Active Route, – = Last Active, * = Both
8 . 8 . 8 . 8 / 32 * [ BGP/ 170 ] 00 : 42 : 51 , localpref 100
AS path: 1299 4785 I, validation-state: unverified
> to 47.0 . 0.1 via ge- 0 / 0 / 0 . 0
[ BGP/ 170 ] 00 : 05 : 09 , localpref 100
AS path: 2914 4785 I, validation-state: unverified
> to 74.1 . 0 . 1 via ge- 0 / 0 / 2.0
13.64 . 0 . 1 / 32 * [ BGP/ 170 ] 00 : 42 : 51 , localpref 100
AS path: 1299 4785 I, validation-state: unverified
> to 47.0 . 0.1 via ge- 0 / 0 / 0 . 0
[ BGP/ 170 ] 00 : 00 : 35 , localpref 100
AS path: 2914 4785 4785 4785 4785 I, validation-state: unverified
> to 74.1 . 0 . 1 via ge- 0 / 0 / 2.0
17.0 . 0.1 / 32 * [ BGP/ 170 ] 00 : 42 : 51 , localpref 100
AS path: 1299 4785 I, validation-state: unverified
> to 47.0 . 0.1 via ge- 0 / 0 / 0 . 0
[ BGP/ 170 ] 00 : 05 : 09 , localpref 100
AS path: 2914 4785 I, validation-state: unverified
> to 74.1 . 0 . 1 via ge- 0 / 0 / 2.0
45.0 . 0 . 0 / 24 * [ BGP/ 170 ] 00 : 51 : 34 , MED 0 , localpref 100
AS path: 65535 I, validation-state: unverified
> to 10.0 . 0 . 0 via ge- 0 / 0 / 1.0
可以看到已经从上游收到了路由表，且与下游客户的路由器也建立了 BGP 连接。那么我们再来看一下客户的路由器吧！
验证客户路由器 BGP 数据库：
BGP table version is 14 , local router ID is 10.0 . 0 . 0
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal
Network Next Hop Metric LocPrf Weight Path
* > 0 . 0 . 0 . 0 10.0 . 0.1 0 138667 i
* > 45.0 . 0 . 0 / 24 0 . 0 . 0 . 0 0 32768 i
可见客户已经成功建立了与我们的 BGP 链接，且已收到我们发过来的默认路由。那么现在网络已经通了吗？
验证网络连通性：
clien t#ping 8.8.8.8 source 45.0.0.1
Type escape sequence to abort.
Sending 5 , 100 -byte ICMP Echos to 8 . 8 . 8 . 8 , timeout is 2 seconds:
Packet sent with a source address of 45.0 . 0.1
Success rate is 100 percent ( 5 / 5 ) , round-trip min/avg/max = 3 / 5 / 11 ms
clien t#traceroute 8.8.8.8 source 45.0.0.1
Type escape sequence to abort.
Tracing the route to 8 . 8 . 8 . 8
VRF info: ( vrf in name/id, vrf out name/id )
1 10.0 . 0.1 [ AS 138667 ] 10 msec 11 msec 3 msec
2 47.0 . 0.1 [ AS 138667 ] 6 msec 14 msec 3 msec
3 101.0 . 0 . 0 [ AS 138667 ] 8 msec 10 msec *
Ping 与 Traceroute 结果正常，可见 BGP 工作正常，对方已接受我们的 IP 段，通信正常。
对于这种疑问，我想说的是，如果客户网络规模很大而且条目很多，而且客户有要求那些段只能发给哪个 transit，哪些段不能发给哪个 transit，需要维护好几个过滤表，那岂不是很麻烦？为了方便维护，我们就需要是用 community 来进行一站式管理。
欲知后事如何，且听下回分解。
