It's One of Those Opinionated Days Again

The 3rd in the Series

It's One of Those Opinionated Days Again The 3rd in the Series I have this long list of possible blogging topics, but a lot of them just don't seem significant enough for a single blog. So, since it's worked before, I thought I'd just run through a bunch of them. Sort of cleaning up my list.


Virtual Network Operators (VNOs) are an interesting niche in the telecommunication market. VNOs essentially patch different provider networks together for you into a single service. Instead of hiring someone to cut your lawn, someone else to edge, and someone else to clean, you just hire a complete lawn service. VNOs buy telecom services from many different providers - usually the best at wherever site you want services at - and tie it together via their own systems. So, you could have a single global MPLS network from a VNO that is really a conglomerate of MPLS VPNs from AT&T, Verizon, BT, Sprint, and a bunch of other little providers. If you are poor at WANs (routing, circuit provisioning, QoS, network management, contracting), VNOs might be a good solution for you. Also, VNOs are very good at providing services in many parts of the world that your current incumbent carrier may be having problems reaching (or may be wanted to charge you a ton of money for.) Be warned though, VNOs work at the lowest common denominator, particularly with QoS. You lose functionality for increased simplicity.


Do strategic customer/vendor relationships drive your vendor selections? For example, you really want to buy some new IT gear from vendor A because they have the best technology and lowest cost. But, big ol' vendor B buys a ton of your company's product. All the financial data and technical testing points to A, but your company's executives swoop in at the last moment and demand B, insisting B would cancel all orders with your own company should you select A. So you get B and their product stinks. Don't you just hate that?


Despite all the industry pundits saying technology is getting easier, it's not. Single point technologies may get simpler, but we live in an integrated world. Technology integration takes expertise in at least one area (let's say networking) and a lot of experience in others. This leads to a high-level idea about IT organizations. In general form we have the managers and the engineers; or management and technical; you get the idea. But this limits a lot of individuals who want to progress to higher and higher levels of responsibility, but remain technically oriented. At some point, you have to give in and be a manager. What about another approach, similar to hospitals. There you have the doctors (I hope the most technically oriented) also leading the projects (operations), dealing with the customers (patients), and leading the teams (ever seen the horde of people on daily rounds?). Yes, there are hospital administrators, but the core work is done at the doctor level, led by the technical experts. Think that would work in IT?


You might have some really good physical designs in your campus network, all based on templates. Each switch has dual uplinks to a distribution layer with dual uplinks to a core. You use interfaces on different blades for redundancy and monitor all links. Too bad all your fiber actually hub-and-spokes out of the same building on the campus. Or, all of fiber between the building runs through a single conduit down the middle of the campus (where, it just so happens, there's a lot of digging going on lately). I'm shocked how often campus fiber plant designs are so opposite from the pretty Visio diagrams we draw showing the perfect Cisco Campus design. Like the time GM's global data center in Detroit was isolated from the network because both strands of an OC-48 SONET ring ran down the same conduit a contractor blow-torched (true story from my past). Yep, a perfect OC-48 with dual strands, redundant COs, and a HA fiber mux. All worked for crap when the single conduit (along with the fiber cable inside of it) was melted 2 feet in each direction. A lot of campus fiber designs are made by the building management people, not IT. They are going for simple and low cost. You should know these designs very well. They can haunt you.


Despite creating a great written network architecture with design templates and an architecture review board to make changes, it really doesn't matter if the actual network is not configured to match all those standards. One of the biggest reasons for this dichotomy of standard vs. actual configurations is simple entropy. As things happen, outages occur, and people do things, entropy enters the network. Few operations teams have time to go back and clean things up or the time to manually audit the existing configurations. Often, you fine that OSPF command in your written standards missing during that P1 outage at 2 AM on Sunday morning. Automating these audits should be a top priority for a network team. There are expensive tools that can do it, open source tools, or just write your own scripts in Perl/Python/Expect. Any way you can audit the actual configuration in the network will lower your outages in the future. This is proactive network management.


This was fun this week....I might have to do a few more weeks of these....clean up my list.

More >From the Field blog entries:

A Private Extranet for Cloud Computing

It's Really Only Partly Cloudy Out There

Networking in the (Thunder) Clouds

Networking in the (Storm) Clouds

How to Save Some $$$s - Keep Competition in Your Network

You Knew I Had to Comment on the Cisco Certified Architect Program

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2009 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)