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:[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
