You Must Understand the Fundamentals to Be Successful

I was speaking with a participant of an SDN event in Zurich after the presentations, and he made an interesting comment: whenever he experienced serious troubleshooting problems in his career, it was due to lack of understanding of networking fundamentals.

Let me give you a few examples: Do you know how ARP works? What is proxy ARP? How does TCP offload work and why is it useful? What is an Ethernet collision and when would you see one? Why do we need MLD in IPv6 neighbor discovery?

Networking is already commoditized enough that most engineers never truly master the fundamentals (it's one thing to hear about ARP in a CCNA class and completely another one to troubleshoot an interesting proxy ARP problem caused by overlapping subnets), but it’s only getting worse.

In the SDN world, the networking infrastructure will become ever more complex, and you’ll experience totally unexpected interactions between controllers, controlled network devices, and attached end hosts. The deep understanding of the fundamentals will be the only way to ensure you’ll successfully fix problems in your SDN networks, regardless of the clueless marketing VPs telling you how we no longer need networking engineers.

The lack of understanding of technology fundamentals, and their impact on solutions we’re trying to deploy in our networks was one of the primary reasons I started creating webinars. Have you tried the free introduction to SDN? Did it work for you? Need more details? Check out the advanced SDN track, and get access to all webinars with the yearly subscription.


  1. I agree with you, I think for being a good engineer or any other profession, you have to have a strong foundation and solid learning.
  2. Agree completely. But is not main purpose of SDN is to to make debugging & troubleshooting easy from centralized location ?. If one needs large set of high quality network engineers then why would one choose complex SDN deployments at all ?
    1. I have yet to see an SDN system that would be less complex than well-designed traditional IP routing. Do I need to say more?
    2. I think the idea is to deploy faster, not to debug/troubleshoot easier. Having a way to tap into the network at any spot via a controller is nice, but it doesn't solve all issues. At some point there will probably be a bunch of third-party and/or native tools to make things easier, but visibility into the forwarding (which seems to be the selling point of SDN solutions in terms of troubleshooting) is not be-all end-all of troubleshooting solutions.
    3. I agree, SDN and NFV are being primarily driven by businesses faster time to market and CAPEX reduction requirements. I'm willing to bet no consideration was given to network management, operational complexity and its impact on support costs and customer experience.

      SDN is also a vague term that seems to encompass all areas of networking. It would be more valuable if the problem was decomposed into different areas for example SDN for data centre, for campus and for WAN or break it up into Edge vs Core SDN. In my opinion these areas would have significantly different solutions.
  3. It's all about the protocols, know your protocols and you will be solid.

    Nope Ivan you need not say any more. Spot on. Just reading the Cisco Press "The Policy Driven Data Center with ACI" and to be frank on first purse what a mess.

    Forget about the HW ASIC+ on the 9k and all the juggling between the NFE, ALE, ASE and Buffer boost, odd over subscription and a recast version of what sounds like WFQ, plus your previous ACI posts. Look at how this is all orchestrated and controlled between the APN profiles, Tenants and EPGs, subjects, contracts, lables, bundles special multicast EPGs and all the rest of the Progresso soup and you wonder WT@#%$%^ were they thinking. I think in one of your older posts you called it spaghetti ;) See chapter 3 The Policy Data Center and chapter 4 Operational Model and you will see what I am talking about. I do get it and it makes sense but you think they could have come up with a better approach/system to simplify.

    1. This is the fundamental issue with all these lovely abstraction tools I have seen - the end result of simplicity for the service consumer can be present but at the expense of immense complexity on the provider side.
      As Ivan says these marketing VPs are blind to this, yes we might need fewer level 1 folk to provision services but the level 2 & 3 people need to be more skilled / expensive than before.
  4. Great post Ivan. The design and deployment is getting more complex with additional integration points in the SDN world (virtual machine managers, orchestration, automation tools etc.). While automation has the potential to reduce the number of network engineers during the run/operate phase, when things go wrong (and they often do), you will need a specialist with sound fundamentals to fix the problem. All this means network engineers need deeper as well as wider skills to survive the brave new world.
    1. That's why in most telcos there are different operational groups for initial deployment and ongoing maintenance and support. If you are going to deploy SDN without a proper SDLC, then best of luck.
  5. I just went through some Cisco webinar, I believe it was on VIRL and they were showcasing the use of the API and python to add a vlan. I do some Python myself and have used the NXOS api for some simple devops menu like use. But for the most part if you are an enterprise and have Prime DCIM to use to add vlans for example why go through the coding process. It was a bad example IMHO.
    1. It depends on where you are in your IT automation journey.

      If you're still deploying everything by hand, and hand-crafting VMs from ISO images, then DCIM is the way to go. It gives you a somewhat consistent view of your data center, and you can deploy something like a VLAN across multiple boxes without ever logging into one.

      If however your server/application people got further along on their path toward DevOps, they might start getting annoyed that they can deploy a VM in 5 seconds, but it still takes dozens of GUI clicks to get a new VLAN deployed. In those environments the need to program networking devices becomes pretty urgent.

      Hope this helps,
Add comment