You are here: Home / Blog / Tired of Being Blamed, It’s not the Network, It’s the Operating System

Tired of Being Blamed, It’s Not the Network, It’s the Operating System

18th December 2012 by 15 Comments

Many people blame networking for not being able to support dynamic server movement in virtualised environment while conveniently forgetting that server operating systems haven’t changed their networking software in twenty plus years. I think that a lot of the blame should be apportioned to operating system vendors.

Many times over the last decade, the IETF has discussed the shortcoming of the IP protocol and solutions proposed. But operating systems vendors, especially server operating systems, have refused to consider change.

Networking people have known since mid-1990′s that TCP/IP does not support mobility and have developed many alternative protocols such Mobile IP that solve this problem. Microsoft and other vendors have failed to implement these protocols, or to take such option seriously.

The ultimate technical problem is that IP and Ethernet was intentionally designed, 35 years ago, to be static and immoveable. Addressing mechanisms such as ARP and DNS assumed that device movement was the exception and thus an RPO/RTO of four hours was just fine. To solve the root of the problem requires changing DNS, DHCP, TCP/IP and every protocol stack of every server and every device.

Of course, this won’t happen. Instead, we have to change every networking device  - firewalls, routers, switches and completely overhaul the software that is used.

So while server administration is basically unchanged at the hardware and software level, every one expects networking gets a full overhaul without changing anything. You can see the problem.

The EtherealMind View

Keep this is mind while you are complaining that the network doesn’t do what you want ? It’s because your operating system has never implemented the features that you needed.

Blame them. And be nice to your networking guy as he works to overcome your shortcomings.

