We have a public holiday today, so I’ll spend the morning with my kids instead of writing yet another whatever-does-not-scale post. However, I did stumble across two fantastic cartoons that I simply have to share with you.
My next live webinar will be based on the DMVPN design posts I wrote recently and a number of scenarios that landed in my Inbox during the last few months. I’ll try to help you decide which phase of the DMVPN technology to use, which routing protocol would be best for you, and how to optimize the routing protocol you select. We’ll also discuss interesting redundancy and primary/backup scenarios, including combinations of DMVPN, MPLS/VPN and 3G networks.
If you’re new to the DMVPN world or haven’t bought my DMVPN webinars yet, consider the DMVPN Trilogy jumbo pack.
Nicira, the OpenFlow startup behind the Open vSwitch, has finally dropped the stealthy cloak. Congratulations!!! Their web site is still pretty sparse on details, but you can get an initial impression of what they’re doing from a number of white papers describing Network Virtualization Platform and DVNI architecture. Short summary: I was almost right, but being a routing-and-switching bloke missed a few interesting bits – OpenFlow (and Open vSwitch) can easily combine security and forwarding functionality.
Two days ago I described how you can use tunneling or labeling to reduce the forwarding state in the network core (which you have to do if you want to have reasonably fast convergence with currently-available OpenFlow-enabled switches). Now let’s see what you can do in the very limited world of OpenFlow 1.0 (if any shipping physical switch supports OpenFlow 1.1 beyond OpenFlow 1.0 functionality, please write a comment)
For whatever reason, Easy Virtual Network (EVN), a configuration sugar-glaze on top of VRF-lite (oops, multi-VRF) that has been lurking in the shadows for the last 18 months erupted into the twittersphere after Cisco’s latest switching launch. I can’t possibly understand why the implementation of a decade-old technology on mature platform (Catalyst 4500 and Catalyst 6500) makes news at the time when 40GE and 100GE interfaces were launched, but the intricacies of marketing always somehow escaped me.
Yesterday I described how the limited flow setup rates offered by most commercially-available switches force the developers of production-grade OpenFlow controllers to drop the microflow ideas and focus on state abstraction (people living in a dreamland usually go in a totally opposite direction). Before going into OpenFlow-specific details, let’s review the existing forwarding state abstraction technologies.
Last week I described the problems high-end service provider routers (or layer-3 switches if you prefer that terminology) face when they have to update large number of entries in the forwarding tables (FIBs). Will these problems go away when we introduce OpenFlow into our networks? Absolutely not, OpenFlow is just another mechanism to download forwarding entries (this time from an external controller) not a laws-of-physics-changing miracle.
One of my Twitter friends sent me this question: “Would you honestly recommend your webinar subscription for a young CCIE that knows how routing works but have no real world experience and is a noob in DC/VM/NXOS?” That sounds like a perfect audience to me – I usually assume the attendees have mastered the fundamentals of networking/routing but don’t know much about the topics of the webinar (the whole idea of my webinars is to help you get started in new technology areas).
Most interesting article in this batch: Ethernet Taps - Don't Get Me Started by Chris Marget, focusing on Ethernet taps: passive, active, aggregators, L1 switches ...
And here are the other interesting links I found in somewhat random order:
Did you rush to try OSPF Loop Free Alternate on a Cisco 7200 after reading my LFA blog post ... and disappointedly discovered that it only works on Cisco 7600? The reason is simple: while LFA does add feasible-successor-like behavior to OSPF, its primary mission is to improve RIB-to-FIB convergence time.
Assume we have a simple triangular network:
Now imagine the A-to-C link fails. How will OSPF react to the link failure as compared to EIGRP? Which one will converge faster? Try to answer the questions before pressing the Read more link ;)
Scott Lowe asked a very good question in his Technology Short Take #20:
VXLAN uses UDP for its encapsulation. What about dropped packets, lack of sequencing, etc., that is possible with UDP? What impact is that going to have on the “inner protocol” that’s wrapped inside the VXLAN UDP packets? Or is this not an issue in modern networks any longer?
Short answer: No problem.
In the Redundant DMVPN Design, Part 1 I described the options you have when you want to connect non-redundant spokes to more than one hub. In this article, we’ll go a step further and design hub and spoke sites with multiple uplinks.
Public IP addressing
Fact: DMVPN tunnel endpoints have to use public IP addresses or the hub/spoke routers wouldn’t be able to send GRE/IPsec packets across the public backbone.
One of my readers couldn’t figure out which IPv6 webinar to buy. He wrote:
I bought your Service Provider IPv6 Introduction webinar. I’m also interested in Building IPv6 Service Provider Core and Building Large IPv6 Access Networks. I realized that the second training is not released yet and it says that it's an update session for the first training, so do I need to buy both? I would like to download all the material related to the trainings so I would watch them whenever I need.
It seems I did overcomplicate a few things, so I’ll try to clear up the confusion I created.
According to Google Analytics these were the most popular posts I wrote in December 2011:
- Is NAT a security feature?
- Decouple virtual networking from the physical world
- Large-scale L2 DCI: a true story
- We just might need NAT66
- VMware vSwitch – the baseline of simplicity
- Junos Day One: MPLS Behind The Scenes
- VXLAN, IP multicast, OpenFlow and control planes
- Which virtual networking technology should I use?
- Nexus 1000V and vMotion
- IPv6 multihoming without NAT: the problem
- VM-aware Networking Improves IaaS Cloud Scalability
It’s hard for me to admit, but there just might be a corner use case for split subnets and inter-DC bridging: even if you move a cold VM between data centers in a controlled disaster avoidance process (moving live VMs rarely makes sense), you might not be able to change its IP address due to hard-coded IP addresses, be it in application code or configuration files.
Disaster recovery is a different beast: if you’ve lost the primary DC, it doesn’t hurt if you instantiate the same subnet in the backup DC.
Posts
