Replicating at Speed
Producing a great network design requires balancing many factors: You’ll have to identify the best technologies for the task(s), and also factor in technology maturity, risk, cost, technical skills needed, staffing impact, and ease of management. It also requires a holistic view of how the proposed design interacts with all the other components in the network or datacenter.
Many in-house technical teams come up with designs that receive little critical review. This happens when the designer is the alpha geek in a shop, whose deep thoughts no-one dares to criticize. It can also happen in organizations that have fallen prey to groupthink – when everyone has the same perceptions about technology, design approaches, and so on.
Technologists are prone to becoming set in their ways. When you are used to certain technologies and design approaches, it can be hard to see that the outside world has moved on. (My favorite example: user switches with large-scale VLANs spanning buildings. They are rarely necessary, and make the entire building a failure domain. But I keep encountering them – despite that design approach having ended in the late 90s.)
To avoid getting locked in on old approaches to problem solving, engage in some external review. Having your plans reviewed by one or more third parties may well catch some overlooked factor; enlarge the set of options under consideration; provide useful discussion of the pros and cons of a particular technology; highlight new ways of providing more robust designs; or otherwise contribute to improving the design.
Consultants do see various ways of doing things, so they may be able to offer designs and alternatives that your staff might not think of. Good consultants are also in a better position to evaluate alternatives, having seen what works and doesn’t work elsewhere.
Design discussions and debates can be informative about what is best and what the alternatives are, especially in a rapidly changing technology environment.
As a consultant, I am particularly conscious of the need to constantly track and evaluate alternatives, to make sure I am providing the best advice. Here’s some of what I’ve learned over the years about how to get informed, unbiased second opinions about network design
If I were a corporate or government CIO in need of fresh opinions on my network, I’d want to start by talking to my technology vendor(s). Sure, they need to sell products, so it may be challenging to get a completely honest and balanced opinion from vendors. It’s not that the vendor is being dishonest; they are just emphasizing the positives of their solutions, and may not even be aware of the alternatives. (The same problem can arise with some VARs. They’re all about pushing their partners’ products. This usually becomes obvious over time.)
But if you listen closely and ask the right questions, the vendor (or VAR) may quietly be telling you something like, “You may want to think twice about buying that switch model; we’re really emphasizing this other model and product line, along with appropriate matching designs from here on out.” So talk to your vendor, listen carefully, and make up your own mind. Consider bouncing what your vendor said off of other outside parties.
A good partner has your interests in mind, and is more interested in doing the right thing than in jamming more boxes into your shop, or in getting you locked into their support services. A good partner will help with knowledge transfer, enabling you to take full ownership of delivered solutions.
Sometimes a product will not solve your problem, or may only partly help, but not all vendors will tell you that. They’ll rarely tell you that you need more staff, or need to put more effort into documentation and diagrams, or into maintaining and tuning network management tools. Have you ever had a vendor tell you their great solution could help but that your staff will need to focus on building skills to make a success of the solution? (Sometimes they do: it is pretty well-known, for example, that Cisco ISE can be very useful, but does require solid helpdesk training in supporting it for a deployment to be a success.)
If what is being proposed is a panacea, you should be hearing alarm bells. Every technology has its pros and cons; there is no magic bullet.
If something is proposed as solving your problem(s), you need to ask:
I personally like to lay out the alternatives, then analyze their pros and cons. While the answer may seem obvious, doing that exercise helps confirm that you’re making the right choice.
This blog post finishes with a couple of design case studies, as an exercise in viewing the alternatives, pros, and cons. I’m not going to recommend any particular solution, since “Your Mileage May Vary.” My point is to give you a sense of what’s possible, technically, in some live situations, so that you can start to see that there are usually many ways to achieve great design, and many questions that need to be answered for you to get there.
What do you design WAN sites with, as far as WAN edge device?
If you’re coming from the TDM world, it’s a router. With MetroEthernet connections into MPLS, a switch is more likely, although switches can’t do traffic shaping if you have port speed that’s less than access circuit speed. What are some other pros and cons in the router-versus-switch debate?
If you come at this from the Internet + VPN side, your expectation might be router to router-based VPN, or it might be firewall to firewall-based VPN. What are the pros and cons? How do you keep the cost down? Do you trust firewall-based edge security more than router-based? If so, why? Are routers or firewalls more flexible as VPN services? Why? (I personally much prefer Cisco routers for site-to-site VPN; the routing support and many options are useful. For personal VPN, AnyConnect on an ASA seems much more common. That’s perhaps habit and experience – are there good reasons for doing things differently?)
If you’re used to hardware WAN acceleration, what are the alternatives? Is there a point where WAN acceleration becomes less cost-effective, say 500 Mbps or 1 Gbps? What are the pros and cons of WAN acceleration? Does WAN acceleration tie you too much to a narrow WAN speed range, so that you can’t really exploit the ability to add 50 or 100 Mbps increments of bandwidth on a 1 Gbps access circuit?
Do you consider that VLANs and routing VRFs (VRF Lite) provide segmentation? If so, how do you mate them up with a firewall to control what goes between them? Pros, cons?
Are firewalls the only true form of segmentation? Is your security team learning VMware or ACI and thinking about micro-segmentation?
What about using an MPLS core with VRFs to segment different user populations and device populations in a large network (e.g. guests, normal users, manufacturing / process controls, surveillance video). What are the pros and cons?
In the Cisco space, medium to large shops looking to change their core datacenter design have several alternatives, including:
What are the pros and cons of each? What size datacenter and business requirements align best with each of these? What is the impact regarding skills? What are the implications or requirements of each concerning IT organization (stovepipes that don’t talk versus collaboration across traditional boundaries of network, server, storage, security, application).
We’re happy to provide an unbiased second opinion about your network design, or just talk through some of your currents needs. Just reach out.
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.