Filed Under: Blog, Featured
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://twitter.com/cloudtoad Derick Winkworth

    Yes. Yes, and yes. You should supplement with some technical material. I’ll even give you some.

    • http://etherealmind.com Greg Ferro

      Send it over and I’ll post a followup.

  • http://thenetworksherpa.com/ john harrington

    Oh man, this is so totally true. It’s strange that the network is the most fundamental and critical layer but is often seen as the path of least resistance for change.

    Enter fabricpath and TRILL. Expensive complexity bought by network teams to mask server intransigence. I’m just delighted that hypervisor-based overlay solution is gaining ground. At least the complexity is moving back toward the edges of the network.

    • Jeff McAdams

      I would take it even further and point out that TCP/IP is actually quite *good* at IP mobility from a pure IP standpoint. Its only when you get into that messy interface with ethernet do things get tricky. But IP as a pure play solved IP mobility through dynamic routing protocols like OSPF and BGP decades ago.

      There is similarity to the argument put forth in the post, though…its server OS networking stack stagnation and server admins’ intransigence that prevents the use of these well debugged protocols to enable system mobility that most enterprise admins can’t even dream of.

      “Anything you can do at layer 2, I can do at layer 3…better.”

    • http://twitter.com/tbourke tbourke

      I agree with the overall sentiment of the article, but I disagree TRILL/FabircPath adds complexity. Compared to STP, it dramatically reduces complexity while bringing Ethernet forwarding into the 21st century. FabricPath and VCS (Brocade’s TRILL-based implementation) configurations are stupid simple compared to STP.

      • http://thenetworksherpa.com/ john harrington

        Fair point. The TRILL teams did a great job hiding all that complexity from the users, but it’s still new silicon. I’m not sure a smarter core is a good idea, but that’s just my take on things.

  • http://twitter.com/DmitriKalintsev Dmitri Kalintsev

    There’s always a selection of open source OSes, where anything you can imagine can be implemented, if one so desires.

    Not too sure if assigning blame to the “OS Vendor” would work in this case.

    • http://etherealmind.com Greg Ferro

      But none of the Linux vendors adopted them. And none of the “system administrators” have ever bothered to adapt their platforms.

      Linux is equally to blame, even if solutions have been offered there.

  • Alexandra Stanovska

    There is still hope – all you have to do is just change the protocol. So maybe there’s a chance of Doing It Right(TM), this time. (Am i overly optimistic?)

    • http://etherealmind.com Etherealmind

      I’ll say overly optimistic. History tells us that OS vendors are too lazy to face to this challenge.

  • Matthew Walster

    Personally, I think the core problem is that the servers are using virtual ethernet interfaces. Why? I’d have thought that the smart option would have been to use some kind of unumbered virtual serial link that the data appears on/leaves through, and to announce which IPs it has configured to the hypervisor.

    What you can then do is redistribute the routes from the hypervisor into your IGP. If you summarise per hypervisor, you can keep the routing table size low, and when you migrate a VM to another host, it’s only one additional host, which might be summarised even further up the tree.

    Is there any obvious reason as to why this doesn’t happen other than a disregard for networks in the design in the VM world?

    • http://etherealmind.com Greg Ferro

      I blame the IEEE for taking too long to develop decent standards. The lack of urgency in delivering VEB or VEPA means that vendors have moved to cover the innovation gap. Today, anyone and everyone are creating new standards via the IETF, with literally dozens of new approaches to virtual networking.

    • Jeff McAdams

      I 100% agree with you…this would have been a fantastic design.

      And, yes, I believe the reason is a disregard for networks in the design in the VM world.

      Its time Hypervisor vendors face facts, they *are* a network device (amongst other categorizations that fit) and need to start supporting more advanced network capabilities than just 802.1q…and preferably start moving up the layers, ie, be an IP router and support OSPF, BGP, maybe even MPLS and *all* of the problems of data center design that are trying to be solved by TRILL, VXLAN, and the various other reinventing-the-wheel-technologies being designed today just disappear by using protocols that have been in use for years and in some cases decades.

  • Sam Stickland

    I perceive two main issues with mobility and the host operating systems.

    1) There is no Layer 5 (session layer). Applications bind directly to the Layer 3 IP address which actually just represents a single interface’s Point of Attachment in the routing hierarchy. If would be better if applications bound to a layer 5 address, that represented the host, and then the network would dynamically bind this to whatever Layer 3 addresses are appropriate at the time. The applications are only ever aware of the Layer 5 addresses and never deal with the Layer 3 addresses (in exactly the same way that applications today are only ever aware of the Layer 3 addresses and never deal with the Layer 2 addresses).

    Adding a session layer would mean altering the IP stack on every host out there.. sigh.. So we don’t have a layer 5 (session layer) but…

    2) ..there is a dynamic binding between layers 2 and 3 (ARP and ND). This means people have been using the Layer3 address as the permanent node identifier, and allowing the network to dynamically bind this to whatever Layer 2 address is appropriate. Unfortunately Layer 2 was designed to learn addresses by flooding and fails open, and creating large scale Layer2 domains is problematic. Properly fixing this (removing broadcast and unknowns) would require a new host/network protocol that registers the MAC/IP binding with the network… which means altering every host out there… sigh…

    This is why I think LISP is quite ingenious. It provides a Layer 5 that can initially be implemented in the network, but can eventually be implemented in the Hypervisor, and then eventually in the host (LISP mobile node). It’s a backwards compatible way of shoe-horning in the layer, but _eventually_ I think it needs to be implemented on the hosts.

    And… I think there’s a damn good reason Cisco haven’t LISP enabled the 1000V yet – it would stop all those the sales of all that shiny expensive TRILL and OTV capable hardware!

    • Jeff McAdams

      >There is no Layer 5 (session layer). Applications bind directly to the Layer 3 IP address which actually just represents a single interface’s Point of Attachment in the routing hierarchy.

      Yes, but you can approximate a layer 5 sort of behavior by using addresses on loopback interfaces. Then its merely a matter of figuring out how to signal to the network where that layer 5-ish address exists. There are multiple ways of skinning that cat that puts the management onus in different places (static routes in upstream routers, participate in the network’s IGP using OSPF or the like, talk to the network as if you were a “customer” of the network using BGP perhaps?…there are surely other ways). We’re using OSPF and BGP…moving to more BGP and less OSPF…and it works fantastically.