Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

We Had SDN in 1993 … and Didn’t Know It

I had three SDN 101 presentations during last week’s visit to South Africa and had tried really hard to overcome my grumpy skeptic self and find the essence of SDN while preparing for them. As I’ve been thinking about controllers, central visibility and network device programmability, it struck me: we already had SDN in 1993.

In 1993 we were (among other things) an Internet Service Provider offering dial-up and leased line Internet access. Being somewhat lazy, we hated typing the same commands in every time we had to provision a new user (in pre-TACACS+ days we had to use local authentication to have autocommand capability for dial-up users) and developed a solution that automatically changed the router configurations after we added a new user. Here’s a high-level diagram of what we did:

HTML user interface (written in Perl) gave the operators easy access to user database (probably implemented as a text file – we were true believers in NoSQL movement in those days), and a back-end Perl script generated router configuration commands from the user definitions and downloaded them (probably through rcp – the details are a bit sketchy) to the dial-up access servers.

Next revision of the software included support for leased line users – the script generated interface configurations and static routes for our core router (it was actually an MGS, but I found no good MGS images on the Internet) or one of the access server (for users using asynchronous modems).

How is that different from all the shiny new stuff vendors are excitedly talking about? Beats me, I can’t figure it out ;) … and as I said before, you don’t always need new protocols to solve old problems.

More down-to-earth SDN thoughts

If you’re looking for grumpy down-to-earth perspective on SDN, join the SDN 101 webinar I’m running in January.


  1. You're the best Ivan! Perl ran a lot of networks, let's be honest...

  2. I try to separate "SDN" and "Network Automation." Automation has been around for decades now and I'd put this one under that, not necessarily SDN, even though people seem to like to spin it as SDN. SDN to me is driven by dynamic variables including applications.

    Now back in the mid-90s we did have RADIUS options controlling things like L2TP tunnels to redirect users to a certain path like walled gardens, web-filtering boxes, etc. Maybe you could call that SDN? Still a tortured interpretation IMHO.

  3. "We Had SDN in 1993 … and it didn´t make it" ;)

  4. We also had "cloud" computing in 1993-1995 Novell teamed up with AT&T to host Novell servers and lotus notes service from AT&T connected via frame relay.
    Worked then but slow fat protocol over thin VCs.. But it was touted in the old rags back then. How funny,

  5. There is a point here, this stuff is not "new". What about GSMP, MSF, FORCES, and even MEGAGO (diff. use context), etc. 10+years ago efforts, some of which are still superior in many ways (in terms both architecture, functionality and to the current "new" OpenFlow does it all for you BS ? For Stanford folks to market this as a new invention of theirs and take credit is ignorant and irresponsible - folks like Nick Mckeowns surely remember the previous attempts. The key problem with the industry is that everyone seems to have a self appointed "right" to come up with "new" protocol/interfaces for old things, and call it solution. No wonder folks get frustrated on the height of the RFC and other spec pile.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.