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

[Stig Johansen]

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
user-authentication in a firewall, 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/