VPLS Is Not Aspirin
If you’re old enough to remember the days when switches were still called bridges and were used to connect multiple sites over WAN links, you’ve probably experienced interesting network meltdowns caused by a single malfunctioning network interface card. Some of you might have had the “privilege” of encountering another somewhat failed attempt at WAN bridging: ATM LAN Emulation (LANE) service (not to mention the “famous” Catalyst 3000 switches with LANE uplink).
It looks like some people decided not to learn from others’ mistakes: years later the bridging-over-WAN idea has resurfaced in the VPLS clothes. While there are legitimate reasons why you’d want to have a bridged connection across the Service Provider network, VPLS should not be used to connect regular remote sites to a central site without on-site routers, as I explained in the VPLS: A secure LAN cloud solution for some, not all article I wrote in 2009 (republished below).
VPLS: Don’t Get Carried Away
VPLS is one of the recent buzzwords entering the Service Provider acronym crowd. Not surprisingly, some vendor marketing departments are touting it as the latest VPN panacea and there are Service Providers believing the story and offering VPLS in environments where it can do way more harm than good.
Security experts have already realized the “opportunities” (read: attack vectors) offered by an enterprise-wide LAN cloud and demonstrated practical VPLS-based attacks. It’s thus vital that you understand the VPLS advantages, limitations and threats in order to be able to offer a range of secure services matching your customer expectations.
The Evolution
When the emerging Service Provider networking vendors tried to replace “old-world” SP technologies (Frame Relay and ATM) with “new-world” ones (IP), they focused on the majority of the IP-based market: the IP-based virtual private networks (VPN), which were very successfully implemented with the MPLS VPN technology.
However, the MPLS VPN technology did not fit all the needs of the incumbent Service Providers, who had to transport legacy traffic (for example, ATM-based video surveillance) across their infrastructure. The early adopters of MPLS VPN have also discovered that even though IP was ubiquitous at the time MPLS VPN was introduced, large enterprises still had to support small but significant amount of non-IP traffic. Even worse, some IP-based applications (including server clustering in disaster recovery scenarios) required transparent LAN communication.
The networking vendors obviously tried to cover all the SP needs and introduced the technologies that enabled point-to-point transport of any traffic across the SP infrastructure: AToM (Any Transport over MPLS) and L2TPv3 (Layer 2 Tunneling Protocol version 3). These point-to-point offerings allowed the SPs to create pseudo-wires carrying Ethernet, ATM or Frame Relay data across their MPLS or IP infrastructure, addressing the legacy needs of the enterprise customers.
With all the building blocks in place, it was inevitable that someone would try to replicate the Local Area Network Emulation (LANE) idea from the ATM world and build a technology that would dynamically create MPLS pseudowires to offer any-to-any bridged LAN service … and thus VPLS was born.
What is VPLS?
VPLS is a technology that provides any-to-any bridged Ethernet transport between a number of customer sites across a Service Provider infrastructure. All the sites (of the same VPN) connected to a VPLS service offering belong to the same LAN (bridging domain) and the frames sent by workstations attached to the site LANs are forwarded according to the 802.1 bridging standards. VPLS offers none of the layer-3 security or isolation features offered by layer-3 VPN technologies (including MPLS VPN and IPSec).
The VPLS Threats
The networking industry made numerous attempts to implement layer-2 switching (formerly known as bridging) across lower-speed WAN networks. All these attempts, including WAN bridges, brouters (WAN bridges with limited routing functionality) and ATM-based LANE have failed due to the inherent limitations of bridging. As I explained numerous times, “the world is not flat, and Layer 2 services cannot cover the needs of an entire network”.
A layer-2 end-to-end solution (including VPLS) has to permit every workstation to communicate with every other workstation in the extended LAN or send Ethernet packets to all workstations connected to the same bridging domain. VPLS thus provides no inter-site isolation:
- A single workstation can saturate the WAN links of all sites connected to the VPLS service.
- An intruder gaining access to a workstation on one site can try layer-2 penetration techniques on all workstations and servers connected to the VPLS cloud.
- VPLS-based services cannot implement traffic filters, as these filters would violate the “transparent LAN” principle.
With these threats in mind, it’s easy to see that you should offer VPLS services only to the customers actually requiring multi-site transparent LAN solution, not to everyone asking about a simple VPN service.
VPLS Is a Perfect Fit For
If your customer has applications that use non-IP protocols (including legacy Microsoft or AppleTalk networks), VPLS is the best alternative as long as the customer understands its security implications. To implement a secure solution on top of a VPLS backbone, each customer site should use a router to connect to the VPLS backbone. Obviously, you should try to offer managed router service to achieve the maximum value add.
VPLS is also a perfect fit for disaster recovery scenarios, where you need to create an impression that servers located at different sites belong to the same LAN.
Don’t Ever Offer VPLS To
When a customer with lack of IT knowledge approaches your sales team asking for a VPN solution linking numerous remote sites, don’t sell them VPLS, they probably need a managed on-site router solution. It’s true that it would be faster and easier to implement VPLS (more so since the customer is not networking-savvy), but after the first major incident (and it will happen eventually), you’ll be faced with an extremely unhappy customer and a tarnished reputation.
Your expressed views appear a bit single-sided. Carrier Ethernet (including VPLS) is very often sold as a backbone carriage solution for customers to run their L3 on top. The case of people "just plugging their LAN switches into it" is pretty rare, as Carrier Ethernet typically steals market share from other technologies (P2P links and IP VPNs), and people usually already have routers in place.
The security issues you pointed out for VPLS are more of a corner case then something really prominent, too.
If we could ensure that everyone connected to a VPLS service will deploy CE routers, I'd be extremely happy. Unfortunately, the reality (particularly with mid-sized SPs and SMB customers) tends to go the other way, more so as people are trying to cut costs.
Assuming the customer has deployed CE routers, we're facing a scalability issue as all of them are connected to the same virtual LAN segment, which is not a good idea if you're talking about hundreds of sites.
Here's Heavy Reading's take in 2007 on Verizon's flavor -
Stan Hubbard, Lead Analyst – Heavy Reading
"Verizon Business delivered the goods again in 2007 by demonstrating a strategic commitment to transform the data connectivity services landscape through Ethernet portfolio innovations that address on-demand enterprise needs. Light Reading and Heavy Reading have been particularly impressed by its national VPLS rollout, international expansion activities and plans, and widespread deployment of Ethernet access platforms that extend the benefits of high-performance Ethernet to more customer locations."
Is this just fluff???
Code-E: the real benefit of VPLS isn't that it doesn't require a router it is that it provides the benefits of IP VPN while giving the customer full control over layer 3. For us that means no more issues interacting with customer routing protocols (eg EIGRP in particular), no more modifying static routes and adding new subnets manually for static routed customers and much simpler troubleshooting when something breaks. For the customer it means the ability to run any routing protocol they like, better convergence times than IP VPNs and the ability to segment their network using VLANs over the WAN for different departments or divisions.
As you start to exceed around 100 sites you start to have to think about scalability more as Sundar mentioned but below that level it is just a no-brainer if you need a private network and you can find a service provider that can deliver VPLS to all of your locations.
I know there isn't a ton of blog coverage on service-provider delivered VPLS networks so I thought some of you might enjoy our blog which has a number of posts on VPLS http://www.cavtel.com/business/blog/
Please keep also in mind that the article was written almost a year and a half ago, when some vendors were still promoting VPLS as the next panacea.
Last but definitely not least, it's great to see a Service Provider blog full of useful and accurate information. I could only wish more SPs would be like you.