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

[Oliver Boehmer (oboehmer)]

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