Network and Telecom Strategies Blog

Please Install Network Taps!

Posted by: Eric Siegel

(I see that today I'm just full of exclamation marks in my titles!)

Anyway...

I have a report coming out in a few weeks, "Network Tapping and Flow Tracing Tools" and a portion of it discusses network taps and "SPAN" (Switched Port Analyzer) ports, which are also called "mirror" or "monitor" ports.

A monitor port is a port on a switch, router, virtual machine processor, or other device that can be configured to copy (or “mirror”) the data from another of the device’s ports or from an otherwise inaccessible data path inside the device. A diagnostic or measurement tool can then be plugged into the monitor port to examine the data flow.

In contrast, a tap is not embedded in network or host equipment. Instead, it's a low-cost physical device that passively, and invisibly, intercepts traffic on a WAN or LAN link. Taps can be electrical, for copper WAN links and Ethernet, or they can be optical, splitting some of the light energy from an optical fiber.

Most enterprises don't install taps; instead, they use the existing monitor ports to connect monitoring equipment and intrusion detection and management equipment. This is a mistake.

While I was talking with tap vendors over the past few weeks, I was struck by how often they commented that enterprises just don't focus on the need for taps. So here are a few reasons that the small investment in a tap infrastructure pays BIG dividends, especially when you have a intrusion incident or diagnostic crisis: 

• Taps do not drop packets. Monitor ports may drop frames, especially under heavy load, because they handle frame monitoring at a lower priority than their primary function. This can be irritating, because it always seems to happen precisely when your network is being flooded by a problem or intrusion.

• Taps do not remove errored frames (e.g., short frames, jabbers); the diagnostic tool can see exactly what is on the communications link, errors included. Monitor ports don't see errored frames because they're removed as they enter the switch or router, long before the monitor port sees them. If errored frames are causing congestion, your diagnostic tools won't see them at the monitor port.  

• Most taps can multicast to multiple output ports, allowing more than one diagnostic tool to see the data flows. That's extremely useful! It's wildly irritating to race into a server room with screaming managers on your tail, and then discover that some mystery cable is plugged into the switch's sole monitor port. What does that cable do? If I unplug it, so that I can plug in my trace tool, what is going to break? Aaargh. Time wasted, tracing cables to figure out what is going on. It's much nicer to have an extra port on the tap! 

• Some taps can filter the traffic, decreasing the volume that the diagnostic tool must cope with. They can provide that function without using a network device’s limited processing capabilities.

• Some taps can combine traffic from multiple sources into one output port for the monitoring tool, possibly adding source identification and hardware time stamping to the frames.

Well, there's a lot more about taps and monitor ports -- and about matrix switches, storage, and trace tools, etc. But you'll have to wait for the report! (If you desperately need it now, and you're a Burton Group client, send me an email and I'll give you a pre-publication copy, of course.)

Time to inventory your IPv4 Addresses!

Posted by: Eric Siegel

I see that Mike put up a blog post about IPv6 ("And you think 2012 will be a problem...") mentioning that I'm working on a paper about IPv4 address exhaustion and the resulting need to be prepared for IPv6-only Internet users.

An important consideration for all enterprises is that, starting in 2009, some Regional Internet Registries (RIRs) began to formalize mechanisms for the transfer of address blocks subject to RIR approval. That allows the appearance of a market in address blocks.

The address block market will peak as the IPv4 address shortage becomes extreme after 2012, then gradually decline as IPv6 gains popularity. Large blocks of addresses, which had no financial value previously, will need to be inventoried and appear as an enterprise asset. (Larger blocks will be more valuable than an equivalent number of addresses in smaller blocks.) In some cases, enterprises may re-number their internal networks to create large address blocks that can then be sold.

So, if you have no idea how many IPv4 address blocks you own, or which ones are used, the time has arrived for you to start an inventory. IPv4 address blocks will suddenly have financial value, and you might even want to consider selling them in a couple of years to an enterprise that hasn't planned ahead and suddenly needs IPv4 addresses but can't get them from their ISP. (That won't be YOU, of course....)

By the way, you can talk with Mike in person about IPv6 and IPv4 at the upcoming Catalyst Conference in Europe on April 19-22. He'll be there!

If you're interested, here are some of the RIR regulations governing transfer of IPv4 blocks:

RIPE:

http://www.ripe.net/ripe/docs/ripe-484.html#55

ARIN:

https://www.arin.net/resources/request/transfers.html ("Transfer of released number resources")

http://lists.arin.net/pipermail/arin-ppml/attachments/20090406/b8a75e31/attachment.pdf

APNIC:

http://www.apnic.net/policy/proposals/prop-050

Out of the Blue: HP Acquires 3Com

A huge surprise (for some of us, at least) was yesterday’s announcement of HP’s intent to acquire 3Com.  This is obviously intended to give HP more in the way of critical mass to take on the 800-lb gorilla Cisco in enterprise networking, and it gives 3Com a way to accelerate the sales of its products through HP’s enormous sales channels.  A huge win for both companies that should make Cisco fearful, right?

Well, not so fast.  To understand some of the challenges associated with this merger requires some knowledge of 3Com: it’s not “your father’s 3Com” that ungraciously dropped out of the enterprise market almost a decade ago.  Instead, think of 3Com as mostly “H3C,” a joint venture between US-based 3Com and Chinese Huawei – the huge networking company originally started by the Chinese government (the Chinese army, actually).  Not long ago 3Com bought out Huawei’s stake in H3C to achieve 100% ownership of the previous joint venture.  (Huawei continues as a very successful global network equipment vendor, but focused mostly on carrier/service provider rather than enterprise products and sales.)

So today’s 3Com is mostly a US-led marketing operation married to a Chinese product development organization with thousands of typically low-paid Chinese engineers.   3Com has succeeded in selling its enterprise networking gear to Chinese companies, but has been less successful in selling its extensive product line to US or European firms.  That’s where HP’s huge distribution has the potential to make a big difference.

So what are the major challenges associated with a combined HP/3Com?  First, there’s a significant amount of product overlap.  HP’s ProCurve networking division (out of Roseville, CA near Sacramento) already has an extensive Ethernet switching product line, and wireless LAN products through the recent acquisition of Colubris. 3Com (through H3C) has all this and more, including high-end data center Ethernet switching, a broad set of other Ethernet switches, WAN routers, wireless LANs, etc.  3Com fills in a few of HP’s missing pieces (such as enterprise-class routers), but many of their products compete with each other.

More recently it seemed that HP was trying to eliminate much of the autonomy of its ProCurve networking division, and create more synergy with HP’s data center server product line – probably a smart move given the recent growth in data center networking.  But the ProCurve product line lacked a data center Ethernet switch analogous to Cisco’s Nexus line with support for FibreChannel SANs or FCoE. Now 3Com is going to supply data center networking gear?  3Com will have to work closely with HP’s server folks to create a converged data center infrastructure that can compete with the Cisco/VMware joint venture?  Hmm…

Another major challenge of a combined HP/3Com to take on Cisco has to do with channel strategies.  Both HP and 3Com have principally targeted SME (small to mid-size enterprise) markets via mostly indirect sales channels and multi-tiered distribution.  In contrast, many Cisco customers are larger enterprises that expect and are accustomed to direct sales and support from their networking vendor.  How will a combined 3Com/HP sell a broad range of networking products to these larger customers?  HP’s acquisition of EDS may help here, at least where networking products are bundled into a network systems integration effort.  But EDS consultants are unlikely to have much knowledge of 3Com products – they’ve historically installed Cisco routers as part of their customer networks.

So the bottom line is that while an HP/3Com deal may create greater competition for Cisco, it’s not likely to threaten Cisco’s dominance in large enterprise accounts – not unless HP can apply considerable effort and transformation to successfully address product overlaps, cultural differences, and channel shortcomings.

A more significant result of the 3Com acquisition is likely to be increased pressure on other network equipment competitors to merge.  How will Juniper, Extreme, Enterasys/Siemens/Gores, Brocade, and others respond to this?  Stay tuned…

- Dave Passmore

SNMP Security

Posted by: Eric Siegel

A question recently arose about best practices for SNMP security, so I feel that a quick blog entry about it would be useful.

Here is the simple rule: if you're running SNMP version 1 or SNMP version 2c (the current variant of SNMP version 2; the original version was abandoned because of a flawed security system), then there isn't any security. So don't allow anyone to write to your devices using SNMP, period. Completely disable all facilities on the devices that respond to SNMP write (SET) commands. If you have to write to the devices, then use a secure pathway, such as secure shell (SSH) or a secure XML flow, thereby avoiding SNMP entirely for writing.

For reading/GET functions in SNMPv1 and v2, I'd just give up and allow unencrypted community strings and data, but I still might secure the aggregated data in collectors or a central management platform. I'd use TCP and encryption for all communications between management platforms and between management platforms and SNMP collectors/pollers. I'd disallow any use of SNMP to sniff traffic, because that might reveal user passwords, etc. (And such sniffing is inefficient and awkward anyway!) I'd also see if I could restrict the data sent by sensitive devices (e.g., firewalls) in response to GET commands; e.g., I'd might not let them send their version numbers or configuration data.

An intruder could do a denial-of-service attack by issuing an overwhelming number of read/GET commands to an SNMPv1 or v2 device under these rules, so maybe you should require that devices have a way to throttle incoming SNMP requests to ensure that they aren't overwhelmed. (Many devices do this by ensuring that SNMP processes run at a relatively low priority.)

Having devices and the management agent check IP addresses and hostnames is not a guarantee against intruders, although it makes intrusion more difficult. Therefore, to decrease the probability of an attack on managed devices, the managed devices should be configured to accept commands only from sources in designated subnets (e.g., a management subnet) or from designated IP addresses or address ranges.

And, of course, you must ensure that devices do not include "hidden" community strings (i.e., strings that are embedded in the device, are typically used by the manufacturer, and are usually undocumented and not revealed to the enterprise purchaser of the equipment); these can create severe vulnerabilities.

You should have firewalls block all SNMP commands that are incoming to protected areas. Use remote collectors/pollers to gather SNMP data and push it through the firewall on a secure TCP flow if you have to go through a firewall.

SNMP version 3 is the most secure, robust solution. Unfortunately, its security features use a new security model that was designed to be independent of other security infrastructures. That helped ensure that SNMPv3 could function in a broken network, but the complexity has made many organizations reluctant to deploy SNMPv3. The IETF's isms Working Group is now trying to create an SNMPv3 security model based on SSH over TCP. When it becomes commercially available, the Integrated Security Model for SNMP will be the recommended security solution for SNMPv3.

Don't Throw Out Those Network Error Messages!

posted by: Eric Siegel

While I'm out here blogging today, here's an idea from the other area I cover: network management.

Please, programmers, when you get an error message as a result of a communications call, don't just retry retryable errors and then not bother to log the problem! We really need to know what is going on; we really need you to log all errors and messages you get from the communications calls and network systems. Maybe the intermittent error didn't crash your program, but it's out there screwing around with someone else's program nevertheless. We'd really love to be able to see the history of the errors and almost-errors in a log somewhere when the production systems are down, people are climbing the walls, and management is making the usual threats.

And another idea: when you write that error message, please don't just issue some generic message: "Things are screwed up somehow, but I've no real idea what's going on. Some damn pointer somewhere is pointing to Mars, maybe. So I'm just going to toss this transaction into the crapper and reset, or panic, or whatever."

Instead, how about a message that contains two parts: first, a series of numbers that give a detailed description of the error, along with the application ID, the transaction ID, the step you'd just completed in that transaction, the specific identity of the servers, databases and other subsystems that were open, etc. And second, a number that includes the time of day and maybe a token that we can use to match to what's going on in the system log files and monitoring files at that time. The end user can read those numbers to the service desk from the screen when the error message shows up, and we can then sort on the first numbers to see if we're suddenly getting a lot of errors with the same database, or server, or whatever. We can use the last number to look at what was going on in our other log files and in measurement system reports. That'll really help cut down our mean time to repair incidents.

I know that your deadlines are insane and your management is foaming. But think of all the time you'll save the operations staff and yourself (when you get called in to consult on the crisis, as you will). That time savings will doubtless come when you're up to your eyeballs in a different project with different insane deadlines, and you'll be really happy with your nice error messages when they save you lots of time!

Well, end of entry. Thanks for listening!

The Blivet and IPv6

Posted by Michael Disabato

When I was in engineering school and working as an intern, I was introduced to the term "blivet." According to Wikipedia (http://en.wikipedia.org/wiki/Blivit), "In traditional U.S. Army slang dating back to the Second World War, a blivet was defined as "ten pounds of manure in a five pound bag" (a proverbial description of anything egregiously ugly or unmanageable); it was applied to an unmanageable situation, a crucial but substandard or damaged tool, or a self-important person." What does this have to do with networking and IPv6? Everything.

I have recently held discussions with several governmental organizations, retail, medical, and financial firms about IPv6 and whether or not they should proceed with it. In every case there has been interest, but no movement, mostly citing lack of business case. Well, I have one for you.

Several of these firms are exhausting the private IP space they are using. One of them had this happen overnight as they absorbed one of their former competitors, which had a network almost as big as theirs. One firm is close to hitting limits because they are virtualizing their desktops, and I don't mean thin clients accessing instances of Windows on a central machine. I mean multiple instances of multiple operating systems on their workstations. Each of these requires an IP address, so you can see where this is going. We may be looking at public IPv4 address exhaustion in one or two years, but some firms see it now. They have a 5 pound network with 10 pounds of addresses. Blivet.

One practice to alleviate this problem is using "dark" IP addresses. Basically you take a range of addresses assigned to another registry and treat them as unroutable, hiding them behind your firewall. This is all well and good until you either acquire the company that really owns the addresses and have to deal with overlapping address space or Something Goes Wrong with your firewall and this hidden address space becomes visible (oops). The latter can bring all sorts of collateral damage when news of this hits the press.

Another practice is to segment the network and create NAT areas. However, this can impact legacy applications, real-time applications (voice and video), and peer-to-peer applications. 

What's the solution to this? Get a bigger bag. There is no longer time to wait on investigating and certifying IPv6 for use in the enterprise. Either a merger, acquisition, or virtualization of your infrastructure will force you to this before we run out of IPv4 addresses. The recommendations from Burton Group are:

• Set up a lab and begin testing and learning immediately 
• Enable your edge connection to the Internet to handle IPv4 and IPv6 
• Identify applications and infrastructure components that cannot be upgraded to hand IPv6 and make plans to isolate them in IPv4 islands with appropriate gateways.
• Set up dual stacks (IPv4 and IPv6) into your data center for you internal network
• Inventory your IP address space and keep a close watch on consumption rates
• Make sure all new applications can handle IPv4 and IPv6 and retrofit existing applications during maintenance cycles 

Burton Group has documents that cover this in detail, and our consulting group can help you plan for the migration and adoption of IPv6. Tempus fugit, folks. 

Michael 

Network and Systems Management: VMess

Posted by: Eric Siegel

OK, now I'm worrying about how we're going to manage VMs without losing our minds.

You see, I've been hearing great stories about how there are going to be huge racks of servers containing zillions of VMs: virtual servers, virtual switches, virtual routers, virtual firewalls, virtual performance optimization appliances, virtual everything! And the system will instantly adapt to changing workloads, spawning new, fully-configured servers with their complete environment, along with switches, routers, whatever.

And if a newly-spawned virtual server is too many virtual-router hops away from closely-coupled applications or processes, well, then, that new virtual server will be automatically re-provisioned and re-configured closer to where it should be for minimum latency!

Yes, the entire mass of virtual whatevers is going to be in constant, thrilling motion! Everything is going to be moving around, minute by minute! Total efficiency in hardware utilization! Minimum transport latency! Automation! I just can't wait! It's going to be just totally wonderful!

Until it breaks.

And when it does break (and it will), I don't want to be the miserable technician trying to figure out where everything was when that transaction failed, trying to track down precisely what subtle interaction of data flow, firewall, optimization device, VLAN, switch... you get the picture... was the source of the difficulty.

It'll be like yelling "STOP!" six hours too late at a frenzied set of hyperactive squirrels loaded on caffeine and springing among the trees while chattering at each other. Now, where were they six hours ago, when the problem occurred? All the actors in the drama will have melted into thin air. I'll bet the guilty one won't even be there any more; he appeared, messed something up, and then vanished into the virtual fabric, leaving just the rack behind.

What will the vendors give us? Probably only the assurance that the virtual servers and switches and routers will have virtual MIBs, just like the real ones. But I know where the real ones are, and I can put my hand on them and monitor them. What happens if a virtual switch appears, switches a gigabyte or two, and then vanishes -- poof! -- inside of a minute? Where did it go? What did it do while it was alive? We'll be MIB-less in the fabric, without any vision.

I can already see a rule I'd like to impose on this mess, which will tie in with the "triage-based incident management" discussed in my post "Network and Systems Management: Over the Edge." It's this:

"Just because a production group can create a maze of unmeasured real and virtual servers, network components, and interconnections that change from one minute to the next is no reason it should. Edsger Dijkstra wrote a famous letter to the editor titled 'GO TO Considered Harmful' (Communications of the ACM, August 1968) in which he made the case for more program structure and less intertwined process flow. The same applies to IT infrastructure." [This is from my new Burton Group paper, "Using Network Management Platforms for Triage-Based Incident Management."]

I'll bet we network folks are going to be stuck in the middle of this VMess, and a miserable place it will be. We'd better start figuring out how we're going to handle it when incidents occur. And I think that triage orientation, with clearly-defined diagnostic domains and rules to ensure that the virtual servers providing a service are all grouped within the same domain, where we can evaluate them as a group with active measurement techniques, is a good place to start.

Network and Systems Management: Over the Edge!

Posted by: Eric Siegel

This is the first of what will be a series of discussions on management of complex networks and systems, a problem that's confronting us all. Before I became an analyst, I spent years in freezing server rooms in the middle of crises, listening to lots of threats ("If you don't fix it fast we're going to ...") and gobbling lots of free pizza.

And those were the "good old days"; now, things are worse. Everything is more real-time; networks, appliances, servers, and distributed applications are more intertwined; network and data flow topologies are out of control; nothing is stable; it's almost impossible to reproduce the production system in a test environment. And yet we're expected to detect incidents and repair them as soon as they occur, if not sooner.

It's a nightmare. We have to get a solid grip on how to manage this mess, or we're all doomed to even more stress and stale pizza and late nights.

So let's see if we can come up with a scheme that makes our lives easier without being too expensive or impossible to implement.

I'd like to start by discussing triage-based incident management, which I've been working on and writing about for a few years now. It seems, at least to me, to be a decent alternative to the classical strategy of spending staggering amounts of money on system monitoring solutions that measure everything that's easily measured (and for which the vendor can bill licensing fees!), then hoping that an expensive "expert system" will somehow sort through that overwhelming flood of data to understand what is going on and assist the operations staff.

Triage-based incident management is based on rapid incident classification, and the basic idea is to find out where the problems are and which group is responsible for them—and then to turn the incident over to the responsible group, with sufficient credible evidence to quash any attempts at finger-pointing. The first goal is to determine the seriousness of the incident; the second is to decide which specialist group should handle it.

Incident classification is based on measuring the service delivered across the boundaries of clearly-defined subsystems, such as DNS, queries to back-end databases, transport across network backbones, and transit time through firewalls and load balancer subsystems. It looks primarily at services delivered, not at individual element measurements such as CPU time and queue length.

For incident classification to work well, clear demarcation points need to be identified at the boundaries between responsibility domains, and there should be easily-understood, credible, real-time measurements of the services being delivered across those boundaries. For example, the service desk can instantly see that DNS response time has suddenly jumped to 30 seconds, or that transit time across a critical VLAN has tripled (or the VLAN has vanished entirely!). They'll then know that they have to call the DNS people or the people responsible for the VLAN. They won't know why the service is failing, but they will be able to prove, in a few seconds, that there really are problems and they'll know the appropriate group to handle the issue.

In actual use, the service desk uses end-to-end performance metrics, such as total transaction response time or VoIP voice quality, to detect incidents, then uses other service measurements to instantly sort the incident into one of three groups:

• A well-known incident with a standard fix (e.g., reboot the server that runs some packaged software that hangs occasionally and that seems to restart without any further problems)

• A new incident that clearly is being caused by problems in a single "responsibility domain" (e.g., a DNS problem is slowing down all transactions, or a slow identity database response is slowing all new logons, so it's obvious which responsible organization gets the trouble ticket)

• A new incident that doesn't clearly fall into a responsibility domain (e.g., some subtle interaction among system elements is causing a confusing set of symptoms; diagnostic procedures should be started and higher-level diagnosticians should be notified)

Within each responsibility domain there can be additional, lower level "diagnostic domains" with the same types of clearly-defined demarcation boundaries and measurements to assist in rapid isolation of the incident to a particular subsystem.

In effect, all this is just what I call "pre-planning your next meltdown." After all, what do we do when we're confronted with a major crisis in the server room (after the obligatory freakout and power-cycling of every box we can find, of course)? We typically start putting in measurements or trying to find existing measurements to isolate the problem to a subsystem. Although we usually don't know what the performance is like when the thing is working, we can guess that response time is not some insanely-long value.

What we're doing with triage-based incident management is just pre-designing the measurements we'll use to diagnose system problems, but we're doing it early, so we can get the benefit of a baseline when the thing actually fails, and we don't have to do it while listening to threats from top management.

Well, that's a start. I'm going to keep writing on this topic, and I'd love to see your comments. What are YOU doing to manage the mess?  Does triage-based incident management seem reasonable?

(Burton Group subscribers, see: "A Framework for Network Incident Management" and the 2007 Catalyst conference presentation "Pre-Plan Your Next Network Meltdown" for much longer discussions of these ideas.)

Bonjour: Nightmare or Sweet Dreams?

Posted by: Dave Passmore

Recently one of our clients posed a question that kicked off some disagreements between our networking analysts vs. our Burton analyst colleagues who cover security.  In particular, this client wanted to know how much of a security threat “Bonjour” technology represented.  Since Bonjour is related to iTunes, our client wanted to know if someone could somehow exploit Bonjour software or protocols to hack into a system running iTunes software.

For those unfamiliar with Bonjour (formerly called “Rendezvous” by Apple), it is essentially a replacement for the old AppleTalk protocol, but based on TCP/IP. Bonjour is a way for a host/server to use IP multicast to advertise its network services, and is incredibly useful and user-friendly.  Bonjour lets your computer automatically find wireless access points, network printers, shared file systems, and yes, other iTunes music libraries with “zero configuration” required.  With Bonjour there’s no need to type in dotted decimal IP addresses, or (especially for home users) to maintain a DNS server.  Just about every network printer, for example, ships with Bonjour turned on.  My home Tivo DVR comes with Bonjour turned on (so that other Tivos in your household can automatically find each other to share files).  Many Windows printer drivers use Bonjour.

The immediate response to the client’s question from our security analysts was to suggest that Bonjour was risky: “another nightmare in the making.”  Bonjour would apparently give away all kinds of information about your computer: your username, what services you’re running, etc.  Bonjour would make it all to easy for a hacker to learn about your computer without having to bother with a port scan.  Bonjour was “promiscuous,” it was “chatty,” and it was likely that malicious content could be brought in from neighboring machines using Bonjour!

But is Bonjour really that risky?  From a networking standpoint, Bonjour’s IP multicast transmits over your local subnet/VLAN segment ONLY.  Nobody on the Internet, or across any router network boundary, will be able to see Bonjour service advertisements.  So a potential “bad guy” would have to be connected directly to your LAN to receive Bonjour service info.

With PCs/Macs, unless you explicitly check a box to advertise a particular service (e.g., your iTunes library, because you want to share music with other people or devices on your LAN), Bonjour info about that service won’t show up on the local network.

All Mac users (and tens of millions of Windows iTunes users) have been using Bonjour for many years without people in the wild exploiting it from a security perspective.  So is Bonjour really to be feared by enterprise network managers?  The benefits of Bonjour would seem to FAR outweigh any potential security issues.  Probably the worst that could happen is that you accidently share info about your iTunes music library, and your co-workers might learn something about your taste (or lack thereof) in music.

Is this economic downturn good for networks?

Posted by: Jack Santos

Hi, I am Jack Santos, CIO Executive Strategist with our EAP coverage area in Burton Group. But as the network guys that normally blog away here know, I stick to them like Teflon on fiber…or something like that.

And I am here to ask an important Carrie Bradshaw-like question.

Is this economic downturn good for networks?

Sure, just because telecoms took it on the chin in 2001 you may be feeling a bit queasy these days. But the amount of dark fiber that was abandoned under streets and undersea practically financed our way out of the last recession - with capacity still available. Concurrently, from 1995-2001 my bandwidth went from 28.8K to 1.5 Mb. From 2002-2008 it went from 1.5Mb to 10 Mb, and rising. All for $35 a month. There is a Moore’s law in there some place.

The recession is caused by two factors: crazed gamblers that aren’t allowed in the front door of any well run mafia financed strip casino but were hired on Wall Strip Street, and (if you believe Tom Friedman’s new book “Hot, Flat, and Crowded”) a planet that has serious issues with impending global warming and commodity shortages, including oil (the current dip in prices aside).

The cost of energy can only mean one thing for everyone involved in networking: more traffic, more bandwidth, more innovation. Telepresence (aka “RGVC” -- Really Good Video Conferencing),unified communication,presence, messaging, 802.11n wireless, WiMax, I and G phones, anytime/anywhere mobility…can only mean good times for network tech staff – regardless of what you hear from the rest of the IT group.

After all, we still have lots of bandwidth,infrastructure has already been squeezed, and companies will need to incur long-delayed upgrades to take advantage of these cost-saving technologies that enable work at home or reduced travel (you can only hold off going IP-PBX for so long);and we’ll need to make sure that stuff stays up--- if it was critical in the past, it’s way beyond critical for the future.

Do I feel confident enough in this viewpoint to invest my child’s education on Cisco, Avaya, Nortel, or AT&T? Well, let’s not get carried away. But I do feel confident enough to know, as a CIO, that network staffing and capacity will be the last place I look for cost cutting.After all, telecom paid their dues in the last recession. And they are lean-and-mean ready for the next.