Blog Posts in December 2015
All the Best in 2016!
The number of visits to my web site is slowly going down – you’re giving me a very clear signal that it’s time to stop blogging.
I hope you’ll manage to catch at least a few quiet days with your loved ones and I wish you all the best in 2016!
More in 3 weeks or so ;)
Broadcom Tomahawk 101
Juniper recently launched their Tomahawk-based switch (QFX5200) and included a lot of information on the switching hardware in one of their public presentations (similar to what Cisco did with Nexus 9300), so I got a non-NDA glimpse into the latest Broadcom chipset.
You’ll get more information on QFX5200 as well as other Tomahawk-based switches in the Data Center Fabrics Update webinar in spring 2016.
Here’s what I understood the presentation said:
Leftover Training Budget? Let Me Help You
If you have some leftover training budget for 2015, there’s no better way to spend it than to invest it in a workgroup ipSpace.net subscription ;)
You can choose between two standard packages (6 or 21 users) which include online consulting sessions, or create your own customized package.
Finally, if you plan to buy one of the standard packages, hurry up – the Dec15 promotional code gives you 10% discount till the end of the year.
Running Open Daylight in Production Network on Software Gone Wild
Nick Buraglio used OpenDaylight and OpenFlow-enabled switches to build a part of the exhibition network of a large international supercomputing conference and was kind enough to talk about his real-life experience in Episode 47 of Software Gone Wild.
We covered:
CPLANE Networks on Software Gone Wild
When I wrote a blog post explaining the difference between centralized control and centralized control plane, John Casey, CEO of CPLANE Networks wrote a comment saying “yeah, that’s exactly what we’re doing.”
It took us a while to get the stars aligned, but finally we managed to sit down and chat about what they’re doing, resulting in Episode 46 of Software Gone Wild.
The Grumpy Old Network Architects and Facebook
Nuno wrote an interesting comment to my Stretched Firewalls across L3 DCI blog post:
You're an old school, disciplined networking leader that architects networks based on rock-solid, time-tested designs. But it seems that the prevailing fashion in network design and availability go against your traditional design principles: inter-site firewall clustering, inter-site vMotion, DCI, etc.
Not so fast, my young padawan.
Let’s define prevailing fashion first. You might define it as Kool-Aid id peddled by snake oil salesmen or cool network designs by people who know what they’re doing. If we stick with the first definition, you’re absolutely right.
Now let’s look at the second camp: how people who know what they’re doing build their network (Amazon VPC, Microsoft Azure or Bing, Google, Facebook, a number of other large-scale networks). You’ll find L3 down to ToR switch (or even virtual switch), and absolutely no inter-site vMotion or clustering – because they don’t want to bet their service, ads or likes on the whims of technology that was designed to emulate thick yellow cable.
This isn't the first time that readers have asked you about these technologies, and it won't be the last. Vendors will continue to market them despite their shortcomings, and customers will continue to eat them up.
As long as there will be someone willing to believe in fairy tales and Santa Claus, there will be someone dressed in red coat and fake beard yelling “Ho, Ho, Ho!”
Enterprise IT managers sometimes act like small kids. They don’t want to hear that they have people- and process problems, and love to believe that the next magical bit of technology will solve whatever it is that bothers them. Vendors obviously love to explore these cravings and sell them ever-more-complex solutions.
I'd like to think that vendors will also continue to work out the kinks and over time the technology will become rock solid and time-tested.
I am positive you can make any technology almost-rock-solid. You can also make pigs fly (see RFC 1925 sect. 2.3). However, have you included the fuel costs in your TCO?
Also, the more complex a technology is, the likelier it is to crash down like a house of cards, and you’ll be left with an incomprehensible mix of bits and pieces that will be impossible to put back together (see also: You can’t reformat your data center).
Nino concluded his comment with a question:
Are you too stuck on past, traditional designs and not being open to new ways of building IT? I get that IT is very cyclical, and these new trends may die in the future...or thrive, and the customers may either fail...or succeed.
I am very open to new ways of building IT. I preach the need for meaningful SDN (not the centralized control plane crap), network automation, and proper application architecture. I just refuse to believe in fairy tales, and solving non-technical problems with technology.
Finally…
Looking for more red pills? Explore my SDN webinars, Designing Active/Active Data Centers webinar, and vMotion-related blog posts.
Featured Webinar: vSphere 6 Networking Deep Dive
The featured webinar of December 2015 is vSphere 6 Networking, a 6-hour deep dive into vSphere 6 networking features covering almost every single vSphere network-related feature.
What does this mean?
Trial subscribers get free access to select videos from this webinar (those marked with a yellow star in this listing) and can purchase it at significant discount.
Should We Use OpenFlow for Load Balancing?
Yesterday I described the theoretical limitations of using OpenFlow for load balancing purposes. Today let’s focus on the practical part and answer another question:
@colin_dixon @ioshints and for a fair comparison: Would a $100k OF switch be able to act as proper LB?
— Kristian Larsson (@plajjan) December 3, 2015I wrote about the same topic years ago here and here. I know it’s hard to dig through old blog posts, so I collected them in a book.
Could We Use OpenFlow for Load Balancing?
It all started with a tweet Kristian Larsson sent me after I published my flow-based forwarding blog post:
@ioshints sure but can't OpenFlow be used to implement an LB? It feels like a mix of terms here
— Kristian Larsson (@plajjan) December 3, 2015Why Do We Need VXLAN (and What Is It)?
Do you need VXLAN in your data center or could you continue using traditional bridging? Do layer-2 fabrics make sense or are they a dead end in the evolution of virtual networking?
I tried to provide a few high-level answers in the Introduction to VXLAN video which starts the VXLAN Technical Deep Dive webinar. The public version of the video is now available on ipSpace.net Free Content web site.
Sometimes It’s Not the Network
Marek Majkowski published an awesome real-life story on CloudFlare blog: users experienced occasional short-term sluggish performance and while everything pointed to a network problem, it turned out to be a garbage collection problem in Linux kernel.
Takeaway: It might not be the network's fault.
Also: How many people would be able to troubleshoot that problem and fix it? Technology is becoming way too complex, and I don’t think software-defined-whatever is the answer.
Is Flow-Based Forwarding Just Marketing Fluff?
When writing the Packet- and Flow-Based Forwarding blog post, I tried to find a good definition of flow-based forwarding (and I was not the only one being confused), and the one from Junos SRX documentation is as good as anything else I found, so let’s use it.
TL&DR: Flow-based forwarding is a valid technical concept. However, when mentioned together with OpenFlow, it’s mostly marketing fluff.
Detecting NAT64 Prefix
If you’re a host running on an IPv6-only network, you might want to detect the IPv6 prefix used for NAT64 (for example, to transform IPv4 literals a clueless idiot embedded into a URL into IPv6 addresses).
Apple has a wonderful developer-focused page describing NAT64 and DNS64, including the way they synthesize IPv6 addresses from IPv4 literals. You (RFC 6919) MUST read it.