16 3 月, 2014
很早就买了这本《MPLS 网络设计权威指南》，但一直没有看，去年年底解决了一些MPLS TE，mVPN的故障，感觉MPLS中的大部分内容基本都已接触到了，所以现在看这本书也许是最合适的时候。这本书中最吸引人的地方就是4个大案例，这是非常有价值的东西。本书英文版是2005年出版，中文是2007年出版的，另一本书《MPLS TE 流量工程》英文版是2002年的，虽然只差了3年，里面扩充了非常多的内容，非常值得一看的工具书
第一章：技术基础：第3层VPN、多播VPN、IPv6和伪线路
本章高度概括，只列出技术分类，不在详细分析
1. L3 MPLS VPN基础，VRF，RD，Packets Forward，详细见我之前的总结
2. 远程接入L3 VPN，l2tp vpdn, pppoe
3. 运营商的运营商架构（CSC），CSC中的包转发
4. 跨域VPN，optionA，B，C，详细见我之前的总结
5. mVPN，SSM，详细见我之前的总结
6. IPv6，其中比较重要的就两个概念：6PE和6VPE，这里需要简要说明一下
6PE Control Plan：
可以看到关键点在于PE本地收到IPv6的报文后，打上自己换回口的label发给远端PE
完整阅读
5 3 月, 2014
学习完《路由优化》好后，按计划开始研究《自顶向下的网络设计》，在这之前，不得不检讨下，路由优化只总结到EIGRP，后面的一直没整理，年纪大了比较懒了。。。望以后补上！
言归正传，当我看完自顶而下的网络设计第一部分，也就是前四章时，发现这是一本非常好的书，但又是一本非常枯燥的书。在第一部分中，基本都在讨论理论，很少涉及技术，对于“攻城狮”的我来说真像在啃一个无味的馒头，但理论是实践的基础，这么重要的东西不能不看。虽然枯燥，但发现作者的逻辑很强，一环套一环，前后呼应，把需求分析逐一讲述给读者。建议可以先看总结，然后逐章阅读，这样感觉效果会更好。另外此书的亮点是每章都会有一个配合本章的Design Scenario，非常赞。
此书唯一让人感觉不爽的就是没有参考答案，Design Scenario也一样，不明为什么，对于scenario，日后有时间再做总结。
23 2 月, 2014
在BRKSE-4054中，对于DMVPN的design做了详细介绍，我这里只是逐一把常用的designs罗列一下，做一个索引，日后有更深的理解，在这里加说明，其实对于每种designs，都需要根据客户的流量做详细测试，另外本文将对两种场景做简单测试，一个是单DMVPN域，双hub；另一个是层次化的DMVPN。
几种常见的部署
1. 双DMVPN域，单hub，每个spoke双p-GRE，Phase1
点评：所有流量都需要经过hub，spoke之间不能建立tunnel，所以两个DMVPN域间的流量分担会更好部署些，特别是两个域都属于不同的ISP
完整阅读
21 2 月, 2014
对于Site-to-Site VPN来说，IPsec是最好的选择，但他有天然的不足，就是无法大规模部署。如果在hub-spoke这种模型下，客户有1000个站点要建VPN，而且spoke跟spoke也要VPN通信，那么全网VPN的配置非常巨大，也非常消耗路由器的资源。此时思科推出了DMVPN，他利用了几个组件，实现了动态IPsec VPN的建立。本文将讨论DMVPN的基本信息及部署方法。
DMVPN的组件
1. mGRE(multipoint GRE)，多点GRE
2. NHRP(Next Hop Resolution Protocol)
3. Dynamic Routing Protocol
4. IPsec VPN，也可以不加IPsec
NHRP类似ARP，不同的是ARP是IP地址到MAC地址的映射，而NHRP是tunnel地址到物理地址（NMBA地址）的映射。
对于DMVPN有3个发展阶段，其他资料里有很细的分类和不同，我在这里只做简单总结：
Phase1：只有hub支持mGRE，branch只支持pGRE；所有流量都需要经过hub，spoke跟spoke之间不能建立隧道；hub可路由汇总，spoke不需要明细路由
Phase2：hub和spoke都支持mGRE；spoke跟spoke可以直接建立隧道，流量可不经过hub；spoke必须要明细路由；hub需要关闭水平分割
phase3：hub和spoke都支持mGRE；spoke跟spoke的隧道由hub触发；hub不需要关闭水平分割
完整阅读
7 11 月, 2013
There have 2 path between PE. And customer found 1st path have 5G traffics, 2nd path only have 300M traffics. After checked, customer have Eompls business.
And amount of traffics belong to l2VPN. In general, Loadbalancing in an MPLS network on Cisco routers is typically based upon the data that follows the bottom MPLS label. Refer to All traffic from one PW follows the same path, so have this issue.
Workaround:
We can use Flow Aware Transport (FAT) PW feature (from 4.2.1).
http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r5.1/lxvpn/command/reference/b_vpn_cr51xasr9k_chapter_011.html#wp3812296210
完整阅读