运营商互联网骨干网与城域网互联结构及策略研究

王泽林，谢梦楠（中国联通网络技术研究院，北京100048）

0 引言

国内运营商互联网骨干网一般按照双平面设置，2 个平面流量基本均衡，同时能够起到保护的作用。骨干网与城域网一般通过2 对路由器进行互联，分别对应2 个平面，两网之间通过BGP 路由协议疏导互通流量。骨干网与城域网之间采用不同的互联结构、不同的路由策略均会引起骨干网2个平面流量的均衡问题，以及骨干网和城域网核心路由器之间流量的横穿等问题。本文主要研究国内运营商互联网骨干网与城域网之间典型的互联结构以及相应的路由策略，给出不同方案之间的比较。

1 骨干网与城域网连接方式

运营商骨干网与城域网一般通过2对路由器进行互联，分别对应2个平面，连接方式分为口字型连接和交叉连接。

1.1 口字型连接

骨干网边缘接入路由器（A路由器）与城域网核心路由器（CR）分平面互联（见图1）。CR1 与A1 路由器相联，CR2 与A2 路由器相联，CR1 和CR2 互联，A1 和A2路由器视流量情况决定是否互联。CR1与A1路由器之间的链路用来疏通骨干网平面一与城域网之间的流量，CR2与A2路由器之间的链路用来疏通骨干网平面二与城域网之间的流量。

1.2 交叉连接

图1 口字型连接示意图

骨干网A 路由器与城域网CR 交叉互联（见图2）。CR1 与A1、A2 路由器相联，CR2 与A1、A2 路由器相联，CR1和CR2互联，A1和A2路由器视流量情况决定是否互联。CR1 与A1、A2 路由器之间的链路以及CR2 与A1、A2 路由器之间的链路分别用来疏通骨干网2个平面与城域网之间的流量。

图2 交叉连接示意图

1.3 2种连接方式的优缺点

口字型连接结构具有以下优缺点。

a）优点：单边连接节省CR、骨干网A路由器端口资源和对应链路的传输资源，且骨干网双平面结构清晰。

b）缺点：CR之间存在上行横穿流量（可以配合调整CR下发到BRAS/SR的路由策略来避免此问题）。

交叉型连接结构具有以下优缺点。

a）优点：CR之间不存在上行横穿流量。

b）缺点：增加了CR、骨干网A路由器的端口消耗和传输资源的消耗，骨干网双平面结构不清晰。

考虑成本因素，推荐使用口字型连接。

2 骨干网与城域网间路由策略

骨干网与城域网之间通过EBGP进行路由交换。

2.1 上行流量路由引导策略

a）CR 给BRAS/SR 下发骨干网发布的明细路由。在CR 与城域网BRAS/SR 之间开启IBGP，将CR 接收到的明细路由通过IBGP下发到BRAS/SR（根据业务开通情况可考虑下发其他路由）。上行流量根据明细路由进行优选，选择不同的CR 作为出口进入骨干网。此策略解决了口字型连接下CR间横穿流量的问题。

b）CR 给BRAS/SR 下发默认路由。在CR 与城域网BRAS/SR 之间使用IGP，通过下发默认路由给BRAS/SR 设备，引导上行流量负载分担到2 台CR，如骨干网A路由器与CR之间采用口字型连接，则由于路由优选的因素，部分上行流量会在CR之间进行横穿。

2.2 下行流量路由引导策略

a）方式一：城域网2 台CR 发布不同的用户地址段（各一半）给骨干网。城域网2 台CR 发布不同的用户地址段给骨干网A路由器，同时要做到2台CR发布的用户路由基本均衡，来引导流量大致均分到2台CR入城域网。

b）方式二：城域网2 台CR 发布相同的用户地址段（所有城域网用户地址段）给骨干网。城域网2 台CR发布相同的用户路由给骨干网A路由器，同时在骨干网内部启用虚拟下一跳技术，使流量在骨干网内部负载均衡到2台A路由器，进而从骨干网进入城域网。

虚拟下一跳技术是一种实现IBGP 的负载均衡办法。假设网络中用IBGP 承载用户路由，IGP 为IS-IS，在2台目的路由器（骨干网A路由器）中分别设置1个相同的虚拟地址，在与其他IBGP邻居路由器宣告路由时，将该地址作为到达下一跳地址，在2台目的路由器上再分别配置1 条静态路由，将该虚拟地址的下一跳指向城域网CR 互联接口的地址。采用该方式后，从源到目的的流量将在BGP 属性Weight、Local Prefer⁃ence、AS-path、Origin、MED均相同的情况下，强行将到达目的的路由下一跳指向相同的虚拟地址。该地址对于源路由器在选路时完全相同，将以负载均衡的方式分别发送到2台目的路由器（骨干网A路由器）。

采用此方法，还可以在目的路由器建立IBGP邻居中设置路由策略控制部分路由（China169 A 路由器中可设置为城域网CR 发布的所有用户路由）的虚拟下一跳，而其他路由的下一跳不变，提高路由的可控性。

