Most of the time these aren't L3 customers it is L2VPN. Like an instance doing cell backhaul where a customer wants two circuits which take diverse paths around a ring. You can do it with G.8032 and different VLANs but its somewhat easier using MPLS along with the benefit of the 50ms protection RSVP-TE can provide. Or IP FRR If you aren't in a ring scenario which breaks it.
Phil From: Andrew Miehs Sent: 7/6/2013 5:07 To: [email protected] Cc: [email protected] Subject: Re: [c-nsp] MPLS down to the CPE On Sat, Jul 6, 2013 at 6:16 AM, Mark Tinka <[email protected]> wrote: > On Tuesday, March 05, 2013 03:23:43 PM Saku Ytti wrote: > > > Not at all. But adding MPLS to customer would increase > > our exposure. > > At $previous_job, this was a serious consideration, mostly > because the customers were starting to pressure ISP's into > making redundancy not only native, but usable without much > input from the customer. > Don't see why adding MPLS would help very much here - especially considering the security risk! What is the difference on input for the customer between connecting to a PE, or connecting to a CE provided by yourselves? The main reason for running a PE out to a customer site would be if the customer requires a lot of different VPNs/ VRFs which you are routing for him - L3 tunnels vs L2 - and you don't have a leased line capable of separating these VPNs... So why couldn't you just run a pair of 3900s CEs (eBGP private ASes between PEs and CEs, iBGP between the two CEs) and HSRP/ GLBP for the customer side failover? _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
