loopback0 – Douglas Gourlay's Blog Data Centers, Virtualization, and Cloud Computing

24Jul/094

Networking and Operations Focus

Again, suitably sub-titled, "things I'd like to change 3/N."

the day Altiris was installed...  (client retrospective)

the day Altiris was installed... (client retrospective)

When networking was in its hey-day growth phase in the mid-late 1990's through the dot-com crash of 2001 we were a nerdy group of people. We didn't have to worry about change control when the systems were not mission critical, we could use the classic "I tripped over the power cord" emergency change-control procedure. The advanced and automated ticketing systems were not in place, there was only one enable password, and we router jocks loved the fact that we were our own masters of the universe.

The features developed, delivered, and sold by the networking vendors catered to us, the operators, admin, engineers, etc. Think about them- the features we all remember and still tend to use were designed to make our jobs easier, not harder. Features like EtherChannel, speed/duplex auto-negotiation (although for many vendors that was a big #fail), IGRP/EIGRP (turn it on, it just works, for three desktop protocols, on one process!), VTP - okay, we all remember the VTP Bomb, but the concept of auto-propagation of VLAN ID and auto-pruning of unnecessary VLANs was nice although the initial implementation was rather like a liquid-center flourless chocolate cake.

What happened?

Why, since 2001 and the dot-com bust have networking vendors stepped away from supporting and embracing the loyal network operators and delivering features and capabilities that make their jobs easier and simpler and instead seem to focus on things that in many cases make the job harder. I mean, how many encapsulation types do I need? How many differing non-interoperable segmentation mechanisms? How many security tags/constructs/products with little integration? How many differing UIs and code-trains?

I like building things that make peoples jobs easier. It's a personal passion of mine, because they tend to get used and deployed, and heck- they make people happy! (as I write this 'Sweet Child o' Mine' comes on the overhead speakers and I have to pause a minute during one of the most memorable guitar solos ever...) ok, back on track... umm, where was I?

Oh yeah- features that make network operators lives easier?

One I always wanted to do was a global port profile. Basically an object oriented port based configuration that is synced across a reasonably sized autonomous system of network devices. Then I can make changes to the port object and have it sweep across the switches and be swiftly implemented. All the ports map to the object, the object is the point of change. This gets very interesting when it is integrated between physical and virtual devices so that I can have a policy that moves as I execute a P2V operation and maintains consistency regardless of where the workload runs.

Just a thought. I am sure there are more... any other things you wish your network did? (I also wish there were native Opsware agents on my network devices... for more food for thought...)

dg

sharing is fun
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Ping.fm
  • RSS
  • Slashdot
  • StumbleUpon
  • Suggest to Techmeme via Twitter
  • Technorati
  • Twitter

3 Tweets

Comments (4) Trackbacks (0)
  1. What a coincidence! I remember having commented on a similar subject, just a few weeks ago, after ten years of not touching the subject. I liked your comments, and couldn’t keep wondering what happened to the “active networks” http://www.sds.lcs.mit.edu/activeware/ from the standpoint of “push” configuration of all sorts across entire infrastructures (thinking now of VMotion-ing layer 2 and 3 virtual devices). I recall having tried some research, on my own, in 1999, focused on ANTS, and things appeared so exciting at the time – i.e. ‘Nirvana” for network operators (while nightmare for security people, of course) …

  2. Some power management stuff for IP phones/switch ports that Cisco and others have been propounding – based on time of day/activity monitoring, turn off PoE to IP phones and lower the power consumption of the connected switch ports. Keep policy configuration very simple (yes, via a GUI :-) ).

    • The phones would need a low-power mode where the buttons worked and when you pushed any button it would ‘come on’ and draw the required power from the switch. Have to balance emergency services availability (E911) with low power… if you coupled a lightweight signaling to the switch that the phones was the only port there then you could easily run at 10Mb or something that reduced the number of pars and kept the power draw low as well.


Leave a comment


No trackbacks yet.

Additional comments powered by BackType