[rbak-nsp] additional ID in Radius request

[Marcin Kuczera]

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
>>
> 
>