2 种方式对比，方式二能更好地做到骨干网的流量均衡以及骨干网到城域网的流量均衡，但需要增加配置量，同时在骨干网使用虚拟下一跳技术之前，还需要全网规划某运营商所有城域网的虚拟下一跳地址，避免重复。

2.3 骨干网与城域网互联结构及策略

基于上述的上、下行流量引导策略，考虑骨干网与城域网互联结构及策略时，可以有以下2种方案（方案不限于以下2 种，本文只挑选了最有可能的2 种进行阐述）。

a）方案一：CR与A路由器之间口字型连接，CR与BRAS 间开启IBGP 承载用户路由，CR 向BRAS/SR 设备下发运营商网内路由，2 台CR 向直连的2 台A 路由器各发一半的用户路由，骨干网策略不变。流量流向参见图3。

图3 方案一流量流向图

（a）上行流量引导：根据明细路由进行优选。

（b）下行流量引导：根据2台A路由器向骨干发布的不同用户路由进行下行流量引流。

（c）优点：无CR 间横穿上行流量，无骨干网横穿流量。

（d）缺点：2台CR虽然是各发布一半的地址段，但由于不同地址段对应的流量不一定相同，仍然可能会造成BRAS/SR至CR的链路流量不均衡。

b）方案二：CR 与A 路由器之间口字型连接，CR向BRAS 设备下发默认路由，2 台CR 向直连的2 台A路由器发全部的城域网用户路由，骨干网采用虚拟下一跳技术，将发布用户路由的下一跳地址指向1 个虚拟地址，虚拟地址的真实下一跳地址为2台CR的地址（虚拟下一跳在2台A路由器上设置）。参见图4。

图4 方案二流量流向图

（a）上行流量引导：从BRAS到CR负载分担上行，CR到A路由器直接上行。

（b）下行流量引导：骨干网内流量负载分担到2台A路由器，从A路由器到CR流量直接下行，从CR到BRAS流量直接下行。

（c）优点：无CR 间横穿上行流量，无骨干网A 路由器之间平面间横穿流量，骨干网流量均衡，BRAS到CR流量均衡，CR至A路由器流量均衡。

（d）缺点：全国所有A 路由器需要增加虚拟下一跳的配置，需要增加虚拟下一跳到CR 的实际下一跳的静态路由配置，全国需统一规划所有城域网的虚拟下一跳地址。

由于方案二需要全网统一增加A 路由器的配置，所以在该方案的实施过程中，不同城域网与骨干网之间路由策略的修改会有先后顺序，不可避免地会出现过渡阶段，当某一城域网与骨干网之间已经修改为方案一的路由策略方案，而对端城域网与骨干网之间还未修改时，方案二处于改造的中间状态，如图5所示。

3 总结

运营商互联网骨干网与城域网的连接方式及互联策略众多，本文提出了2 种典型的互联结构及互联策略方案供运营商选择。不同方案的选择应综合考虑技术方面的优缺点、投资成本、改造难度等多种因素，在现有网络结构及互联策略的基础上逐步演进。

图5 方案二改造中间状态流量流向图

［1］ 邓炜，赵武，范春湘.利用BGP 虚拟下一跳技术实现IP 骨干网流量负载均衡［J］.电信工程技术与标准化，2009（8）：63-66.

［2］ 陈敏.广域网架构与路由技术项目教程［M］.北京：电子工业出版社，2013：213-255.

［3］ Randy Zhang，Micah Bartell.BGP 设计与实现［M］.北京：人民邮电出版社，2012：110-180.

［4］ Priscilla Oppenheimer. Top-Down Network Design［M］. Indianapo⁃lis：Cisco Press，2011：51-78.

［5］ Parkhurst，William R. Cisco BGP-4 Command and Configuration Handbook［M］.Indianapolis：Cisco Press，2001：120-142.

［6］ Faraz Shamim，Zaheer Aziz，Johnson Liu，et al.IP 路由协议疑难解析［M］.北京：人民邮电出版社，2013：50-70.

［7］ Jeff Doyle. TCP/IP 路由技术（第二卷）［M］. 北京：人民邮电出版社，2009：350-380.

［8］ 张国清.路由技术（IPv4 版）［M］.北京：电子工业出版社，2012：70-120.

［9］ Todd Lammle.CCNA学习指南［M］.北京：电子工业出版社，2009：267-387.

［10］Diane Teare.CCNP Route［M］.北京：人民邮电出版社，2011：297-457.

［11］Russ White，Don Slice，Alvaro Retana.路由设计的优化［M］.北京：人民邮电出版社，2013：348-392.

［12］Zaheer Aziz，Johnson Liu，Abe Martey. IP 路由协议疑难解析［M］.北京：人民邮电出版社，2013：52-137.

［13］Sam Halabi.Internet 路由结构［M］.北京：人民邮电出版社，2015：221-228.

［14］ IETF RFC 4271.A Border Gateway Protocol 4（BGP-4）［S/OL］.［2015-07-02］.https：//www.rfc-editor.org/rfc/rfc4271.txt.

［15］ IETF RFC 1997. BGP Communities Attribute［S/OL］.［2015-07-02］.https：//www.rfc-editor.org/rfc/rfc1997.txt.