At a recent Gartner event, several colleagues were discussing the first networks we worked on. Coincidentally, well-known network blogger Ivan Pepelnjak blogged about the first computer network he worked on. So this inspired me to get some of this written down…
Andrew Lerner/ My first network was… back around the time of Chumbawamba, we were upgrading the WAN for a large federal government agency. It was an IT Modernization effort moving from Banyan Vines running over X.25 to Lotus Notes over TCP/IP on Frame Relay. I learned more about X.121 and DLCIs then you’ll ever need and racked up a ton of frequent flier miles doing international installs. Things I learned
- WANs were very expensive, mission critical and provided relatively limited performance. Still applies today although I would add brittle to the mix today.
- It’s all about context…the end-users were delighted to have 128K Frame Relay Lines (they were coming from 9.6 kbps.
- Outages happen, even to big Carriers.
- Do not attempt to carry-on a Cisco 2500 router thru airport security in foreign countries. Similarly, customs does not laugh when you tell them a Cisco 1600 router is a “big alarm block”
Joe Skorupa/ My first network was…a 3 node async terminal statistical multiplexor net for a Big 10 University. It supported the bookstore and the athletic ticket office. Things I learned:
- The muxes reliably delivered 100% of traffic when set for a 9.6Kbps second link,
- But it delivered only some of the traffic when set for the supposedly supported 19.2Kbps link speed. This was my first encounter with vendor math.
- The bookstore was a profitable business for the University. If Alumni couldn’t get their basketball tickets, millions of dollars of donations disappeared. Thus, the managers of those two customers could get me fired quicker than my own manager could.
- Stop trying to force the vendor to fix a fundamental design flaw. Back down the speed, declare victory and keep my job.
Thirty years later, the world looks remarkably similar (+1 from me).
Network Manager from the Retail Industry/ My first network was…in the Late 1990s, working on a regional hospital network which included 10mbps Ethernet, IBM token ring and a 128kbps ISDN BRI Internet line. The network ran IPX, TCP/IP, AppleTalk and DECNet. The hardware included switches from four different vendors and the routing protocol was RIP. As you might expect, it was problematic and offered me a great opportunity to learn. My take: A far-too-common, but good example of network incrementalism and accrual of technical debt (fragility).
Director at a VAR, focused on Federal Government/ My first network was…a government network in the 1990s, supporting the usual office applications, Microsoft servers, 500+- users, WAN and MAN connectivity including microwave , Novell Groupwise (you get the idea). The average user login would take 15-17 minutes (yes, minutes). Thus, employees couldn’t do anything and it had been up and running for about 1.5 years and it was just horrendous! They’d come in to the office, put their stuff down, log in, and leave for a half hour (plenty of time to discuss the prior night’s episode of Roseanne or Home Improvement). Within minutes, I started troubleshooting (at Layer 1, where else) and reached behind the desk and grabbed what felt like telephone wire. Dropped that cable and fished around for the network cable, but turns out that was the network cable. It was Cat3 and it was about 35′ long. My next question, “are you guys running any of the Novell protocols, IPX, Novell print services on your network?”. Their answer, “we don’t know“. Long story short, we removed miles and miles of Cat3, turned off all of the un-necessary chatty Novell protocols, fixed a few hundred duplex mismatches on their equipment and things started to look up. A few weeks later, a lady from cube-land kicked the conference room door open and shouted. “Who did this to the network?” I was sure that we were going to get fired on the spot, but quite the opposite – She was blown away. The average login time went from 17 minutes down to about 5 seconds. What I learned that still applies today:
- Follow a layered troubleshooting approach and never sleep on the physical layer
- The network is meant to support apps, but that doesn’t mean apps were written with the network in mind.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.