[c-nsp] mpls option A with LAC and LNS

[Vikas Sharma]

Hi Oli,

Authentication is required to keep users in their respective VRFs. These all
attributes will come from Radius. We are getting services from other
operator. User are using their infracture and coming in to my network.

We provide mpls vpn / internet services to the customer.

Regards,
Vikas Sharma


On 7/28/08, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
>
> Ah, ok.. may I ask why you would want to authenticate the "users"? And
> against which user database?
> Which service(s) do you provide for the other operator? More than just
> traffic?
>
>        oli
>
> Vikas Sharma <mailto:vikassharmas at gmail.com> wrote on Monday, July 28,
> 2008 8:24 AM:
>
> > Hi Oli,
> >
> > Thanks for the prompt responce. I think I need to slightly modify
> > this.
> >
> > Though I have used the term LAC and LNS, I am not using L2TP to get
> > the data from the other operator. I am using Inter-AS option A, back
> > to back vrf. The issue I can see once the data is at my ASBR, it will
> > not have any control plane information (as other operator has already
> > put it in to the respective vrf). In that case I will not be able to
> > use my radius to authenticate the user. In summary, my radius will
> > not be used at all.
> >
> > Regards,
> > Vikas Sharma
> >
> >
> > On 7/28/08, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> >
> >       Vikas Sharma <> wrote on Monday, July 28, 2008 6:59 AM:
> >
> >       > Hi,
> >       >
> >       > Need help to resolve the below situation. The scenario of LAC
> / LNS
> >       > and mpls option A -
> >       >
> >       > In case, the customer belong to the ISP dials and latch in the
> same
> >       > ISP (i.e. using ISP infrastructure), I can authenticate (since
> they
> >       > will latch on LNS, a radius client), using radius and radius
> will
> >       > return certain attribute including vrf / pool name etc. and
> then
> >       > customer will go to it's own vrf and to it's own network.
> >       >
> >       > But in my case, customers come from other ISP domain (dialing
> and
> >       > coming on their lac) and we are using back to back vrf to
> connect
> >       LAC > and LNS. Now the problem is, how to authenticate the users
> and
> >       return > vrf and ip pool name from the radius as LNS can not act
> as
> >       radius > client now. The only option I can see is to forward the
> >       fraffic to > firewall, which can act as radius client and query
> to
> >       radius server, > radius server can inturn return the vlan which
> can
> >       be mapped to > respective vrf.
> >
> >       you can use vrf-aware Radius to send Radius the radius requests
> >       within the VRF (which, I think, solves your problem, but I'm not
> >       sure I entirely understood your topology):
> >
> >       aaa authentication ppp VRFCUST group VRFGROUP
> >       aaa authorization network VRFCUST group VRFGROUP
> >       aaa accounting network  VRFCUST group VRFGROUP
> >       !
> >       aaa group server radius VRFGROUP
> >       server-private x.x.x.x key zzzzz
> >       ip radius source-interface ...
> >       ip vrf forwarding <vrf-name>
> >       !
> >       int virtual-template1
> >       ppp authentication chap pap VRFCUST
> >       ppp authorization VRFCUST
> >       ppp accounting VRFCUST
> >
> >       However: The L2TP packets also arrive within a VRF, so you need
> to
> >       use vrf-aware vpdn as well (specifiy "vpn vrf <name>" in your
> > vpdn-group).
> >
> >       hope this helps..
> >
> >              oli
>