[rbak-nsp] additional ID in Radius request
Denis Mikhaylovskiy
denis.mikhaylovskiy at ericsson.com
Mon Jul 26 09:52:28 EDT 2010
Ok, understood,
In this case you can distinguish by NAS-Port-Id for instance as it indicates form where DISCOVER comes.
You can tune this attribute by issuing 'radius attribute nas-port-id format' command.
And yes, IP will be allocated after receiving access-request until you are using external dhcp server.
Cheers,
/denis
-----Original Message-----
From: Marcin Kuczera [mailto:marcin at leon.pl]
Sent: Monday, July 26, 2010 5:20 PM
To: Denis Mikhaylovskiy; redback-nsp at puck.nether.net
Subject: Re: [rbak-nsp] additional ID in Radius request
Denis Mikhaylovskiy wrote:
> The source context of access request is what you have specified in aaa global config. Or you may have aaa last-resort context. Or you can statically bind it to any context like this:
> dot1q pvc 100
> service clips dhcp context NAME
>
> So the answer is depending on your actual config.
dot1q pvc 15 encapsulation multi
service clips dhcp context clips
circuit protocol pppoe
bind authentication chap maximum 2000
dot1q pvc 3800 encapsulation multi
service clips dhcp context wifi1
circuit protocol pppoe
bind authentication chap maximum 2000
So, this is static bind however, there are 2 context that are used for
CLIPs - clips and wifi1
And - I want i.e. subscribers to be recognized from where they are
sourced (depending on PVC) and then bind them with one or second context.
If this is done by MAC address - this is not a problem, if IP is to be
allocated dynamically from pool and no MAC is analysed at authentication
time - it is a problem.
Our case - all CLIPS subscribers are authenticated allways even if they
are not defined in radius but..
- if they are defined in radius, they will receive IP from radius
(public) with proper profile
- if they are not defined in radius, they will receive IP from DHCP
(redback), private IP and from radius additionally profile with redirect
to "auathorized" website.
Regards,
Marcin
>
>
> Cheers,
> /denis
>
>
> -----Original Message-----
> From: Marcin Kuczera [mailto:marcin at leon.pl]
> Sent: Monday, July 26, 2010 4:34 PM
> To: Denis Mikhaylovskiy
> Cc: redback-nsp at puck.nether.net
> Subject: Re: [rbak-nsp] additional ID in Radius request
>
> Denis Mikhaylovskiy wrote:
>> Hi Marcin,
>>
>> It is dynamic clips, so context will be sent in acct-start, or in first acct-update (please make sure you have 'aaa accounting event dhcp' configured).
>> This is because access-request takes place before binding a clips session.
>
> So - how can we recognize which context is the source of access-request ?
> We have aaa auth subscriber global...
>
> It is necessary to split some common at the moment mechnism for
> information for unauthenticaded subscribers (different websites for
> different contexts).
>
> Marcin
>
>
>
>
>>
>> Cheers,
>> /denis
>>
>>
>> -----Original Message-----
>> From: redback-nsp-bounces at puck.nether.net [mailto:redback-nsp-bounces at puck.nether.net] On Behalf Of Marcin Kuczera
>> Sent: Monday, July 26, 2010 3:31 PM
>> To: redback-nsp at puck.nether.net
>> Subject: [rbak-nsp] additional ID in Radius request
>>
>> hello,
>>
>> is is possible so that in this request context from which the request is
>> sourced will be included ?:
>>
>> rad_recv: Access-Request packet from host 10.100.10.56 port 1812, id=7,
>> length=251
>> User-Name = "00:26:9e:60:d1:c4"
>> User-Password = "Redback"
>> Service-Type = Outbound-User
>> NAS-Identifier = "se100-test"
>> NAS-Port = 33816576
>> NAS-Real-Port = 603980580
>> NAS-Port-Type = Virtual
>> NAS-Port-Id = "2/4 vlan-id 804 clips 131150"
>> Medium-Type = DSL
>> Mac-Addr = "00-26-9e-60-d1-c4"
>> Platform-Type = 4
>> OS-Version = "6.2.1.2"
>> Redback-Attr-202 = 0x3d3d070100269e60d1c4
>> Redback-Attr-202 = 0x0c0c0d61646d696e2d73746174696f6e
>> Redback-Attr-125 = 0x4d53465420352e30
>>
>>
>> Regards,
>> Marcin
>> _______________________________________________
>> redback-nsp mailing list
>> redback-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/redback-nsp
>>
>
>
More information about the redback-nsp
mailing list