The Adventures of Rich and Vince

Characters courtesy of SP Studio

The Adventures of Rich and Vince

Characters courtesy of SP Studio

Out with Outsourcing

Maybe you moved to outsourcing so long ago, you didn’t have time to learn the lessons of the early 2000's – and you surly couldn’t rely on your managed service provider to “innovate” on your behalf at that time (no one was using the “innovate” word back then). In the early 2000’s we had this thing called “convergence” – now we call it “unified communications” because that’s a sexier marketing term. Those of us who were doing the innovating were moving voice and video on to the data network to replace aging and dollar-sucking analog phone systems and private line ISDN video systems. (Don't look now, but it’s happening again with storage in the data center. We call it “storage convergence”, but it will probably come to be known as “unified fabric”, what with the success of “unified” in “unified communications”; “unified” is now a marketing darling.)

We also went from Nortel wide area routers, a frame relay network, a Lucent PBX and Cisco switches to an all Cisco solution for LAN, WAN and voice communications over an MPLS core. Along the way, we also bought the Microsoft story and acquired more messaging and collaboration products from them and tied it all together with some new protocols and enterprise wide quality of service to handle the real-time traffic.

This also forced an organizational shift from a tower model supporting the silos of legacy voice, LAN and WAN to cross functional teams supporting the converged infrastructure, each person specializing in routing and switching or servers and storage or IP data communications (voice and video included) all with an underlying knowledge and awareness of security and network management. We consolidated the support organization, developed talent and reduced headcount favoring fewer qualified generalists over many siloed technology specialists. We became more efficient, more automated, smaller and more agile, more strategically focused and highly competent in multiple disciplines. Where do we go from here?

Logically, to save more money, you get rid of the IT team in favor of outsourcing. I won’t turn this into a “they took our jobs” rant as I’ve always worked for a provider of consulting services (read that as “outsourcer”, “managed service provider” or however else fits best). No, instead, I’ll take objection with the way in which most organizations choose to outsource. Have you learned nothing? I guess I can’t blame you, you let the people with the all the experience go. “When experience is not retained […] infancy is perpetual.” I’ll break it down for you.

For the past decade, we’ve just gone through the exercise of “unifying” the network and breaking down the tower support model to streamline IT and processes, to integrate multi-discipline teams to support the converged network. Why does your outsourcing agreement look like your 1995 IT office: multiple vendors, each providing one or more (but not all) “towers” of LAN, WAN, IPT, data center, mobility / wireless and security?

I've seen this done in different combinations, but always a combination that involved more than one partner. Remember how hard it was to change culture in your own organization – to get the network folks to talk with the voice folks, to get the server guys to talk with the storage experts? It was a paradigm shift. Some feared (rightly so) that their jobs would be eliminated. Some didn’t believe in the vision of a unified network and melded support organization. What makes you think separate vendors outside your organization are going to cooperate on your behalf better than your own team?

I’m aware of the perils of sole sourcing, but why is it acceptable to sole source my network for LAN, WAN, data center and telephony from Cisco but not the management of that infrastructure to a single partner? In fact, I see the benefits of increased dollar spend with a single vendor providing me better leverage to command greater discounts. I see the benefit of a single support contract for all infrastructure and a smaller bill for that service as on-site spares for a single vendor’s equipment is more cost-effective for large volume items.

We can no longer draw lines between LAN and WAN, internal and external, voice / video and data networks. We didn’t support them that way in-house, why does it make sense to have them supported by multiple managed service providers? As the lines between networks and the services they provide start to blur and we move to an outsourced model, we need to think more strategically about how we partner in this environment. Want a true end-to-end service level agreement? It may be hard with a single vendor - think it will be easier with multiple partners?

When we supported our own WAN in-house, I didn't deploy Cisco WAAS for the very specific task of WAN acceleration. For that specialization, I chose Riverbed, easily the market leader in that specific discipline of wide area network acceleration. That’s a targeted decision to realize a huge benefit on a critical asset. To that end, I don’t need to foster that holistic solution by splitting my network on arbitrary lines and selecting different partners to manage each piece. Rather, I ensure my chosen outsourcing provider maintains the key strategic partners to make their services best of breed. This shifts the management burden of the partner ecosystem to the provider.

I also make sure they go beyond the standard management, lights-on, day-to-day operations teams and support desk to provide a facility for innovation. We establish an internal team and a team of technical experts from the outsourcing partner (that may change based on technology requirements for current initiatives) to incorporate next generation technology as pilot projects that have a clear path to production roll-out and absorption into the existing management contract.

Sure this isn’t a “one size fits all” approach just as trying to find a customized managed service is something of a fool’s errand. But use this as an example. “Those who cannot remember the past are condemned to repeat it.”

The Adventures of Rich and Vince

Characters courtesy of SP Studio

IPv6 Sage

Well, it's official now:

The Adventures of Rich and Vince

Characters courtesy of SP Studio

Penultimate Perl Packets

Previous posts pontificated Perl packet crafting. This entry encapsulates every earlier evidence on the issue.

The Windows Packet Crafter is back - newly imagined as a Perl script that creates an interactive shell around the Net::Frame modules for creating and capturing custom packets from a Windows computer.

The misery of making packets on a Windows computer is of course the Windows TCP/IP stack's scarcity of support for raw socket options like IP_HDRINCL and normal setsockopt() calls. The way around this is literally around the Windows TCP/IP stack with a driver that allows access to the network hardware without the Windows API aggravation. The WinPcap library is a useful tool in this regard and there exists a Net::Pcap Perl module to fully utilize this functional utility.

I've already sung the praises in previous posts of the Net::Frame suite. Windows Packet Crafter creates a wrapper script to present a shell with commands and macros for creation and manipulation of packets using the Net::Frame suite.

Since Windows Packet Crafter is written in Perl as a Perl module with a separate shell script, one can easily create their own scripts utilizing the abstracted methods, macros and commands of the module. Or, for the lazy, just use the included scripts to create ARP requests, IPv4 and IPv6 traceroutes, TCP connections and many other common and useful tasks.

Windows Packet Crafter can easily be expanded with additional Perl modules - like Convert::ASN1 to decode SNMP packets (example is included in the distribution) or new 'plugins' to extend the features / commands in the Windows Packet Crafter shell environment.

Give it a test run and let me know what can be improved!