MPLS Services

Fri Aug 28 18:52:21 UTC 2009

This might give you some ideas (also solves the overlapping customer address
problem):

http://www.nil.com/ipcorner/FlexExtraImplement/

Ivan

http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Kenny Sallee [mailto:kenny.sallee at gmail.com] 
> Sent: Friday, August 28, 2009 6:28 PM
> To: nanog at nanog.org
> Subject: MPLS Services
> 
> Questions for the community:  from a Application Service 
> Provider perspective - how / can one provide application 
> access to a group of Enterprises where the ASP provider 
> provides ASP like applications to all Enterprise customers 
> who have multiple locations and who may or may not have 
> overlapping addresses?  Each Enterprise is it's own business 
> and we cannot allow connectivity between each other We've 
> struggled internally with this.  MPLS and using BGP 
> communities seems to be the solution.  But I am trying to 
> understand / think through the configuration of it from a CE 
> and PE side perspective.  Lab configs to follow but here's 
> what I'm thinking:
> 
> - From the CE side we could ask for 2 frame PVC's - each in 
> it's own VRF on the PE side.  Call 1 VRF private and 2nd VRF 
> public.  In the Private VRF advertise all CE routes between 
> customer A for example.  Each CE customer would have their 
> own VRF on the MPLS providers network.
> 
> -  From the CE, In Public VRF advertise a network range we 
> provide the clients and NAT traffic destined for the shared 
> environment to the public range
> 
> -  On each CE router only permit route updates on the Public 
> VRF for BGP communities that belong to that customer and our 
> shared segments.  Could also do this with just route 
> filtering by ACL/prefix lists.  On the Private VRF no need to 
> filter incoming but filter outgoing to contain routing domain 
> consistency (only send updates for CE networks)
> 
> - In the Public VRF from ASP side  - advertise all shared 
> services routes.
>  Accept all updates on Public VRF.  No access to Private VRF's here.
> 
> Thoughts?
> Thanks,
> Kenny
> 
> 