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
Why you should talk to your vendors
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.
Case study: WAN edge device
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?
Case study: security segmentation
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?
What about Cisco ISE? ISE arguably provides segmentation in terms of user-identity based access controls, potentially getting you out of the business of source IP = identity / trust group game. What are the costs, pros, and cons compared to other forms of segmentation?
Case study: Data center design
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).
This article originally appeared on the Netcraftsmen blog.
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
