Blog Posts in April 2012
The most popular post in March was the one describing my BGP security Internet draft. That’s good news – let’s hope you’ll all implement the recommended security measures. And here’s the top-10 list as reported by Google Analytics.
- My first Internet Draft has just been published
- Stretched Layer-2 Subnets – The Server Engineer Perspective
- OpenFlow: A perfect tool to build SMB data center
- Knowledge and Complexity
- Cisco & VMware: Merging the Virtual and Physical NICs
- MPLS/VPN in the Data Center? Maybe not in the hypervisors
- VXLAN and EVB questions
- Grumpy Monday: HP and OpenFlow
- Do we really need Stateless Transport Tunneling (STT)
- Scalable, Virtualized, Automated Data Center
In this part of the OpenFlow webinar, Greg Ferro talks about SDN and controller ecosystems, including a great overview of potentially relevant SDN technologies, from venerable SNMP to NETCONF and OpenFlow (more information, roadmap, videos and PDFs).
Vasilis sent me an interesting campfire story. It started with a common mistake:
An external partner of my company used an Ethernet cable and connected two switchport interfaces of one of our access switches .
Being a conscientious networking engineer, he had the usual safeguards in place ...
Five years ago I was writing about trivial things like continuous pings, booting a 2800-router with an USB image and EEM tricks. Three years ago it was traffic shaping, IOS interface names, OSPF (router ID selection and SPF events) and BGP Route Reflector update groups.
The blogosphere has been full of OpenFlow-related articles recently (no wonder - there was Open Networking Summit in Santa Clara), so here's a special OpenFlow edition of interesting links
Let's start with my good friend Greg Ferro. I'm so glad to see him returning back from a sabbatical at OpenFlow Kool-Aid lake. His latest articles are a must-read: OpenFlow might lower CapEx while SDN will increase OpEx and OpenFlow doesn’t undermine Vendors even though it changes everything. We're perfectly aligned, which will make our discussions way less interesting, but I'm glad I'm not the only conservative in the town.
I’ve published two cloud networking-related presentations to my webinar demo web site: the Cloud Computing Networking Under the Hood presentation from EuroNOG 2011 briefly describes various technologies you can use to implement virtual networks in IaaS clouds, the Cloud Networking Scalability one from RIPE64 addresses the scalability aspects of these technologies.
VMware has a fantastic-looking cloud provisioning tool – vCloud director. It allows cloud tenants to deploy their VMs and create new virtual networks with a click of a mouse (the underlying network has to provide a range of VLANs, or you could use VXLAN or vCDNI to implement the virtual segments).
Needless to say, when engineers not familiar with the networking intricacies create point-and-click application stacks without firewalls and load balancers, you get some interesting designs.
Google Analytics claims blog posts describing Nicira were among the most popular content written in February 2011. No surprise there. Here’s the whole top-10 list:
- Does CCIE still make sense?
- Nicira Open vSwitch inside vSphere/ESX
- IBM launched a Nexus 1000V competitor
- Nicira, BigSwitch, NEC, OpenFlow and SDN
- Nicira uncloaked
- 6WIND: Solving the Virtual Appliance Performance Issues
- Embrace the change ... resistance is futile ;)
- Microsoft Network Load Balancing Behind the Scenes
- Edge Virtual Bridging (802.1Qbg) – a technology refusing to die
- Forwarding State Abstraction with Tunneling and Labeling
Buying a new networking appliance (be it VPN concentrator, firewall or load balancer … aka Application Delivery Controller) is a royal pain. You never know how much performance you’ll need in two or three years (and your favorite bean counter will not allow you to scrap it in less than 4-5 years). You do know you’ll never get the performance promised in vendor’s data sheets … but you don’t always know which combination of features will kill the box.
Now, imagine someone offers you a performance guarantee – you’ll always get what you paid for. That’s what LineRate Systems, a startup just exiting stealth mode is promising.
One of the answers you get from some of the vendors selling you data center fabrics is “you can use any topology you wish” and then they start to rattle off an impressive list of buzzword-bingo-winning terms like full mesh, hypercube and Clos fabric. While full mesh sounds like a great idea (after all, what could possibly go wrong if every switch can talk directly to any other switch), it’s actually the worst possible architecture (apart from the fully randomized Monkey Design).
Before reading the rest of this post, you might want to visit Derick Winkworth’s The Sad State of Data Center Networking to get in the proper mood.
The system that allows me to publish slide decks on my demo site is finally ready for beta testing ... you’re most welcome to try it with different browsers and tell me how many things are broken.
Last week Juergen Brendel published an interesting blog post describing how you can use vCider to implement high-availability clusters with multi cloud strategy, triggering the following response from one of my readers: “I hadn't heard of vCider before but seeing stuff like this always makes me doubt my sanity – is there really a situation where the only solution is multi-site L2?”
Fernando made a very valid comment to my Monkey Design Still Doesn’t Work Well post: if we would add a few more links between edge and core (fabric) switches to that network, we might get optimal bandwidth utilization in the core. As it turns out, that’s not the case.
We’ve seen several interesting data center fabric solutions during the Networking Tech Field Day presentations, every time hearing how the new fabric technologies (actually, the shortest path bridging part of those technologies) allow us to shed the yoke of the Spanning Tree monster (see Understanding Switch Fabrics by Brandon Carroll for more details). Not surprisingly we wanted to know more and asked the obvious question: “and how would you connect the switches within the fabric?”
It's been a while since I published the interesting links; there were so many of them in my Evernote notebook that I had to publish the data center ones separately.
Let's start with Network, Interrupted, which is a fantastic summary of where the network might be in a few years by Derick Winkworth. Then there's You Can’t Build A System In A Silo, a fantastic summary of what needs to be done to reorganize your IT by Ethan Banks. And here are all the other interesting links in somewhat random order:
If you’re attending the upcoming RIPE64 meeting in Ljubljana, don’t be late for my presentations (pretty early on Tuesday, April 17th) on Cloud Computing networking and Data Center fabrics. Later in the same week (April 19th), I’ll be presenting in the Server Guy’s Guide to Network Fabrics – a free webinar sponsored by Juniper. Finally, there’s the Cloud Computing Networking – Will It Scale? webinar in the last week of April.
Get your personal cloud fabric @ etsy.com
The proponents of Network Prefix Translation for IPv6 (NPT66) usually claim it’s required for one of the two reasons: to implement multihoming without BGP (valid) and to avoid renumbering inside network(s) when the ISP assigns you a new IPv6 prefix. Let’s focus on the renumbering claim today.
Last week Stephen Foskett and Greg Ferro brought back their merry crew of geeks (and a network security princess) for the third Networking Tech Field Day. We’ve met some exciting new vendors (Infineta and Spirent) and a few long-time friends (Arista, Cisco, NEC and Solarwinds).
Infineta gave us a fantastic deep-dive into deduplication math, and Spirent blew our socks off with their testing gear. As for the generic state of the networking industry, the “I’m excited” rating from last autumn changed to this (HT @reillyusa):
Trevor Pott wrote an interesting article in The Register (linking to my IPv6 multihoming post – thank you!) explaining how, in his opinion, IPv6 sucks for small and medium businesses. I wholeheartedly agree with some of his conclusions (actually, agreed with them for the last three years), but unfortunately the article contains several factual errors that simply have to be corrected (I doubt many of Trevor’s readers will actually find their way to this article, but one can always hope).