The MPLS-OPS Archive

[Christopher Lewis <chrlewis@cisco.com>]

Hi Mike,

Do the publicly viewable links off 
http://www.cisco.com/univercd/cc/td/doc/product/vpn/solution/rampls/ramplspr/intro.htm 
help? This covers the use of virtual interfaces to support access to MPLS 
VPN from the following.

Dial L2TP, RFC 1483 routing, PPPoX and PPPoX to SSG, DSL L2TP, plus PPPoE 
and DOCSIS for cable. These have all been tested in real world deployment 
scenario's and your account team can give you all the config, test plans 
and results.

Of course, the examples given here use Cisco Access Registrar as the Radius 
server for passing attributes back based off domain name of the user, but 
almost any Radius will do the job.

For off-net IPsec access, fixed site locations are fairly trivial to 
account for (as I think you infer below), if you want details of remote 
access users coming in over IPsec encrypted tunnels and dumping them in the 
right VRF, you can ask your account team to get in contact with me.

Chris

At 08:26 AM 2/24/2002, Mike Duckett wrote:


>-----Original Message-----
>From: Mike Duckett [mailto:mduckett@bellsouth.net]
>Sent: Sunday, February 24, 2002 8:05 AM
>To: mpls-ops@mplsrc.com
>Subject: off net access to 2547 PE
>
>
>Cisco, Juniper, ... and operators...
>
>I noticed a recent thread on what you called "various media/protocols
>accessing a MPLS VPN".  Basically, you have a problem where customer sites
>or mobile workers are not directly connected (via circuit nor ATM/FR/..) and
>require access to the VPN.  One approach is to mix and match overlay VPNs
>(e.g, IPSec) with 2547 VPNs.  Certainly there are religious and
>non-religious views on how to address a non-directly connected CE.  I'm
>particularly interested in the view of Cisco and Juniper as well as service
>providers as to how they can support a large scale 2547 service in
>conjunction with off-net users.  I'm interested in two "virtual" interface
>options including:
>
>(1) PPP/L2TP (could be used for cable, dsl, ..) access into a VPN.  In this
>case, the network between the PE and the customer is a "broadband"
>aggregator functioning below the IP layer as far as the customer is
>concerned.
>
>(2) IPSec into a VPN.  In this case, I have customers with off-net sites
>that need access to the VPN, both mobile workers and dedicated sites, and
>are not directly connected to my network.
>
> > Are folks looking at X.509v3 extensions to carry service attributes (e.g.,
>access lists, ip addresses) or is PPP used inside the IPSec tunnel?  Again,
>trying to develop a scalable architecture and deal with (1) VRF/VPN
>identification, (2) IP security profile, (3) service attributes such as IP
>address, access lists, QoS policy.  Seems like either (a) X.509 certificate
>to address IPSec component along with PPP/IPsec using Radius/LDAP, or (b)
>X.509 with extensions addressing service attributes would be the basic
>options.  What are vendors implementing?
>
>Overarching:
>
>Can this be done?  If so, can you point me to a detailed architecture?
>
>How to you manage AAA (authentication and authorization attributes) for
>users?  Can this be supported in Radius or LDAP?
>
>What models do you support for key management as well as things like issuing
>session attributes (e.g., traffic filters, diff serve)?  Can this be
>integrated into Radius as well?
>
>How do you see building a large off net PE connection scheme (e.g., using
>IPsec and PPP/L2TP)?  You have problems like scaling VRFs, scaling
>encryption, load sharing, distributed PEs, etc...
>
>-------
>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

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