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:[EMAIL PROTECTED]> 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) <[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/
