assigning IP pools thru ACS

Unanswered Question
Sep 17th, 2003
User Badges:

We have 2 NASs, in two cities. Currently the IP pool is configured on the NASs for Group-async1.


We want to be able to apply access-lists per user groups. We are planning to create various IP pools on the ACS and assigned it the relevant user groups and then remove the IP pool from the NAS.


This would work if the remote users would not travel between the cities, however they need to travel and hence some time the assigned IP address for a particular remote user could be in one city and other times in the other city. We also have another user-group (3rd_party) that do not need to travel and always come in through one of the NASs.


Is there a way to solve this problem and achieve our aim? I thought we could define the various IP-pools on the NASs and then reference it in the user-groups setting on the ACS. This would work for various "3rd_party" groups but would not for the remote users who travel between the cities. I came across this command


aaa configuration config-username <name >

http://www.cisco.com/en/US/customer/products/sw/secursw/ps4911/products_tech_note09186a0080118d82.shtml


I think this command will solve my problem. i.e. for various remote users that do not travel between sites I can create a number of user groups and assign various IP-pools to them in the ACS configuration. Then for users that do travel between sites (majority), I would again create relevant user groups on ACS but this time will not assign any IP-pools to them. Then with the help of aaa configuration config-username <name> command on the NAS and its counterpart on ACS they will get assign relevant IP addresses.


What do you think?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gfullage Thu, 09/18/2003 - 18:54
User Badges:
  • Cisco Employee,

Ariya,


Apologies for not getting back to you sooner, been snowed under lately.


First off, I must admit I'm not sure if this works on CSNT. The sample you linked to is for CSU which I have tested it on before, I don't see why it wouldn't work with CSNT but haven't tested it personally.


Keep in mind also that all this command does is change the name the NAS will use to look for the pool. If you don't have this command it'll send a request for the IP pool to ACS using the default user name of "pools-NAS", where NAS is the NAS name. Using this command simply changes that name to whatever you enter after the command.


Also, the IP pool is still linked to the specific user ID, not the NAS. The individual userid has an IP pool name defined in it, which then points to a pool defined under the "pools-NAS" user, so the same user, whether they're in Melbourne or Sydney will get an IP address out of the same pool. Don't you want them to get a different IP address depending on whether they're in Melbourne or Sydney (I would think so otherwise how is your internal routing going to work)?

arparsamanesh Thu, 09/18/2003 - 21:16
User Badges:

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?

gfullage Fri, 09/19/2003 - 18:49
User Badges:
  • Cisco Employee,

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.

arparsamanesh Sun, 09/21/2003 - 22:40
User Badges:

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


Actions

This Discussion