For an overview of this problem, watch this free video from the IPv6 microsegmentation webinar, for more details, watch the IPv6 Security webinar.
Matt Oswalt wrote a great blog post complaining about vendors launching ocean-boiling solutions instead of focused reusable components, and one of the comments his opinion generated was along the lines of “I thought one of the reasons people wanted SDN, is because they wanted to deal with The Network – think about The Network's Performance, Robustness and Services instead of dealing with 100s or 1000s of individual boxes.”
The comment is obviously totally valid, so let me try to reiterate what Matt wrote using Lego bricks ;)
Last week I published slide decks for Network Function Virtualization, BGP-Based SDN Solutions and SDN Use Cases webinars – they’re available to subscribers and attendees registered for individual webinars.
One of the topics I’m addressing in the Enterprise IPv6 101 webinar (after all, it’s an introductory-level webinar) is the question of “what exactly is IPv6”. After all the promises, myths, in the end it turns out all we got were bigger addresses (and ton of additional complexity).
A recent well-publicized network outage prompted someone to start collecting fat-finger horror stories, and dozens of networking engineers were quick to chime in. Enjoy!
My Business Case for SD-WAN blog post received numerous comments pointing out the potential pitfalls of hybrid WAN, including reduced security, unreliable Internet services and denial-of-service attacks.
While all those comments are perfectly valid, I still think hybrid WAN (whether implemented with traditional technologies or SD-WAN products) makes perfect sense.
I found a great explanation for hodgepodge of kludges found in "organically grown" solutions (legacy precursors to SD-WAN come to mind):
In a long-lived project, components are being replaced. Nice reusable components are easy to replace and so they are. Ugly non-reusable components are pain to replace and each replacement means both a considerable risk and considerable cost. Thus, more often then not, they are not replaced. As the years go by, reusable components pass away and only the hairy ones remain. In the end the project turns into a monolithic cluster of ugly components melted one into another.
Note: You really should read the whole blog post.
Most people casually involved with virtual appliances and network function virtualization (NFV) believe that replacing Linux TCP/IP stack with user-mode packet forwarding (example: Intel’s DPDK) boosts performance from meager 1 Gbps to tens of gigabits (and thus makes hardware forwarding obsolete).
Having data points is always better than having opinions; today let’s look at Receiving 1 Mpps with Linux TCP/IP Stack blog post.
2015-07-18: The blog post was updated based on feedback by Kristian Larsson.
“Daddy, why is Internet not working even though I have good signal?”
“You really want to know?”
“OK, let me draw a diagram or two ;)”
… and now my 8-year old knows how DHCP and DNS works (root cause was a broken DNS proxy running on upstream $0.99 WAN router).
One of my readers sent me an interesting reliability design question. It all started with a catastrophic WAN failure:
Once a particular volume of encrypted traffic was reached the data center WAN edge router crashed, and then the backup router took over, which also crashed. The traffic then failed over to the second DC, and you can guess what happened then...
Obviously they’re now trying to redesign the network to avoid such failures.
Engineers developing open-source wireless mesh network protocols and solutions get together every now and then to test the performance of competing mesh network ideas.
A month ago I was asked to deliver a short presentation on “something interesting about networking” at my local university. The temptation to talk about network automation and SDN was huge, but I quickly figured out that would make no sense (the audience were students in their freshman year) and decided to talk about a fundamental question: why should a programmer care about networking.
The problem with MPLS and similar technologies is that they weren’t designed with today’s business challenges in mind. Today, a company may need to launch an overseas R&D office overnight, or it may acquire a startup and want to immediately network with offices in distant regions and countries. Older technologies just don’t have the flexibility to do this on the fly.
Not surprisingly, the above paragraph triggered a severe case of Deja-Moo.
While some people lament the lack of IPv6 business case, others are busy rolling it out – you (RFC 2119) SHOULD check out the Status of Swisscom’s IPv6 Activities presentation from recent Swiss IPv6 summit.
Ethan Banks recently wrote a nice blog post detailing the benefits and drawbacks of traditional routing protocols and comparing them with their SD-WAN counterparts.
While I agree with everything he wrote, the comparison between the two isn’t exactly fair – it’s a bit like trying to cut the cheese with a chainsaw and complaining about the resulting waste.
The responses of Internet Service Providers (ISPs) to lack of IPv4 address space range from outright denial (sometimes coupled with reassuringly-expensive large-scale carrier-grade NAT) to all-in IPv6-only designs using 464XLAT for residual IPv4 connectivity.
An anonymous commenter wrote this comment to my initial SD-WAN post:
I can still hardly imagine the business case behind SD-WAN. Any thoughts?
This question is really easy to answer. There’s a huge business case that SD-WAN products are aiming to solve: replacing traditional MPLS/VPN networks with encrypted transport over public Internet. However…
Gabi Gerber (the wonderful mastermind behind the Data Center Day event) is helping me bring my Designing Infrastructure for Private Clouds workshop (one of the best Interop 2015 workshops) to Switzerland.
This is the only cloud design workshop I’m running in Europe in 2015. If you’d like to attend it, this is your only chance – register NOW.