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

[Vikas Sharma]

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
>
>