The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-May> msg00204



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: NAT for MPLS VPNs.

  • From: fraanro <fraanro@arrakis.es>
  • Date: Tue, 28 May 2002 13:30:09 GMT
  • Cc: fraanro <fraanro@arrakis.es>, mpls-ops@mplsrc.com
  • Resent-Date: Tue, 28 May 2002 10:26:43 -0400
  • To: raszuk@cisco.com

The point about security and the IT departments is quite reasonable. 
But, maybe not specifically for Internet but for any kind of shared 
services the provider may be willing to give, like access to 
applications, etc., the provider could give access to them to the VPNs 
of the customers using the VPN itself. 
The extreme case would be an ASP on top of that provider. The sites of 
the different customer VPNs would reach the shared resources (Oracle 
servers, who knows) directly instead of going to the HUB site, being 
NATted/Firewalled in this point, and then back again to the provider). 
I think both ways to do it have pros and cons.
Probably for big customers with big IT departments, the HUB model is 
clearly preferred (or the only accepted).
But for small or medium companies without these IT departments, the 
integrated model could be more acceptable, couldn't it?

Javier.

----- Mensaje Original -----
Remitente: Robert Raszuk <raszuk@cisco.com>
Fecha: Lunes, Mayo 27, 2002 9:22 pm
Asunto: Re: [MPLS-OPS]: NAT for MPLS VPNs.

> 
> Hi Javier,
> 
> >    Now my question is (mainly targeted to people working in 
> service 
> > providers but in general to all): Is currently the Internet 
> > connectivity for the VPNs being integrated in the VPN service 
> using 
> > this kind of devices/features or is actually using mostly the 
> > traditional model based on two physical/logical links in the 
> main site 
> > of the customer, one for the VPN and one for Internet. 
> >    The point is, what is being preferred by service providers 
> and why? 
> 
> My observations of the actual deployments demonstrate that Internet
> access is mostly provided via a HUB sites with a dedicated solid
> firewalls. It is also often the case that the Internet provider is
> different from the VPN service provider. 
> 
> Now reg your question if it actually makes sense to integrate both ...
> with the same provider the answer would be yes, but I don't think that
> collapsing both in to one interface between as you said main sites and
> provider is very safe or efficient idea. I am sure some folks may 
> say it
> could be cheaper but bearing in mind that even logical interface
> separation is more then sufficient I don't think so. Also I am sure
> (based on my own experience) that internal securty departments get
> paranoid (and I think for the right cause) when the corporate and
> internet packets travel together.
> 
> Rgs,
> R.
> 
> > fraanro wrote:
> > 
> > Hi all,
> > 
> >    ASAIK, some vendors like Netscreen, or Shasta from Nortel, or I
> > thinks also Cosine (but I am not sure about it) support NAT in 
> such a
> > way that can be used for MPLS VPNs, for providing Internet 
> connectivity> for a customer corporate VPN.
> >    Cisco is also due to release that feature for MPLS VPNs.
> >    Now my question is (mainly targeted to people working in service
> > providers but in general to all): Is currently the Internet
> > connectivity for the VPNs being integrated in the VPN service using
> > this kind of devices/features or is actually using mostly the
> > traditional model based on two physical/logical links in the 
> main site
> > of the customer, one for the VPN and one for Internet.
> >    The point is, what is being preferred by service providers 
> and why?
> > I think integrating the Internet and VPN service in the same 
> interface> (physical and logical) as any solution that integrates 
> several services
> > toghether reduces the churn (i.e. the rate of losing customers 
> going to
> > other service providers), but in practice, how many providers 
> build the
> > service this way?
> >    Thanks in advance for your oppinions.
> >    Javier.
> > 
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml