大约5个月前,我长篇大论的思科在他们新的“长途VMotion验证架构”。简而言之,我没有对思科的解决方案支持VMotion inter-datacenter L2连接。快进到思科本周宣布的包裹运输虚拟化(OTV),其新的软件解决方案inter-datacenter 2层连接。在简单的层面上,思科公司采纳了我的建议,我可以解决任何与隧道和想出OTV(这就是为什么我认为思科欠我一些版税.... j / k)。在更深的层次上,思科花时间提供所需要的L2互连,但封锁所有的坏事——ARP洪水、生成树协议,未知单播帧等。这是由OTV自动完成。它股票MAC表之间的网站连接到OTV“云”,并将L2转发帧内OTV封装(以太网/ GRE具体)。这对我们有非常有趣的影响。正如我之前在博客中写道,我们有新的数据中心网络基于Nexus 7000年代。雷竞技电脑网站我们升级其他企业数据中心与Nexus 7000年代在未来6个月。雷竞技电脑网站最终,这两个bi-coastal数据中心将是公司的引擎。雷竞技电脑网站企业应用程序和灾难恢复将映射到这两个公司的数据中心。雷竞技电脑网站OTV提供了一个很好的方式提供这些数据中心之间的层2连接使用一个单一的IP范围,促进虚拟化和运动数据,并简化博士激活一个事件应该发生。雷竞技电脑网站 Migrating applications could be easier also since IPs on servers and DNS would not need to change. However, there are some areas that need to be addressed which I am unable to determine right now. Cisco.com actually has a limited amount of information about OTV right now. First, while the OTV does provide a split-active FSRP (think HSRP) for optimized outbound traffic, I didn't see anything about subnet advertisement to the global routing table. Let's say our data center subnet is 10.255.0.0/16. We then build a new DC on the opposite side of the USA and extend the L2 boundary to the new DC using OTV. This new DC, which will also have devices in the 10.255.0.0/16 range, will also need to advertise subnets (or a single /16 for better summarization) to the global routing table. Now let's say Site #3 needs to communicate with server 10.255.100.25. Just looking at the diagram that traffic would probably follow the 10.255.0.0/16 advertisement into the east data center. Then does it ride the OTV tunnel to the west data center? That's inefficient for both delay and bandwidth utilization. This can be solved by leaking routes, at worst /32 host routes, into the global routing table. Then the Site #3 router would know to send packets directly to the west data center. Too bad this could explode your global routing tables. Plus, most MPLS service providers limit the number of routes you can advertise to them. This would never work if you have IP VPN services from an MPLS carrier. Cisco needs to address this issue in the future. It's a huge routing problem. Secondly, OTV needs to integrate - automatically - with load balancing. Real servers in a load balancing pool that move across the L2 tunnel need to become part of a VIP-pool in the new data center, not remain a part of the original data center's VIP pool. You could argue this change is no different than moving data storage when a VM moves, but load balancing is inherently a "network" service often provided by Cisco products. Thus, OTV should address is somehow; perhaps with XML integration with ACE or something. It will be interesting to watch OTV mature. It will be going on our roadmap this week to research in the near future.
与OTV在幕后OTV主页OTV白皮书OTV常见问题解答OTV vs vpl新的OTV许可模式
更多的从野外>博客条目:
流我有媒体播放器通过Verizon MiFi我的iPhone
去思科子网思科的新闻,博客,论坛,安全警报,赠书,等等。