Defining rule using framed-ip-address attribute

[asmash_]

Hi,

We are using SBR Provider Edition (SPE) as for GPRS traffic.

Need to define a rule based on framed-ip-address segment (which usually a single IP address in Acct request). In other word, we want to segregate the traffic based on framed-ip-address segment.

As for example, if Acct request is generated for 10.10.10.0/24 user IP which is a segment of 10.10.0.0/16 (entire pool), the realm will be different.

Can someone help me in this regard?

Thanks,

asmash

[jcanchola_]

You could try setting the account attribute map rule in the proxy.ini for Framed-IP-Address = 10.10.10*. Have you tried that already?

What is your current procedure for mapping the accounting request? Can you attach your proxy.ini?

[asmash_]

Hi Jcanchola,

I'll send you the proxy.ini shortly.

In real case, how can we mention the IP address start and end? Something like 10.10.10.20 to 10.10.10.180.

Thanks,

asmash

[apaul_]

Hi Asmash,

I do not think the Attribute map_ section support the range as per your description.

As far as I know, Ipaddr wildcarding in Attribute map_ section_ is only allowed in format as 192.168.100.*_

Hope this helps

[asmash_]

Well! Paul,

So, can we define multiple framed-ip-address to cover the whole chunk?

Target: 10.10.0.0/22

framed-ip-address=10.10.0.*

framed-ip-address=10.10.1.*

framed-ip-address=10.10.2.*

framed-ip-address=10.10.3.*

BR,

asmash

[apaul_]

Hi Asmash,

Be aware that each RealmName entry in an [AuthAttributeMap] or [AcctAttributeMap] section is examined in sequence from top to bottom. Within each RealmName entry, each rule is evaluated in sequence from top to bottom.

The results are:
If all of the rules in a RealmName entry evaluate to true, the packet is routed to the realm called RealmName and the remaining entries in the attribute map are ignored.

If any of the rules in a RealmName entry evaluate to false, this entry does not result in a mapping. Steel-Belted Radius Carrier evaluates the next entry in the map.

[asmash_]

Hi Paul,

Then what could be the solution to map a Realm based on particular framed-IP-address segment (let's say /22) ?

BR,

asmash

[jcanchola_]

It might be easier if you tell us how you are assigning the address.

Are there any radius attributes that are used to assign the address to the subscriber, and is it SBR that is doing the address assignment?

Are there any other unique attributes that we can use for the mapping?

[asmash_]

Actually, User IP (framed-ip-address) is assigned by NAS and forward the Accouting Start message to SBR (Proxy). SBR select particular Realm based on AcctAttributeMap (APN, User-name attributes) and forward it as end nodes.

Two NAS allocates IP address dynamically from the pool 10.8.0.0/13 and 10.16.0.0/13 respectively.

At present AcctAttributeMap DO NOT check framed-ip-address value rather it rely on APN and User-name to distinguish realm and forwards it to two different destination (D1, D2).

Existing Topology:

NAS01 (10.8.0.0/13) -> SBR01 -> D1

and

NAS02 (10.16.0.0/13) _-> SBR01 -> D2

Now we need to insert framed-ip-address into consideration as a portion of NAS01 Acct message has to be forwarded to D2 insted of D1 while rest part will follow as it is (i.e. D1).

Topology to be Designed:

NAS01 (10.8.0.0/13) -> SBR (if targetted IP segment, 10.10.0.0/22) -> D2

NAS01 (10.8.0.0/13) _-> SBR (rest IP of 10.8.0.0/13) -> D1

and

NAS02 (10.16.0.0/13) _-> SBR -> D2

_

Thanks,

asmash

[jcanchola_]

How does the NAS make the decision to assign the address from the 10.10.0.0/22_ segment?

Is SBR doing the authentication for the subscriber?

Ultimately we need to find something unique that we might be able to key on to map the request. If SBR is doing the authentication we might be able to embed an attribute in the class attribute so that we can then use that for the account attribute map.

The JavaScript module will be able to do this based on the framed-IP attribute, but if we can find something unique in the request that would be significantly easier to configure.