For an enterprise migrating from traditional Internet IPSec L2L VPNs for branch offices to a MPLS-based VPN, there are options for either a L2VPN or L3VPN. The L2VPN looks more attractive as you have nearly complete control over it to run your own routing protocols that don't require ISP coordination or MP-BGP in their network to support the VRF routing.

  1. If a MPLS-VPN (L3VPN) is used, DIA can be provided on that same service, though I have no direct experience with this and am not sure if it's generally a good or bad idea.
  2. Also, I don't think DIA is generally provided as a service or possible with L2VPN, but please confirm.
  3. WAAS will also be used in the future if that has any influence on whether to go L2 or L3VPN. Each branch office currently has their own DIA and will continue to have that provided either separately or multiplexed with the VPN. WAAS would be done in 2900 ISRs in the branch office and TBD in main corporate office.
  4. Should encryption -- not PCI/not HIPPA required -- be mandatory as we do now with IPSec or is there usually enough inherent trust with either the L2 or L3VPN implementations with VRFs; specifically, does SOX say anything about requiring encryption?
  5. (Bonus points) Terminating the VPN on a router inside the firewall seems to be the way to go, though with DIA multiplexed on the VPN seems to thrown a monkey-wrench into this as DIA is usually outside the firewall. With or without DIA to worry about, having the VPN on the Internet edge router outside the firewall would usually deal with public IP space, so to continue using private addressing between sites, is it recommended to just to do no-NAT or identity-NAT at the firewall.

Putting myself in a customer perspective, with presumption that customer has solid technical competence.

If you have multiple offices, you should confirm that L2VPN product you're offered is multipoint, any-to-any solution, like VPLS. Then ask how many MAC addresses can be in each sites, how are bcast/mcast/unknown unicast limited. If there are no limitation, it likely is not a good news, then it might mean if some other customer fills MAC table, you'll suffer as well.
It would be prudent to test that limits are enforced.

I would shy away from getting Internet access in L2VPN or L3VPN, it will probably contain several SPOFs as implemented by operator, you might be more comfortable controlling those SPOFs yourself, so you don't have to wait for operator to fix something while all your offices are without Internet.

Having said that, both L2VPN and L3VPN commonly are provided with Internet access. In L2VPN (particularly ELAN/VPLS) it's actually very easy, provided you're using routable IP addresses, as then operator will just drop in IRB interfaces in the L2VPN instance acting as your default-gw inside the operator network, HSRP/VRRP if needed.
In L3VPN Internet Access product probably assumes RFC1918 addresses and there likely is no ability to order direct INET connection to each site, from closest PE. Only option likely offered is centralized firewall, which may or may not contain large amount of SPOFs.

In either case, please be sure you understand how the INET access is implemented and if you're ready to carry the risks. If not, just order additional INET access to one or more sites and handle INET yourself, which I'd prefer to do anyway.

I have no comment on WAAS, I've never used them, but can understand how they might be useful in slow-speed accesses using badly designed applications.

If encryption is not mandated by regulatory authority, I would not do it personally, it's just more things to cause problems, require maintenance and increase cost of CE.
I would however acquire actively knowledge what applications we're using internally which of them are using encryption, which can be migrated to encryption and which cannot use encryption and device long-term plan to move all applications to encryption.
Security should not have higher cost than the risk carried in the breach of security.

I'm not sure I understand bonus point question, I would certainly not put a firewall between my CE and operator PE. States should be kept at last possible moment. I personally would only want FW in front of human LANs, where guaranteeing software hygine is difficulty. I would not put FW in front of servers, because it'll dilute my investments in availability and performance. Enterprise world has too much love for FWs.

  • Good info as usual. On the bonus question, it wasn't about firewall between CE and PE; just which side of firewall to place CE and drop PE link into it. I think without DIA in the mix, my CE would be inside my firewall, but if I do WAAS on the 2900 Internet edge routers, that tends to move the CE outside. I understand with your SP-thinking about firewalls that the "E" in CE really means edge and would be outside, but then that's where the consideration of RFC1918 comes into play with NAT on the firewalls since we don't can't have public addresses going into the VPN. Sep 23 '13 at 8:16
  • All MPLS VPN design guides I saw from Cisco don't have firewalls in the picture. Sep 23 '13 at 8:19
  • In my mind LAN_PC - FW - CE - PE - Core. Then CE can connect to other unfirewalled LAN for servers etc, where performance/availability is importanat.
    – ytti
    Sep 23 '13 at 8:25
  • What are some of the SPOFs you're thinking about with DIA in this context? Sep 26 '13 at 6:55
  • If you buy INET access for your L3 MPLS VPN, it would typically use centralized FW. It's very rare to see FWs deployed with routing redundancy, often if there is any redundancy it's just stateful failover. And when there is an issue, all your sites will be without INET, which may be unacceptable, especially if fixing it takes longer time. So I would personally prefer to build it myself, with INET accesses in two or more offices, which advertise default to the L3 MPLS VPN. But of course convenience is preferable to many and we have many satisfied customers using centralized FW for INET.
    – ytti
    Sep 27 '13 at 7:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.