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

[Vikas Sharma]

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 <stig.johansen at ementor.no> 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
>
> vsharma6 at nms4:~$ telnet mas1.zrh
> mas1.zrh: node name or service name not known
> vsharma6 at nms4:~$ 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: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vikas Sharma
> Sent: 28. juli 2008 10:26
> To: Oliver Boehmer (oboehmer)
> Cc: cisco-nsp at puck.nether.net
> 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) <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
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>