This means your WAN needs may be very different from a similar company of similar size, even if you’re in the same trade sector, or industry vertical. Fortunately network providers the world over have a wide variety of WAN services they can offer to meet your needs. Today, let’s focus specifically on using a technology called VPLS to connect your data centres via Ethernet.
If your team is investigating WAN providers, leverage the Netify research database. Netify positions you to create feature matrices, with comparison data, across 100+ curated SD WAN & MPLS vendors & providers. Impress your peers, build your own list vs specific requirements, set budgets and manage the end to end procurement process using the Netify SD WAN assessment. Click to get started.
Editors note:
- Procure SD WAN like an expert consultancy. We’ve put all our years of telecoms experience into our SD WAN Guide with leading vendors evaluated, just for you. Download it for free and start applying practical tips today.
Most organisations, mid-size and above, will eventually need to connect at least a couple of data centres together. It might be two physical branch hosting facilities, or perhaps they’ll connect that branch data centre with a Cloud presence like Amazon’s AWS. They might connect them for any number of reasons.
Company A might do it to provider backup, and disaster recovery services for their primary data centre. Company B may be primarily concerned with bringing their internal applications closer to users over dedicated circuits.he first will be that of a mid-sized enterprise with three locations; A, B, and C.
A single provider connects all 3 sites with point-to-point services today. Sites A and B are data centres, site C is a corporate office.
The enterprise is making a move to mirror critical services at each of the data centres to the other (backup and hot-spare redundancy). At the same time, they are installing a new phone system. So for the first time, they need to extend some of the VLANS at location A into Location B and vice versa.
Additionally, they’d like to build a new phone VLAN (and single IP subnet) that spans all 3 locations. There will be two PBXs for resiliency, one will be at the corporate office and one will be at data centre B. This means they’ll also need a PBX (backend) VLAN that only spans those two locations. This might be a perfect time for that organisation to talk to their Ethernet provider about converting those point-to-point circuits over to a VPLS. This uses the provider as a virtual switch and flattens that network into a single virtual LAN making both transitions possible.
Our second scenario will involve an organization that intends to still put Layer 3 routers at every location, but may still want a VPLS solution to achieve their goals.
Let’s consider a corporation that has, until today, maintained a single (very large) data centre at one location. The location is served by two Tier 1 Internet providers using BGP multi-homing for resiliency. Due to changing business drivers, they decide they need to diversify.
They’re going to break this data centre up and re-locate most of this hardware to 4 different data centres (or cloud locations). The data centres will be geographically dispersed and will likely utilise the same two major carriers for connectivity. Now, the enterprise certainly has the option of extending their BGP Autonomous system footprint around the world.
However 4 (or 8 if you want chassis level resiliency) BGP capable routers, each capable of taking a full route table from two providers can be hideously expensive. So they decide that they’re going to have BGP borders at only two of these locations. That leaves the question of how all 4 locations talk to each other. In the end, they decide that ll 4 locations will be tied together with a VPLS and will use an IGP (OSPF) to communicate with one another.
Since the VPLS presents as Ethernet, the OSPF routers are all in the same broadcast domain, see each other plainly, and form adjacencies as if they were within a single campus. You can see, that even though, there is a Layer3 boundary at each datacenter edge, the VPLS technology still makes the “provider Ethernet Bridge” an efficient, and effective L2 solution for the middle.
Whatever the business driver, using VPLS as your Ethernet connection technology in the WAN can pose multiple advantage over other approaches. It can help to make the distance between data centres transparent to your applications. It can dramatically simplify routing. It can even flatten the network and help you extend VLANs across continents if desired.
Virtual Private LAN Service (VPLS) is an architecture that fits within a set of services often referred to as transparent LAN services (TLS) by service providers. These TLS services allow providers to connect customer edge (CE) devices across long distances and to provide the handoff to the CE as Ethernet. Some TLS services are point-to-point, and only connect a single point to a single other point. Other TLS services are multi-point to multi-point, and this is where we find VPLS. VPLS is capable of connecting a few, or hundreds of sites together into a virtual mesh. Each branch location will have a customer edge device (an Ethernet router or switch). The provider builds a mesh of pseudo wires connecting all of these Ethernet devices together. Best of all, the provider network is acting as a virtual Ethernet mesh, so the provider (or providers) in the middle act a large virtual Ethernet switch (bridge) tying the whole thing together.
Simply put, this all means that each of your locations sees themselves tied to all of the others with simple Ethernet connectivity. That means you can choose to extend VLAN100 to branches A, B and F, but not C, D, and E. You could also have just a single DHCP server (or a redundant pair) and do away with having one at every branch. Also, applications and services that rely on broadcast (or multicast) protocols can be extended from branch to branch. With your provider acting as a large Ethernet switch between branches, you are able to treat your WAN much more like your LAN. However, just because VPLS presents its self to your CPE as Ethernet, doesn’t mean everyone who uses VPLS between data centres does so simply to extend their switching. Let’s briefly look at two common scenarios where an enterprise might choose to deploy VPLS between data centres.
The first will be that of a mid-sized enterprise with three locations; A, B, and C.
A single provider connects all 3 sites with point-to-point services today. Sites A and B are data centres, site C is a corporate office.
The enterprise is making a move to mirror critical services at each of the data centres to the other (backup and hot-spare redundancy). At the same time, they are installing a new phone system. So for the first time, they need to extend some of the VLANS at location A into Location B and vice versa.
Additionally, they’d like to build a new phone VLAN (and single IP subnet) that spans all 3 locations. There will be two PBXs for resiliency, one will be at the corporate office and one will be at data centre B. This means they’ll also need a PBX (backend) VLAN that only spans those two locations. This might be a perfect time for that organisation to talk to their Ethernet provider about converting those point-to-point circuits over to a VPLS. This uses the provider as a virtual switch and flattens that network into a single virtual LAN making both transitions possible.
Our second scenario will involve an organization that intends to still put Layer 3 routers at every location, but may still want a VPLS solution to achieve their goals.
Let’s consider a corporation that has, until today, maintained a single (very large) data centre at one location. The location is served by two Tier 1 Internet providers using BGP multi-homing for resiliency. Due to changing business drivers, they decide they need to diversify.
They’re going to break this data centre up and re-locate most of this hardware to 4 different data centres (or cloud locations). The data centres will be geographically dispersed and will likely utilise the same two major carriers for connectivity. Now, the enterprise certainly has the option of extending their BGP Autonomous system footprint around the world.
However 4 (or 8 if you want chassis level resiliency) BGP capable routers, each capable of taking a full route table from two providers can be hideously expensive. So they decide that they’re going to have BGP borders at only two of these locations. That leaves the question of how all 4 locations talk to each other. In the end, they decide that ll 4 locations will be tied together with a VPLS and will use an IGP (OSPF) to communicate with one another.
Since the VPLS presents as Ethernet, the OSPF routers are all in the same broadcast domain, see each other plainly, and form adjacencies as if they were within a single campus. You can see, that even though, there is a Layer3 boundary at each datacenter edge, the VPLS technology still makes the “provider Ethernet Bridge” an efficient, and effective L2 solution for the middle.
Since we’re talking about “how to” connect data centres with VPLS, it might be beneficial to spare a moment for “how NOT to” connect data centres with VPLS, so you might be inclined to ask me “are there caveats or gotchas to using VPLS?” Why yes, and here’s one. This is a Layer 2 service. That's not a caveat you say? That's just restating the core concept of what VPLS is? Well here's the thing about Layer 2 services in the WAN. I've seen one too many network engineers order an L2 service, but then treat it like a typical L3 WAN service. So I'm asking you to remember that you're ordering a virtualised L2 switch that is geographically dispersed over (potentially) the entire globe.
We've all looped a port on an Ethernet switch in the administration building, and accidentally caused a broadcast storm that took building C and D offline as well. Haven’t we? Really, that’s just me? Remember that when you extend your switching network with VPLS, it may be possible to misconfigure a VLAN and do the same thing, but now it affects London, Singapore, and Paris. Most VPLS providers provision the VPLS service (their virtual bridge) to minimize these types of user failures, but you should still remember the root of the technology is Ethernet.
One limitation that often comes with these provider protections is an upper limit on the number of mac addresses that the provider will allow the “virtual Ethernet Bridge” to learn. Mac-learning is crucial to the proper function of an Ethernet bridge. So if you are NOT putting routers (and L3 boundaries) at each endpoint, talk with your provider about things like mac-learning limits and circuit MTUs to head off any problems during the ordering / planning process.
VPLS will continue to service a critical need in the provider space for years to come. Scores of industries and enterprise networking pros understand that just because the Cloud trend is upon us doesn’t mean that everything will move to a “commodity” Internet style circuit. VPLS is, and will remain a versatile tool in the WAN engineer’s tool box.
If your business is changing, or shifting and it sounds like VPLS might be the right solution for you, get in touch with us.