Blog Posts in August 2016
Have you written something about assessment and planning for migration of traditional in-premise data center network to private or public cloud? There would be hundreds of things to check during assessment and then plan accordingly.
Academically, that’s a wrong way of approaching the problem.
When I talk about network automation with enterprise engineers I usually get responses along the lines of “That’s interesting, but it will never happen in my organization. That’s what startups or cloud providers do.”
They couldn’t be more wrong: Thomas Wacker from UBS (one of the top 20 global financial services companies in case you don’t recognize the name) will describe how UBS uses network automation in new data center deployments during our Network Automation DIGS SDN event on September 1st, and we’ll spend the rest of the afternoon focusing on how you could get started and what your first network automation project should be.
Andrew wondered how one could scale the L3-only data center networking approach I outlined in this blog post and asked:
When dealing with guests on each host, if each host injects a /32 for each guest, by the time the routes are on the spine, you're potentially well past the 128k route limit. Can you elaborate on how this can scale beyond 128k routes?
Short answer: it won’t.
Software Gone Wild podcast is well into its toddler years and it was time for a teambuilding exercise. Just kidding – we wanted to test new tools and decided to discuss the vacation experiences and podcast ideas while doing that.
On a more serious note: we’re always looking for cool projects, implementations and ideas. Contact us at podcast (-the weird sign-) ipspace.net.
My “this is why you need automation” blog post triggered numerous comments and tweets. I loved this one:
What if the mistake was embedded into the automation process/tool (designed by humans) in the first place? Now you have a video series titled "Automation Gone Wild".
I guess this tweet is a priceless answer to that question:
One of my subscribers considered attending the Virtual Firewalls workshop on September 1st and asked:
Would it make sense to attend the workshop? How is it different from the Virtual Firewalls webinar? Will it be recorded?
The last answer is easy: No. Now for the other two.
Decades ago I got involved in another interesting project: let’s build our own file server operating system on top of Z80 CPU. Yes, I was at university (how did you guess?) and No, it never really took off.
Still basically the same old debate from 25 years ago that experienced Network Architects and Engineers understood during technology changes; "Do you architect your network around an application(s) or do you architect your application(s) around your network"
I would change that to “the same meaningless debate”. Networking is infrastructure; it’s time we grow up and get used to it.
I spent the last week creating numerous scenarios using Ansible networking modules for my upcoming Network Automation workshop. The scenarios use Cisco IOS and Nexus OS modules as I used VIRL for network simulation, but you could easily adapt them to other networking devices.
One of my users couldn’t get the inter-VRF NAT to work after watching the DMVPN webinars (no real surprise there, the VRF lite concept is covered in more details in the Enterprise MPLS/VPN webinar) so I decided to write a short document describing the details.
After the fantastic Docker 101 webinar by Matt Oswalt a few people approached me saying “that was great, but we’d need something more on Docker networking”, and during one of my frequent chats with Dinesh Dutt he mentioned that he already had the slides covering that topic.
Problem solved… and Dinesh decided to do it as a free webinar (thank you!), so all you have to do is register. Hurry up, there are only 1000 places left ;)
Failure to use DNS, IP addresses embedded in the code, ignoring the physical realities (like bandwidth and latency)… the list of mistakes that eventually get dumped into networking engineer’s lap is depressing.
It’s easy to reach the conclusion that the people making those mistakes must be stupid or lazy… but in reality most of them never realized they were causing someone else problems because nobody told them so.
After I completed the LAN-over-RS-232 project, it was obvious (well, not in retrospect) that the solution to every problem must be Z80 computers connected with some crazy RS-232 wiring. A few years later we had to write an application to support rally races. Guess what the solution was ;)
I stumbled upon a great description of how you can go bankrupt in 45 minutes due to a manual deployment process. The most relevant part of it:
Any time your deployment process relies on humans reading and following instructions you are exposing yourself to risk. Humans make mistakes. The mistakes could be in the instructions, in the interpretation of the instructions, or in the execution of the instructions.
And no, it's not just application deployment. A similar disaster could happen in your network.
It was early 1980s and I was just entering my MacGyver phase when someone asked me “could you make a local area network out of RS-232-based shared bus?” Sure, why not, it can’t be that hard…
I stumbled upon a great ACM article comparing challenges of distributed systems with well-known milestones of modern physics.
The modern networks are probably the ultimate distributed systems. Now take the ideas from that article and apply them to the Centralized Control Plane concept (the last time I checked the marketers were still promoting that academic marvel).