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

[Oliver Boehmer (oboehmer)]

Well. I guess the easiest method is to have the operator forward you the
sessions via L2TP to your LNS so you can terminate and authenticate
them, using the method I indicated in my initial reply.

I don't know ISG well enough to advice, but
http://www.cisco.com/en/US/docs/ios/12_2sb/isg/configuration/guide/isb_i
p.html shows how this can be used to handle "IP sessions". Maybe someone
else will be able to comment further.  

	oli

Vikas Sharma <mailto:vikassharmas at gmail.com> wrote on Monday, July 28,
2008 10:26 AM:

> 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