The MPLS-OPS Archive

["Yuly Milner" <ymilner@hotmail.com>]

Hi all,

I'm one of those service providers, and right now we consider providing 
internet connectivity (via sub-provisioning) to our corporate VPN customers.
Right now we prefer the centralized internet access model. Currently we rely 
on customer's own security solutions, but the internet access is done on our 
MPLS rouder, via import/export between ISP VPN and customers VPNs. I think 
this is better than access via the hub site, because the potentially, if we 
used a managed firewall, the traffic would go directly to the ISP from all 
VPN sites, without going first to the hub site. Also, we can more easly 
change the ISP for our customers, if they are not satisfied with the service 
ISP provides.


Regarding the NAT and firewall devices: Lucent also has virtual firewalls in 
their Brick product line. Did you consider it? I'm curious because we are in 
a process of selecting the right product for managed firewall service in our 
network.
Thanks,

Yuly





___________________________________________________________
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


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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