Glen,

Thanks for your comments. So if I don't use the command "aaa configuration config-username", what you are saying is that, I can still achieve my goal of assigning NAS based IP pools to the general users (to get a different IP address depending on whether they're in Melbourne or Sydney) and still be able to assign a specific IP address to the "3rd_party" group.

For example

user_group = "3rd_party", IP_pool = 192.168.1.1-9

user = john1 from ACS database, IP_pool = uses the group setting

user = john2 from ACS database, IP_pool = uses the group setting

user = john3 from ACS database, IP_pool = uses the group setting

user_group = "user_general", IP_pool = not assign

user = unknown users from NDS database, IP_pool = uses the group setting

user_group = "NAS_mel", IP_pool = not assign

user = "pools-mel", IP_pool = 192.168.1.65-254

user_group = "NAS_syd", IP_pool = not assign

user = "pools-syd", IP_pool = 192.168.2.65-254

So the above approach should work right?

But the IP pool is still linked to the userid, so regardless of whether they're in Melbourne or Sydney they'd still get the ame IP address, which is not what you want.

Remember, the individual user ID has an IP pool defined in it, whne they authenticate that pool name is sent to the NAS. The NAS then does another request to the Radius server to get an address from that pool. So the specific pool is still assigned to the user ID. Unless you move the user from group NAS_mel to NAS_syd when they travel they'll still get the same IP address, and this is not what you want to have to do.

I'm not sure of a way to do this automatically other than put the IP pool onto the NAS itself, then whatever NAS they dial into they'll use that pool.

Hi Glen,

May be my example was not clear, there are 2 types of user groups, one called "general users" and all of the users ion this groups are actually coming through "unknown user" through NDS. In this user group, IP pool field is empty. (These are the users that move between Sydney and Melbourne)

Then the 2nd type of groups is called "3rd_party", which contains the 3rd party users which are created in the ACS database. In this group, there is a IP pool assign which is 192.168.1.1-9. (These are the users that only come through Melbourne)

Then there are two more user groups namely

user_group = "NAS_mel", IP_pool = not assign

user = "pools-mel", IP_pool = 192.168.1.65-254

user_group = "NAS_syd", IP_pool = not assign

user = "pools-syd", IP_pool = 192.168.2.65-254

So now when the 3rd part user dials in Melbourne NAS (this is where they'll always dial) they'll get an IP address from pool "192.168.1.1-9". All is good!

When any of the general users dial in Melbourne NAS, because their user group "general users" does not have an IP pool assigned, then the Melbourne NAS should check under the default name "pools-mel" user ("mel" is the name of the NAS), there is an IP pool assign to this user, therefore this general user should gets an IP address from pool "192.168.1.65-254".

A similar thing will happen for the Sydney NAS.

So this way any of the users in the "general users" group will get an IP address from "pool-syd" if they dial via Sydney NAS or will get an IP address from "pool-mel" if they dial via Melbourne.

Am I correct?

Regards

This could be possible, but I think both user groups (NAS_mel and NAS_syd) should have a pool reference defined (say pool1). After that two users mel-pools and syd-pools should have the actual definition of the pool1 pool (two different definitions as your setup requires).

The following is from the Free TAC+ docs:

pool-def# (PPP/IP, 11.2(4)F)

This attribute is used to define ip address pools on the NAS.

During IPCP address negotiation, if an ip pool name is

specified for a user (see the addr-pool attribute), a check is

made to see if the named pool is defined on the NAS. If it is,

the pool is consulted for an ip address.

If the required pool is not present on the NAS (either in the

local config, or as a result of a previous download

operation), then an authorization call to obtain it is

attempted, using the special username:

-pools

where is the configured name of the NAS.

Note: This username can be changed using the IOS configuration

directive e.g.

aaa configuration config-name nas1-pools-definition.cisco.us

The pool-def attribute is used to define ip address pools for

the above authorization call e.g.

user = foo {

login = cleartext lab

service = ppp protocol = ip {

addr-pool=bbb

}

}

user = nas1-pools {

service = ppp protocol = ip {

pool-def#1 = "aaa 1.0.0.1 1.0.0.3"

pool-def#2 = "bbb 2.0.0.1 2.0.0.10"

pool-def#3 = "ccc 3.0.0.1 3.0.0.20"

pool-timeout=60

}

}

In the example above is a configuration file fragment for defining 3

pools named "aaa", "bbb" and "ccc" on the NAS named "nas1".

When the user "foo" refers to the pool named "bbb", if the

pool "bbb" isn't defined, the NAS will attempt to download the

definition contained in the "nas1-pools" entry.

The other pools will also be defined at the same time (or they

will be ignored if they are already defined).

Since this procedure is only activated when an undefined pool

is referenced, one way to redefine a pool once it has been

downloaded is to manually delete the definition e.g. by

logging into the NAS, enabling, and configuring:

config t

no ip local pool bbb

^Z

When a pool is deleted, there is no interruption in service

for any user who is currently using a pool address. If a pool

is deleted and then subsequently redefined to include a pool

address that was previously allocated, the new pool will pick

up the allocated address and track it as expected.

Since downloaded pools do not appear in the NAS configuration,

any downloaded pool definitions automatically disappear

whenever a NAS reboots. These pools are marked as "dynamic"

when they appear in the output of the "show ip local pools"

NAS command.

Since it is desirable not to have to manually delete pools to

redefine them, the AV pair pool-timeout= can be used to

timeout any downloaded pool definitions. The timeout is in

minutes.

The effect of the pool-timeout attribute is to start a timer

when the pool definitions are downloaded. When the timer

expires, the pools are deleted. The next reference to a

deleted pool via will cause a re-fetch of the pool

definitions. This allows pool changes to be made on the

daemon and propagated to the NAS in a timely manner.

See also:

sho ip local pool

sho ip local pool

IOS commands:

ip local pool

Oleg Tipisov,

REDCENTER,

Moscow