简介这份PPT面向通信网络运维人员、网络规划工程师及备考相关认证的技术学习者系统梳理中国移动CMNET的骨干网络架构与路由策略帮助读者建立从网络分层到路由组织的整体认知。资源包内含1个pptx文件整体约6.43MB以图文并茂的幻灯片形式呈现便于课堂讲解与自学查阅。内容覆盖骨干核心层、汇聚层、接入层的分层结构以及网络概述、网络现状、路由组织策略与网络演进等关键议题并延伸至Web cache、DNS、流控系统等配套技术同时结合CMNET一期至五期的建设历程说明双节点改造、10G链路引入、集群路由器部署与IDC发展等阶段性特征。目录按骨干架构、缓存与流控、省网组织、高价值业务保障等模块展开结构清晰适合作为网络架构梳理与路由策略学习的参考材料。目前已有75人学习。1. 从一份 2012 年的 CMNET 架构 PPT 说起它到底能解决什么问题翻到这份《CMNET网络结构和路由策略.pptx》的时候我第一反应是——这玩意儿年代感太强了。2012 年 8 月CMNET 六期工程还没完工五期工程 911 条骨干链路里还有 270 条没到位全网省际链路 205 条其中 31 条峰值利用率已经打到 100%。但恰恰是这种“工程进行时”的文档比任何教科书都更能讲清楚一件事一个国家级骨干网是怎么从双节点改造、10G 端口引入、集群路由器上线一步步演进到能承载 824Gbps 总流量的。这份 PPT 覆盖了骨干网络架构、路由组织策略、Web cache/DNS/流控系统、省网组织结构、高价值业务区分与保障五大块。它不是给初学者看的科普而是给当时参与 CMNET 五期、六期建设的工程师做技术交底用的。如果你现在在做运营商级网络规划、IDC 互联方案设计或者单纯想搞明白“骨干核心层、汇聚层、接入层”到底怎么划分、路由反射器怎么部署、网间互联节点为什么选北京上海广州这份材料里的拓扑逻辑和参数取舍放到今天依然有参考价值。我把它拆了一遍下面按“架构怎么分层 → 路由怎么组织 → 互联怎么设计 → 坑在哪 → 怎么验证”的顺序讲。2. 骨干网三层架构拆解核心层、汇聚层、接入层的职责边界与节点设置2.1 三层结构的功能划分与节点选址逻辑CMNET 骨干网按功能分为三层骨干核心层、骨干汇聚层、骨干接入层。这个分层不是拍脑袋定的背后是流量模型和故障域隔离的考量。骨干核心层由北京、上海、广州三个节点构成职责是中转省际流量和网间流量同时负责全网与国际 Internet、国内其他运营商的互联。核心层节点之间要求全网状互联——六期工程后除西安、沈阳外骨干核心节点之间都是全网状互联。为什么是北上广因为国际出口、国内互联出口、NAP 互联都设在这三个城市流量天然汇聚。骨干汇聚层是西安、成都、武汉、南京、沈阳五个节点负责汇接各省到骨干网的连接相当于中国电信的普通核心。每个汇聚节点负责本大区内省份流量之间的交换。六期工程把原核心骨干层和汇聚骨干层统一调整为骨干核心层汇聚和疏通出网的业务量实现跨省业务的有效疏通。骨干接入层按一个省份两个骨干接入节点设置只负责汇聚本省省际流量和出网流量。全网 23 个骨干接入节点六期新增天津私有云节点作为骨干接入节点。节点设置有一条硬原则无论骨干和省网、城域网一般接入节点至少连接两个上级节点。城域网核心至少连接两个省网核心省网核心至少连接两个以上骨干核心或汇聚。这就是“双节点、双设备、双上联”的由来。2.2 省网两种自治域结构与组网原则省网分两种结构。A 结构覆盖 29 个省采用一个自治域分为省网核心、省网接入、城域网接入三层。B 结构是广东和江西采用不同 AS。这个差异直接影响路由策略——同 AS 内可以用 IGP 直接打通不同 AS 之间必须走 BGP。省网核心层向上连接骨干核心或汇聚节点向下连接城域网核心。城域网核心至少连接两个省网核心这是冗余的基本要求。省网接入层/城域网核心这一层实际上承担了本省流量的汇聚和分发。一个容易被忽略的细节原则上同省的两个接入节点同时连至三个核心节点中的一个按区域连至五个汇聚节点的一个或多个。只有杭州连接至三个核心并连接到南京。六期后增加了到核心以及汇聚的多个方向连接比如济南连武汉、厦门连武汉。这种“多方向连接”是为了在单节点故障时流量能快速切换到备用路径。2.3 国际出口层与海外 POP 点的部署国际出口层由北京、上海、广州的路由器组成面向国内连接骨干核心层面向国外连接海外 POP 点。设立这个层面的一个重要目的是方便国际出口配套工程实施——把国际流量先汇聚到出口层再做统一的策略调整不用在每个核心节点上单独配策略。海外 POP 点方面美国 POP 点设在洛杉矶和旧金山负责北美方向的国际互联网接入。香港 POP 点负责香港本地和部分东南亚、欧洲的互联网接入。伦敦 POP 点负责欧洲国际互联网接入当时只有 1 台设备且未启用。每个节点规划两台路由器这是标准配置。网间互联节点设置上国内互联节点北京、上海、广州均为双节点设置。国际互联路由器也是双节点但由于安全配套尚未到位北京国际出口、上海国际出口 2、广州国际出口 1 暂未上线。NAP 互联路由器北京、上海、广州均为单节点设置。注意海外 POP 点由中国移动国际公司运营的 CMNET 国际网CMI提供拥有独立自治系统。现有北美 POP 点单局址双设备、香港 POP 点单局址双设备及欧洲 POP 点尚未承载业务。3. 路由组织策略落地从 IGP 选路到网间流量调优的实操路径3.1 路由反射器部署与 IGP 路由表设计CMNET 骨干网的路由组织核心是 BGP IGP 的组合。IGP 负责骨干网内部的可达性BGP 负责省际和网间的路由交换。六期工程的一个关键调整是北京、西安、武汉、广州、上海设置独立的 IP RR路由反射器。为什么需要独立的 RR因为骨干网节点数量增长后IBGP 全互联的会话数呈平方级增长。以 36 个节点城市计算全互联需要 630 条 IBGP 会话维护成本极高。RR 的引入把会话数降到线性级别每个客户端只需要和 RR 建立会话。RR 的部署位置也有讲究。北京、上海、广州是核心层必须设 RR。西安、武汉是汇聚层设 RR 是为了覆盖中西部和华中区域的省网接入。广州设 RR 是因为华南区域流量大且广东是 B 结构省网需要独立的路由策略。IGP 路由表的设计原则是核心层和汇聚层之间的链路作为主路径接入层到核心/汇聚的链路作为备份。具体配置上通常用 OSPF 或 ISIS 作为 IGPcost 值按链路带宽设置——10G 链路 cost 设小2.5G 链路 cost 设大155M 链路 cost 设最大。这样 IGP 选路自然倾向于高带宽路径。3.2 网间互联路由策略与流量调优网间互联的路由策略直接决定了流量怎么走。PPT 里给了一组关键数据电信互联方向北京:上海:广州 300:287:359联通互联方向北京:上海:广州 374:223:393。这组数字是向外发布路由的条数不是带宽。为什么广州发布的条数最多因为广州片区覆盖广东、广西、海南、云南、贵州等省份这些省份到电信和联通的互访流量大。北京片区覆盖北京、天津、河北、山西、内蒙古、辽宁、吉林、黑龙江、陕西、甘肃、宁夏、青海、新疆范围广但单省流量相对分散。上海片区覆盖上海、江苏、浙江、安徽、福建、江西、山东、河南、湖北、湖南、四川、重庆、西藏流量居中。路由发布策略的核心逻辑是按片区广播网间路由吸引入流量。具体做法是在三个核心节点上配置 BGP 策略对来自电信和联通的路由按片区打 community 属性然后在向外发布时根据 community 决定是否发布以及发布多少条。流量调优的另一个手段是划分大区负责网内流量调整。中国移动大区内流量优先通过汇聚节点转发不绕行核心节点。比如成都大区内的四川和重庆互访优先走成都汇聚节点不走广州核心。这样可以降低核心节点的压力也减少时延。3.3 省际流量与网间流量的实际分布PPT 里有一组 2012 年 3 月的实测数据骨干网承载总流量 824Gbps其中省际流量 555Gbps 占 67%网间流量 269Gbps 占 33%。省际流量排名前 10 的省份总和 421Gbps占省际流量的 76%。网间流量排名前 10 的省份总和 175Gbps占网间流量的 65%。这组数据说明一个事实流量高度集中。浙江、江苏、上海、山东、江西、山西、广东、河南、福建、四川这十个省贡献了四分之三以上的省际流量。在做容量规划和路由策略时这十个省是重点保障对象。各省从骨干网到电信方向的流量总和 91.9Gbps排名前十省份总和 59.5Gbps 占 64.8%。到联通方向流量总和 75Gbps排名前十省份总和 48.7Gbps 占 65%。电信方向的流量略大于联通方向这和电信的宽带用户基数有关。提示做流量调优时先看省际流量排名和网间流量排名把 Top 10 省份的链路利用率和路由策略单独拉出来分析。尾部省份的流量小策略调整的收益有限。4. 高价值业务保障与流控系统Web cache、DNS 和流量控制的协同4.1 Web cache 部署位置与缓存命中率优化Web cache 在 CMNET 里的部署位置通常在省网核心层或城域网核心层。放在省网核心层的好处是覆盖全省用户坏处是缓存服务器需要处理全省的 HTTP 请求压力大。放在城域网核心层的好处是压力分散坏处是缓存命中率可能下降因为城域网的流量规模小缓存内容覆盖不全。PPT 里没有给出具体的缓存命中率数据但从架构逻辑推断CMNET 的 Web cache 应该采用分层部署省网核心层部署大容量缓存集群城域网核心层部署小容量缓存节点。省网核心层的缓存集群负责热门内容的全局缓存城域网节点负责本地热门内容的缓存。缓存命中率优化的关键是内容热度预测和缓存替换策略。常见做法是用 LRU最近最少使用或 LFU最不经常使用作为缓存替换算法同时根据内容类型设置不同的 TTL。静态资源如图片、CSS、JS 文件设置较长的 TTL动态内容设置较短的 TTL 或不缓存。4.2 DNS 系统架构与解析路径优化DNS 系统在 CMNET 里的作用是把域名解析成 IP 地址直接影响用户访问网站的速度。CMNET 的 DNS 系统通常采用递归解析 权威解析的分层架构。递归解析器部署在省网核心层负责接收用户 DNS 查询并逐级查询权威服务器。权威服务器部署在骨干核心层负责解析 CMNET 自己管理的域名。DNS 解析路径优化的核心是减少递归查询的跳数。常见做法是在递归解析器上配置缓存把热门域名的解析结果缓存下来。同时配置转发器把非本域名的查询转发给上游 DNS 服务器避免从根域名开始逐级查询。另一个优化点是 DNS 就近解析。根据用户的源 IP 地址返回最近的服务器 IP。比如用户在北京访问某个 CDN 域名DNS 返回北京节点的 IP而不是广州节点的 IP。这需要 DNS 系统支持 EDNS Client SubnetECS扩展把用户的子网信息传递给权威服务器。4.3 流控系统与高价值业务标识流控系统在 CMNET 里的作用是控制网络流量避免拥塞和崩溃。PPT 里提到高价值业务的区分、标识原则及保障方法这是流控系统的核心功能。高价值业务的区分通常基于五元组源 IP、目的 IP、源端口、目的端口、协议号或 DPI深度包检测。比如 VoIP 业务用 UDP 且端口号在特定范围视频业务用 RTSP 或 HTTP 流媒体协议这些都可以通过 DPI 识别出来。标识原则是在网络边缘给高价值业务的报文打上 DSCP差分服务代码点标记。比如 VoIP 打 EF加速转发视频打 AF41保证转发普通上网流量打 BE尽力而为。然后在核心节点和汇聚节点的队列调度上按 DSCP 值分配不同的带宽和优先级。保障方法包括队列调度算法如 WFQ、CBWFQ、LLQ和拥塞避免机制如 WRED。LLQ低延迟队列适合 VoIP 这种对时延敏感的业务WRED加权随机早期检测适合 TCP 流量可以在队列满之前随机丢包避免全局同步。注意流控系统的策略配置要避免过度精细化。如果每条业务流都单独配策略设备性能会急剧下降。常见做法是按业务类型分组每组配一条策略。5. 避坑与排查CMNET 架构落地中最容易翻车的五个点5.1 双上联变单上联链路扩容时的配置遗漏现象某省接入节点按规划应该双上联到两个汇聚节点但实际运行中发现只有一条链路承载流量另一条链路处于空闲状态。原因链路扩容时只加了物理链路没有更新 IGP cost 或 BGP 策略。IGP 选路时两条链路 cost 相同但 BGP 的 best path 选择算法只选了一条另一条没有进入转发表。解决检查 IGP 的 cost 配置是否对称检查 BGP 的 multipath 配置是否开启。如果设备支持开启 BGP multipath 让两条链路同时承载流量。如果不支持用 IGP 的等价多路径ECMP来分担。5.2 路由反射器集群 ID 冲突导致路由丢失现象RR 部署后部分客户端的路由没有反射到其他客户端导致某些省际路由丢失。原因多个 RR 配置了相同的 cluster ID。BGP 路由反射器用 cluster ID 来防止路由环路如果两个 RR 的 cluster ID 相同客户端会认为是从同一个 RR 收到的路由只保留一份。解决每个 RR 配置唯一的 cluster ID。通常用 RR 的 router ID 作为 cluster ID确保全局唯一。5.3 网间互联路由发布过多导致入流量突增现象某核心节点调整了向电信方向的路由发布策略后入流量突然增加链路利用率从 60% 飙升到 95%。原因路由发布条数增加后电信侧的网络认为通过 CMNET 到达某些目的地更优把大量流量切到了 CMNET。PPT 里电信互联北京:上海:广州 300:287:359如果广州从 359 增加到 500入流量会显著增加。解决调整路由发布策略时先在小范围测试观察入流量的变化。可以用 BGP community 做精细控制只对特定省份或特定客户发布额外路由。5.4 DNS 缓存污染导致解析异常现象用户访问某些网站时DNS 解析返回错误的 IP 地址导致访问失败或跳转到错误页面。原因DNS 递归解析器的缓存被污染攻击者向递归解析器发送伪造的 DNS 响应把错误 IP 写入缓存。解决启用 DNSSEC 验证确保解析结果的真实性。同时配置 DNS 缓存的最小 TTL避免缓存被长期污染。定期清理递归解析器的缓存。5.5 流控策略过严导致正常业务被限速现象某省部署流控系统后用户反映视频卡顿、下载速度慢但网络监控显示带宽利用率并不高。原因流控策略把某些正常业务误判为高带宽占用业务进行了限速。比如把 HTTPS 流量误判为 P2P 下载限制了带宽。解决检查 DPI 规则的准确性更新特征库。对于无法准确识别的流量先放行再观察不要直接限速。流控策略上线前先在镜像流量上测试确认误判率在可接受范围内。6. 从六期工程看架构演进容量规划与扁平化试点的验证方法六期工程有一个值得单独拿出来讲的点苏州城域网流量直连骨干网南京、上海节点进行扁平化试点。这个试点的背景是传统三层架构下苏州城域网的流量要先经过省网核心再到骨干汇聚路径长、时延大。扁平化后苏州城域网直接连到骨干节点省掉省网核心这一跳。验证扁平化效果的方法很简单在试点前后分别抓取苏州到南京、苏州到上海的流量路径和时延数据。如果时延降低、路径跳数减少说明扁平化有效。但要注意扁平化会增加骨干节点的端口压力和路由表规模需要评估骨干节点的处理能力。容量规划方面PPT 里有一组关键数据2003 年到 2011 年网络承载流量增长 175 倍年均增长 90.7%。2008 年到 2011 年业务量增长 8 倍年均增长 100%。但网络建设容量只增长约 45 倍年均增长 62.7%。网络容量建设速度远低于业务量增长这是 CMNET 当时面临的核心矛盾。做容量规划时我一般会按“峰值利用率不超过 70%”来设计。PPT 里 2012 年 3 月的数据显示205 条省际链路中37 条峰值利用率超过 80%31 条达到 100%。这些链路就是扩容的优先级最高目标。指标2003 年2011 年年均增长网络承载流量5.6G840.4G90.7%网络建设容量约 40G约 1800G62.7%主流端口技术155M/2.5G10G—宽带用户数100 万1000 万—WLAN AP 数20 万200 万—这张表说明一个事实流量增长和容量建设之间存在剪刀差。做规划时不能只看当前的利用率要按业务增长趋势预留 buffer。我一般会按“未来 12 个月流量增长 80%”来估算如果当前峰值利用率已经超过 50%就要启动扩容。从那以后我每次做骨干网规划都强制走一遍“流量增长趋势 → 容量缺口 → 扩容优先级 → 扁平化可行性”的流程。先看历史数据算年均增长率再看当前峰值利用率算出还能撑几个月然后按链路利用率排序决定先扩哪条。扁平化试点要先做小范围验证确认骨干节点扛得住再推广。希望帮到你。本文还有配套的精品资源点击获取