Any good network designer knows that design is driven by business. Before starting a network design, you gather business-related information such as locations, scale of the network, internal and external users, how the users will communicate with one another, and how the traffic will flow. But a great network designer should also keep in mind that design decisions may also affect the business -- in the future, if not today.
One of my previous articles on MPLS traffic engineering drew a reader comment about which questions we should ask service providers before choosing an MPLS service. I gave almost all classical answers to that question from the convergence, management, security, and network control point of view.
But another consideration is also important, and it will help explain how design decisions can affect business.
If you choose an MPLS service, the service provider can give you Layer 2 or Layer 3 connectivity options. This means you will interact with the service provider at Layer 2 over a technology like Ethernet, HDLC, or ATM, or you will be connected through IP and run a routing protocol at Layer 3. Though many service providers give only static routing and BGP as an option, all interior gateway protocols are also supported at the edge.
Only one Layer 3-based IP MPLS VPN connection can be set up on each physical or logical connection. If you need more for redundancy or another purpose (such as multi-tenancy), you will need to pay more.
Redundancy always introduces complexity, at least for IP and routing protocols. For example, say you need a connection between point A and point B. Connecting via only one link is the most direct and least complex path, but it is not redundant. So maybe two connections might be ideal for redundancy, but it also increases network complexity. The configuration complexity and convergence time of the system also increase.
If MPLS Layer 3 VPN connectivity is chosen and the business needs multi-tenancy functionality, perhaps for unit-based separation, partner connections, or private/public cloud, you will require more and more physical or logical connections from the service provider. Alternatively, you could use Carrier Supporting Carriers technology. This is not that common of an option, and it does require additional resources for staff training, network management, and tool support for MPLS.
So a more common alternative method is creating overlay tunnels. You can do this with basic GRE tunnels or DMVPN (multipoint GRE tunnels), which may be more scalable. These overlay tunnels will not provide segmentation, however, so you will need to build VRF lite or more scalable MPLS VPN on top of the overlays. Here's where your complexity really increases based on design choice.
You may be thinking, "Why is network complexity so important that it can affect the overall business?" The answer is simple. When you increase complexity, you expect many protocols and systems to interact with one another. Many things need to be configured, monitored, and troubleshot. If one system breaks, it usually affects many others, causing expensive outages and downtime.
Let me give an example. If the OSPF routing protocol breaks, it affects LDP, RSVP, BGP, and so on. Before the other protocols will work properly, you must wait for OSPF to converge. If one protocol converges faster than the other, you may try to fix the resulting black holes with IGP/BGP or IGP/MPLS synchronization. Solving one problem leads to another problem, which forces you to add another layer of complexity.
If you had focused on the need for segmentation to provide multi-tenancy when initially selecting your MPLS VPN, you could have simplified your situation greatly. Scalable multi-tenant designs can be achieved without too much complexity.
Don't forget that, beyond best-practices and design principles, there is a relationship between technology design and business that goes both ways.Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security. He has more than 10 years in IT, and has worked on many network design and deployment projects. View Full Bio