Hi Oli / Stig, Thanks for the reply.
Oli - Let me see if I can use ISG.. Stig - Here "user-authentication in a firewall" the issue is I do not have control plane information, I just have IP subnet and VRF. On that basis my authentication will not work. Even I thought of creating vrf's on the operator ASBR, but the issue is I have to create so many e-bgp session based on every customer, my router will be down :) Regards, Vikas Sharma On 7/28/08, Stig Johansen <[EMAIL PROTECTED]> wrote: > > Hi there, > > You should separate the customers in the LAC at your service provider. > Either in different VRF's or at least in different IP-subnets. The best > would be if you could get the provider to use *your* RADIUS-server for > authenticating. They could do a proxy and stripping unwanted > parameters/adding their internal parameters at their end. This way you > could control which IP-subnet the different users (your customers) get > and do some VRF-selection based on source-addresses at your "LNS". > > Since the PPP-connection is terminated in the LAC at the > service-provider, you won't be able to do any re-negotiating as in a > LAC/LNS L2TP-setup. The alternative would then be to do a > > [EMAIL PROTECTED]:~$ telnet mas1.zrh > mas1.zrh: node name or service name not known > [EMAIL PROTECTED]:~$ telnet MAS1.ZRH > MAS1.ZRH: node name or service name not known > but I belive this would be a negative > impact for the users. > > Best regards, > Stig Meireles Johansen > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Vikas Sharma > Sent: 28. juli 2008 10:26 > To: Oliver Boehmer (oboehmer) > Cc: [email protected] > Subject: Re: [c-nsp] mpls option A with LAC and LNS > > 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) <[EMAIL PROTECTED]> 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:[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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
