Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Building Network Design Skills

How do you learn how to do network design well? NetCraftsmen does Network Assessments, as well as other types of assessments. We frequently get asked about design skills and sources of best practices. In addition, I’ve been mulling over how to best internally build junior engineers’ skills in design.

Here are several ways to build your network design skills:

  • Read everything you can get on the topic with a critical eye. Determine what is trustworthy, what is marketing pushing an agenda, what is overly complex, what is good for the customer.
  • Read the Cisco Press ARCH book. Now. It ties to the CCDP exam, and certainly doesn’t hurt if you’re doing the CCDE written (from experience). I’ve been involved with the second and third editions, and can vouch that there is lots of good design content. The updated fourth edition came out in December 2016. I now have a copy, but haven’t read/skimmed it, so I can’t comment on it yet. The table of contents indicates some timely updates, including some added case studies at the end. Good idea!
  • Read the CCDE suggested reading list — you need to know various approaches, their technical capabilities, limitations, pros, and cons. You may find the CCDE Study Guide useful (good content, many typos). It does include Service Provider and MPLS topics, which might be deferred if you’re primarily interested in enterprise design.
  • Read the Cisco Validated Design (CVD) documents. They’re mostly really good content. A few are shallow or have an agenda. In general, I find any given CVD about 95% bang on, with minor differences over some of the ancillary details. There are some major exceptions, ones that I consider poor ideas/overly complicated.
  • Get into a job position where you can see and analyze many networks, regarding both business requirements and technical design. Consulting (internal or external) and design reviews are one way to do that. Question everything. Think outside the box. Solve business problems for the customer.
  • Practice design write-ups and simple clean diagramming. Presenting a design to the customer is important. Did I say “PowerPoint”? Definitely a required skill!
  • Practice critical thinking. How could this be done differently? What are the pros and cons of each alternative? Over time, you should build up mental or notes-based lists of alternatives for various design situations (campus, datacenter, WLAN, WAN, small/medium/large sites, etc.). Example: datacenter design with two core switches, or three different flavors of spine-leaf with Nexus 9Ks.
  • Practice your PowerPoint and/or Visio skills. They’re essential for presenting a design, and darn useful for showing the stages of a migration or new technology deployment.

Exercising design skills

As an example, consider campus network segmentation, a topic that doesn’t get widely discussed. I’m using it for precisely that reason: Thinking through new situations builds skills.

I’ve seen the following alternative approaches. A terse pros/cons analysis is included. I’m not claiming its 100% perfect; I’m just trying to provide a meaningful example, one where I’ve seen a lot of rigid design thinking (that is, picking one of the below approaches where I’d have picked another, generally because it was simpler or less costly and met the requirements).

>This can work; I have done it at 100+ building hospital and medium-sized government agency scale.Simple, low-tech for operations

Design Approach

Pros

Cons

Firewall-based segmentation

This is common in data centers, not so much in campuses.

Firewall routing is limited in capability.
Firewalls can become traffic bottlenecks.
Generally ends up being somewhat clumsy, not agile.

Central interconnect or core with firewall pairs guarding compartments or zones

 

For zone A to talk to B, two pairs of firewalls need to be configured. This scales very poorly.

Firewall pair with compartments as zones off the firewalls

All the rules are in one firewall pair.

You still have to write two sets of ingress rules for A to B.
All the rules are in one firewall pair.
Doesn’t scale (scale up not out).

Multiple firewall pairs randomly interconnecting security zones

 

Routing could get really messy.
Avoiding asymmetric flows?
Operations, troubleshooting ugly.
Hierarchical designs are generally highly advisable — random meshes not.

Network virtualization and segmentation

 

Complexity

VLANs as segmentation

Simple

Large scale VLANs not a good idea.

VLANs + VRFs and VRF Lite/EVN as segmentation

This can work; I have done it at 100+ building hospital and medium-sized government agency scale.
Simple, low-tech for operations

Not elegant.
Adding a segment/zone is painful.

That plus central MPLS

Makes the core more scalable, which in turn simplifies overall scaling

Cost for MPLS capability (devices supporting it, licensing).
Increased tech complexity (MPLS VPNs).

MPLS-centric campus (e.g. down to access layer using 3850 switches)

Scalable, elegant.

Cost for MPLS capability.
Increased tech complexity (MPLS VPNs).

Campus Fabric: ISE + VLAN/VRF/VXLAN, omitting LISP

If you have a need to extend L2, VXLAN is the way to go. We’re doing it in some datacenters, with BPG (EVPN). It is, in effect, the new FabricPath.

Why would one want to extend L2? VoIP mobility without central CAPWAP and avoiding re-DHCP comes to mind.
The DNA Campus Fabric (SD-Access) solution requires LISP.

(New) Cisco DNA Campus Fabric: ISE + VLAN/VRF/VXLAN + LISP

(See above)

(See above)
Increased complexity due to LISP. (I’m not a fan!)
LISP is apparently in there for mobility support; I’m not convinced it is needed unless you’re talking mobility across normal L3 routing boundaries — use cases?

ISE-centric segmentation

Provides useful security insights into devices, locations, contexts.
Doesn’t create “hard boundaries” between user or server groups.
Does allow control via PEPs.

Device support in general (SGTs, PEPs).
Doesn’t create “hard boundaries” between user or server groups — that’s not helpful if you need to keep different types of users segmented from each other.
Some requirements might need overly many PEPs.
SXP scaling limitations.

NEXT page: A closer look at campus network segmentation options

  • 1