Hash username or mac address to assign user to different vlan
Hi All, I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs. For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } } Will I be able to do this in the post-auth with unlang? Thanks, Schilling ---------- Forwarded message ---------- From: schilling <schilling2006@gmail.com> Date: Tue, Jan 25, 2011 at 10:19 AM Subject: Re: dynamic VLAN assignment w/ mschapv2 against AD and LDAP To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> I believe I resolved this. I used eapol_test to get all wanted result, and will try on real NAS later on. The following is what I did. Basically I followed Alexander's example, Modified peap section in eap.conf to use another virtual server "auth" instead of inner-tunnel virtual server. I almost blindly copied Alexander's example in auth server except I removed the reject for the realm checks. The ldap cache pm is not needed in my case since I do not query windows AD via LDAP to get their attributes. If I want to do ldap after ntlm against AD, then Alexander's pm might be needed. Then I want to map certain attribute like employeeStatus from our iPlanet ldap server to some radius attribute, so I can manipulate it in the post-auth section. I put the following line in etc/raddb/dictionary ATTRIBUTE My-Local-employeeStatus 3000 string and the following line in etc/raddb/ldap.attrmap #FOO specific attributes replyItem My-Local-employeeStatus employeeStatus Without these two line addition, radius will complain unknown attribute. Then in the post-auth section #default will have no Tunnel attribute/value, instead, they will be configured on #the NAS to go to student VLANs. # this will cover my ldap ntPassword authentication/authorization #facstaff have employeeStatus set while student does not if ( "%{User-Name}" =~ /@/ && "%{reply:My-Local-employeeStatus}" ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff" } } #this will cover my AD ntlm auth, People in AD are all facstaff if ( "%{User-Name}" !~ /@/ ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff" } } In this way, people can map arbitrary attribute from ldap to radius, if not in dictionary/ldap.attrmap, then just defined your own. Then you have flexibility of using these attribute/value in your logic at post-auth section. Thanks all for the hints and help! Schilling
schilling <schilling2006@gmail.com> wrote:
I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs.
You are however not reducing the broadcast domain, you might be segregating the noise though. If you have large L2 broadcast domains, splitting people up into different VLAN's is not going to in effect solve the problem. For background noise, you can actually reduce chatter by asking Windows clients to disable NetBEUI via DHCP and configure switches/wifi to not forward client<->client traffic where appropriate. For wireless networks you can also kill a lot of multicast traffic (5353/udp is a good example I would say). Another possible work around is that VLAN 'facstaff' at site A is not the same broadcast domain at site B. Better still, L3 is the way to go. We have and it solves a lot of problems, although there is upfront migration pains.
For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } }
Will I be able to do this in the post-auth with unlang?
You probably would get better millege calling on 'md5' xlat, I think the following sort of thing will work: ---- authorise { update reply { Service-Type := Framed-User Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 } # kludge to fake substr() if (%{md5:%{User-Name}} =~ /^(.)/) { if (%{1} =~ /^[0-7]/) { update reply { Tunnel-Private-Group-Id := "facstaff0" } } else { update reply { Tunnel-Private-Group-Id := "facstaff1" } } } } ---- I would recommend L3-ising your network though if possible and as the rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise to a minimum. Cheers -- Alexander Clouter .sigmonster says: RAM wasn't built in a day.
I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is. First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea. The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone. Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group. Anyway, that is my 2 cents on the whole deal. Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE
On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
schilling <schilling2006@gmail.com> wrote:
I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs.
You are however not reducing the broadcast domain, you might be segregating the noise though. If you have large L2 broadcast domains, splitting people up into different VLAN's is not going to in effect solve the problem. For background noise, you can actually reduce chatter by asking Windows clients to disable NetBEUI via DHCP and configure switches/wifi to not forward client<->client traffic where appropriate. For wireless networks you can also kill a lot of multicast traffic (5353/udp is a good example I would say). Another possible work around is that VLAN 'facstaff' at site A is not the same broadcast domain at site B. Better still, L3 is the way to go. We have and it solves a lot of problems, although there is upfront migration pains.
For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } }
Will I be able to do this in the post-auth with unlang?
You probably would get better millege calling on 'md5' xlat, I think the following sort of thing will work: ---- authorise { update reply { Service-Type := Framed-User Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 } # kludge to fake substr() if (%{md5:%{User-Name}} =~ /^(.)/) { if (%{1} =~ /^[0-7]/) { update reply { Tunnel-Private-Group-Id := "facstaff0" } } else { update reply { Tunnel-Private-Group-Id := "facstaff1" } } } } ---- I would recommend L3-ising your network though if possible and as the rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise to a minimum. Cheers -- Alexander Clouter .sigmonster says: RAM wasn't built in a day. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Feb 17, 2011 at 02:26:14PM -0800, Brett Littrell wrote:
I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is.
First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea.
The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone.
Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group.
Anyway, that is my 2 cents on the whole deal.
Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE
I agree with you that random VLAN selection is not a good idea and it wrecks havoc with most clients too. However, the problem we ran into was balancing the usage of all of the VLANS to get both good performance and minimize infrastructure costs. This can be done by assigning to groups and then placing in the VLAN according to that group, but then you have the problem of balancing the assignment to the named groups. In the end, we used the hash function because it would deterministically assign a user to a VLAN and balanced the hardware usage reasonably well. We used the simple crc32, but a better hash function would distribute them even better if all were connected simultaneously, but a crc32 was easy and the size of the groups was within 10%. Calculating the group members is easy, but they already have that information from VLAN/IP address of the machine. It is also easy to have the network gear return who is attached and what VLAN they are in. My 1.5 cents. :) Ken
On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
schilling <schilling2006@gmail.com> wrote:
I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs.
You are however not reducing the broadcast domain, you might be segregating the noise though. If you have large L2 broadcast domains, splitting people up into different VLAN's is not going to in effect solve the problem.
For background noise, you can actually reduce chatter by asking Windows clients to disable NetBEUI via DHCP and configure switches/wifi to not forward client<->client traffic where appropriate. For wireless networks you can also kill a lot of multicast traffic (5353/udp is a good example I would say).
Another possible work around is that VLAN 'facstaff' at site A is not the same broadcast domain at site B.
Better still, L3 is the way to go. We have and it solves a lot of problems, although there is upfront migration pains.
For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } }
Will I be able to do this in the post-auth with unlang?
You probably would get better millege calling on 'md5' xlat, I think the following sort of thing will work: ---- authorise { update reply { Service-Type := Framed-User Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 }
# kludge to fake substr() if (%{md5:%{User-Name}} =~ /^(.)/) { if (%{1} =~ /^[0-7]/) { update reply { Tunnel-Private-Group-Id := "facstaff0" } } else { update reply { Tunnel-Private-Group-Id := "facstaff1" } } } } ----
I would recommend L3-ising your network though if possible and as the rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise to a minimum.
Cheers
-- Alexander Clouter .sigmonster says: RAM wasn't built in a day.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OT from OP question, but have you ever thought of PVLANs, VACLs, PACLs, broadcast storm control, etc. Not sure how many users you're talking about, and what apps, but with prudent configs many thousands of users "can" exist on a single VLAN without concern. ----- Original Message ----- From: Kenneth Marshall [mailto:ktm@rice.edu] Sent: Thursday, February 17, 2011 05:52 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Hash username or mac address to assign user to different vlan On Thu, Feb 17, 2011 at 02:26:14PM -0800, Brett Littrell wrote:
I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is.
First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea.
The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone.
Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group.
Anyway, that is my 2 cents on the whole deal.
Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE
I agree with you that random VLAN selection is not a good idea and it wrecks havoc with most clients too. However, the problem we ran into was balancing the usage of all of the VLANS to get both good performance and minimize infrastructure costs. This can be done by assigning to groups and then placing in the VLAN according to that group, but then you have the problem of balancing the assignment to the named groups. In the end, we used the hash function because it would deterministically assign a user to a VLAN and balanced the hardware usage reasonably well. We used the simple crc32, but a better hash function would distribute them even better if all were connected simultaneously, but a crc32 was easy and the size of the groups was within 10%. Calculating the group members is easy, but they already have that information from VLAN/IP address of the machine. It is also easy to have the network gear return who is attached and what VLAN they are in. My 1.5 cents. :) Ken
On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
schilling <schilling2006@gmail.com> wrote:
I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs.
You are however not reducing the broadcast domain, you might be segregating the noise though. If you have large L2 broadcast domains, splitting people up into different VLAN's is not going to in effect solve the problem.
For background noise, you can actually reduce chatter by asking Windows clients to disable NetBEUI via DHCP and configure switches/wifi to not forward client<->client traffic where appropriate. For wireless networks you can also kill a lot of multicast traffic (5353/udp is a good example I would say).
Another possible work around is that VLAN 'facstaff' at site A is not the same broadcast domain at site B.
Better still, L3 is the way to go. We have and it solves a lot of problems, although there is upfront migration pains.
For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } }
Will I be able to do this in the post-auth with unlang?
You probably would get better millege calling on 'md5' xlat, I think the following sort of thing will work: ---- authorise { update reply { Service-Type := Framed-User Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 }
# kludge to fake substr() if (%{md5:%{User-Name}} =~ /^(.)/) { if (%{1} =~ /^[0-7]/) { update reply { Tunnel-Private-Group-Id := "facstaff0" } } else { update reply { Tunnel-Private-Group-Id := "facstaff1" } } } } ----
I would recommend L3-ising your network though if possible and as the rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise to a minimum.
Cheers
-- Alexander Clouter .sigmonster says: RAM wasn't built in a day.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
I have been asked to do just this and I am working on the solution now.
We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
In my tests I have been creating a hash from the 'State' attribute which seems reasonably random and gives me a good even share across the VLANs in my pools, but would be completely non-deterministic. (My tests are not real world so this could prove untrue).
A hash on User-Name may be more deterministic, but may not give me the balance I need.
Students and Staff have different format usernames so I am sure this would result in un-balanced sharing across the VLAN pools. And we have un-even numbers of students on different courses and their usernames start the same.
I am using a perl module called within post-auth that does some LDAP lookups as well to find the type of the user.
Nothing is set in stone yet and I am still experimenting, I feel sure whatever method I use will end up being a "I wouldn't start from here" solution in 12 months time!
# Staff in our world means Staff + Research Postgrads and Students are Students + Taught Postgrads...
On 17 Feb 2011, at 23:52, Kenneth Marshall wrote:
> On Thu, Feb 17, 2011 at 02:26:14PM -0800, Brett Littrell wrote:
>> I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is.
>>
>> First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea.
>>
>> The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone.
>>
>> Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group.
>>
>> Anyway, that is my 2 cents on the whole deal.
>>
>>
>> Brett Littrell
>> Network Manager
>> MUSD
>> CISSP, CCSP, CCVP, MCNE
>
> I agree with you that random VLAN selection is not a good idea and it
> wrecks havoc with most clients too. However, the problem we ran into was
> balancing the usage of all of the VLANS to get both good performance and
> minimize infrastructure costs. This can be done by assigning to groups
> and then placing in the VLAN according to that group, but then you have
> the problem of balancing the assignment to the named groups. In the end,
> we used the hash function because it would deterministically assign a
> user to a VLAN and balanced the hardware usage reasonably well. We used
> the simple crc32, but a better hash function would distribute them even
> better if all were connected simultaneously, but a crc32 was easy and
> the size of the groups was within 10%. Calculating the group members
> is easy, but they already have that information from VLAN/IP address of
> the machine. It is also easy to have the network gear return who is
> attached and what VLAN they are in.
>
> My 1.5 cents. :)
>
> Ken
>>
>>>>> On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
>>
>> schilling <schilling2006@gmail.com> wrote:
>>>
>>> I get dynamic VLAN assignment working in post-auth section with
>>> help/hints from a lot of list members. Now I want to do one more
>>> steps. I would like to hash the username or mac-address to distribute
>>> users to different VLANs. The idea is to use freeradius to spread the
>>> load on different smaller subnets to reduce the broadcast in bigger
>>> VLANs.
>>>
>> You are however not reducing the broadcast domain, you might be
>> segregating the noise though. If you have large L2 broadcast domains,
>> splitting people up into different VLAN's is not going to in effect
>> solve the problem.
>>
>> For background noise, you can actually reduce chatter by asking Windows
>> clients to disable NetBEUI via DHCP and configure switches/wifi to not
>> forward client<->client traffic where appropriate. For wireless networks
>> you can also kill a lot of multicast traffic (5353/udp is a good example
>> I would say).
>>
>> Another possible work around is that VLAN 'facstaff' at site A is not
>> the same broadcast domain at site B.
>>
>> Better still, L3 is the way to go. We have and it solves a lot of
>> problems, although there is upfront migration pains.
>>
>>> For example I want to do the following
>>> if ( "%{User-Name}" !~ /@/ ) {
>>> if ( %{User-Name}%2 == 0 ) {
>>> update reply {
>>> Service-Type = "Framed-User"
>>> Tunnel-Type = "VLAN"
>>> Tunnel-Medium-Type = "IEEE-802"
>>> Tunnel-Private-Group-Id = "facstaff0"
>>> }
>>> elsif ( %{User-Name}%2 == 1 ) {
>>> update reply {
>>> Service-Type = "Framed-User"
>>> Tunnel-Type = "VLAN"
>>> Tunnel-Medium-Type = "IEEE-802"
>>> Tunnel-Private-Group-Id = "facstaff1"
>>> }
>>> }
>>> }
>>>
>>> Will I be able to do this in the post-auth with unlang?
>>>
>> You probably would get better millege calling on 'md5' xlat, I think
>> the following sort of thing will work:
>> ----
>> authorise {
>> update reply {
>> Service-Type := Framed-User
>> Tunnel-Type := VLAN
>> Tunnel-Medium-Type := IEEE-802
>> }
>>
>> # kludge to fake substr()
>> if (%{md5:%{User-Name}} =~ /^(.)/) {
>> if (%{1} =~ /^[0-7]/) {
>> update reply {
>> Tunnel-Private-Group-Id := "facstaff0"
>> }
>> } else {
>> update reply {
>> Tunnel-Private-Group-Id := "facstaff1"
>> }
>> }
>> }
>> }
>> ----
>>
>> I would recommend L3-ising your network though if possible and as the
>> rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise
>> to a minimum.
>>
>> Cheers
>>
>> --
>> Alexander Clouter
>> .sigmonster says: RAM wasn't built in a day.
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
----------------------
Barry Dean
Principal Programmer/Analyst
Networks Group
Computing Services Department
Tel: 0151 795 9540
Skype: barryvdean
On 18/02/11 14:16, Dean, Barry wrote:
I have been asked to do just this and I am working on the solution now.
We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
There is no such thing as an "interim" authentication request. Post-auth is called after every auth. I suspect you are referring to feature(s) on the switch(es) you use where it will "re-auth" the client after X minutes. That's just another, separate authentication as far as FreeRadius is concerned.
In my tests I have been creating a hash from the 'State' attribute
That's a very bad idea. It will change mid-session and cause you huge problems. We do pervasive VLAN assignment on a large scale here, and my advice is the same as others in the thread - don't use a hash value. Just map a user or group to a vlan. If you need to "balance the numbers of users on a vlan" (why?) then you should log the vlan assignments to SQL and run a post-processing script that changes the assignment to keep the "load balanced". Personally we just run big subnets to reduce the waste of IP space and configuration overhead.
what's your biggest subnet for the wireless? How do you deal with excessive broadcast protocols? Thanks, Schilling On Fri, Feb 18, 2011 at 9:26 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 18/02/11 14:16, Dean, Barry wrote:
I have been asked to do just this and I am working on the solution now.
We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
There is no such thing as an "interim" authentication request.
Post-auth is called after every auth.
I suspect you are referring to feature(s) on the switch(es) you use where it will "re-auth" the client after X minutes. That's just another, separate authentication as far as FreeRadius is concerned.
In my tests I have been creating a hash from the 'State' attribute
That's a very bad idea. It will change mid-session and cause you huge problems.
We do pervasive VLAN assignment on a large scale here, and my advice is the same as others in the thread - don't use a hash value. Just map a user or group to a vlan.
If you need to "balance the numbers of users on a vlan" (why?) then you should log the vlan assignments to SQL and run a post-processing script that changes the assignment to keep the "load balanced".
Personally we just run big subnets to reduce the waste of IP space and configuration overhead. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 18/02/11 14:34, schilling wrote:
what's your biggest subnet for the wireless?
Our entire wireless network is one /19, but our wireless system is a Cisco lightweight that does "clever" things with broadcast, DHCP and ARP traffic. However, we have lots of wired subnets which are /21, some with >1000 hosts on them.
How do you deal with excessive broadcast protocols?
We do nothing. We used to be very worried about this, but in practice we've found it's a non-existent problem. The world isn't 10Mbit/half-duplex ethernet any more ;o) (Layer2 security is a different matter)
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
How do you deal with excessive broadcast protocols?
We do nothing. We used to be very worried about this, but in practice we've found it's a non-existent problem. The world isn't 10Mbit/half-duplex ethernet any more ;o)
...it supposedly nukes the ability for workstations to do power saving (broadcast packets are always processed kernel land) and as broadcast/multicast is limited to the lowest common denominator speed for wireless network's, it can have a pained effect (no doubt most places are still set at 1Mbps). 500 Windows workstations on my local LAN would annoy my NO_HZ laptop :) Cheers -- Alexander Clouter .sigmonster says: Your present plans will be successful.
Here at Georgia Tech, I had to design a system to do VLAN steering based on a number of criteria (including hashing based on MAC). Because I know MySQL and the like MUCH better than freeradius configuration, that's where we moved the logic to by using stored functions. This system also has the ability to disable a given VLAN (in the event of catastrophic system/network issues) by the inclusion of a new table called "radhashgroup" which looks like: mysql> select * from radhashgroup +----+-----------+---------------+---------+ | id | groupname | chain | status | +----+-----------+---------------+---------+ | 1 | vlan1296 | authenticated | ACTIVE | | 2 | vlan1296 | stateful | STANDBY | | 3 | vlan0316 | authenticated | STANDBY | | 4 | vlan0316 | stateful | STANDBY | | 6 | vlan0808 | stateful | ACTIVE | | 7 | vlan1312 | stateful | ACTIVE | +----+-----------+---------------+---------+ In the above scheme, we have two kinds of networks for WPA, one with stateful packet inspection (no inbound without an outbound request) called "stateful" and the other which has the inbound firewall turned off, historically called "authenticated". We also have a new table that allows people to request to be put into one group or the other (in case there are more than one "authenticated" vlans in the future) with the table "user_prefs": +----+--------------+-------------------+---------------+ | id | username | mac_address | chain | +----+--------------+-------------------+---------------+ | 3 | aa66617 | 58:b0:35:67:55:9b | authenticated | | 6 | rdearux3 | 00:aa:5e:38:4b:6e | authenticated | | 11 | frapp66 | 00:1f:ff:d8:bc:ff | authenticated | | 8 | snark340 | 00:03:cc:12:92:54 | authenticated | The system has the following features: 1) VLAN based steering based on username only, mac address only, username and mac address pairing (this is based on "priority" which I believe is explained in my SQL logic better) 2) VLAN steering based on type of connection (inbound security on or off) that still utilizes the MAC based vlan hashing 2) The ability to turn off a given "group" or in our case "vlan" if something really really bad happens. Granted, this will require the user to re-authenticate to get the new VLAN, but it's better than a longer term system outage. I have NEVER had to use this (knock on wood) yet. :) As you can see, we have two "stateful" networks and one "authenticated" network. The above table allows us to add new networks in as needed and as we migrate our captive portal IP ranges to GTwpa as we encourage it's use over the old way. I did have to modify the radusergroup table slightly so that it looks like: +-----+-------------------+-------------------+-----------+-----------+----------+--------------------------+ | id | username | mac_address | source_ap | groupname | priority | comment | +-----+-------------------+-------------------+-----------+-----------+----------+--------------------------+ | 123 | equevedo3 | 00:14:d1:c8:02:ec | | vlan0316 | 100 | block_id:3258 | | 253 | inorris3 | | | vlan0316 | 100 | block_id:3697 | | 223 | | 00:aa:c6:d0:bf:ff | | vlan1987 | 200 | tablet 1 | We have two radius servers and I use the id to keep a central table in sync with the outlying tables on either radius server. The priority comes in when we talk about which VLAN preference takes priority. The MySQL functions that I designed look as follows: # Separate file of the functions we use for WPA # # Instantiate by: # # mysql -u radius -p radius_wpa < wpa-db-functions.sql # ### # We need to use the radius database :) # use radius_wpa; ### # Add our custom MySQL stored procedures # ### # function: simpleHash(string, number of buckets) returns <0 - (number of buckets - 1)> # DROP FUNCTION IF EXISTS simpleHash; DELIMITER | CREATE FUNCTION simpleHash(hashthis VARCHAR(30), hashsize INT) RETURNS INT DETERMINISTIC BEGIN DECLARE hashval INT; DECLARE hashme VARCHAR(30); SET hashme = UPPER(hashthis); SET hashval = CONV(SUBSTR(md5(hashme),-8),16,10) % hashsize; RETURN hashval; END| DELIMITER ; ### # function: determineGroupByHash(string) returns groupname defined in table radhashgroup which corresponds to radgroupreply table entries # DROP FUNCTION IF EXISTS determineGroupByHash; DELIMITER | CREATE FUNCTION determineGroupByHash(client_mac VARCHAR(17), client_username VARCHAR(64)) RETURNS VARCHAR(64) DETERMINISTIC BEGIN DECLARE hashval INT; DECLARE hashsize INT; DECLARE chain_pref VARCHAR(32); DECLARE returngroup VARCHAR(64); DECLARE rownum INT; SET @rownum = -1; SET chain_pref = determinePreferredChain(client_mac, client_username); SELECT count(*) INTO hashsize FROM radhashgroup WHERE status = 'ACTIVE' AND chain = chain_pref; SET hashval = simpleHash(client_mac, hashsize); SELECT r1.groupname INTO returngroup FROM (SELECT @rownum:=@rownum+1 AS hash_value, groupname FROM radhashgroup WHERE status = 'ACTIVE' AND chain = chain_pref ORDER BY groupname ASC) as r1 WHERE hash_value = hashval; RETURN returngroup; END| DELIMITER ; ### # function: determinePreferredChain(mac, user) returns preferred chain defined in table user_prefs # DROP FUNCTION IF EXISTS determinePreferredChain; DELIMITER | CREATE FUNCTION determinePreferredChain(client_mac VARCHAR(17), client_username VARCHAR(64)) RETURNS VARCHAR(64) DETERMINISTIC BEGIN DECLARE returnchain VARCHAR(64); IF EXISTS(SELECT chain FROM user_prefs WHERE (mac_address = client_mac AND username = client_username) LIMIT 1) THEN SELECT chain INTO returnchain FROM user_prefs WHERE (mac_address = client_mac AND username = client_username) LIMIT 1; ELSE SET returnchain = 'stateful'; END IF; RETURN returnchain; END| DELIMITER ; ### # function # # | Criteria | Priority | # +-----------------------------+----------+ # | User or MAC Blocks | 100 | -> blocks should direct user to one of the linux FWs captive portal # | MAC assignments | 200 | -> should be used SPARINGLY and only by admins # | Username + MAC assignments | 300 | -> user preferences for a specific device (this device when used by this user) # | Username assignments | 400 | -> user preference for (this user, all devices) # +-----------------------------+----------+ DROP FUNCTION IF EXISTS determineGroup; delimiter | CREATE FUNCTION determineGroup(client_mac VARCHAR(17), client_username VARCHAR(64)) RETURNS VARCHAR(64) BEGIN DECLARE returngroup VARCHAR(64); DECLARE clean_mac VARCHAR(17); SET clean_mac = REPLACE(LOWER(client_mac),'-',':'); IF EXISTS(SELECT groupname FROM radusergroup WHERE (mac_address = clean_mac OR username = client_username) ORDER BY priority LIMIT 1) THEN SELECT groupname INTO returngroup FROM radusergroup \ WHERE ((username = client_username OR mac_address = clean_mac) AND priority = 100) \ OR (mac_address = clean_mac AND priority = 200) \ OR (username = client_username AND mac_address = clean_mac AND priority = 300) \ OR (username = client_username AND priority = 400) \ OR (username = 'DEFAULT') \ ORDER BY priority ASC LIMIT 1; IF returngroup IS NULL THEN SELECT determineGroupByHash(clean_mac, client_username) INTO returngroup; END IF; ELSE SELECT determineGroupByHash(clean_mac, client_username) INTO returngroup; END IF; RETURN returngroup; END| delimiter ; What we have found is that the basic hash of the MAC address for MOST general users, results in a practically 50/50 split between the two "stateful" networks. (For our networks these are the 1312 and the 808 networks for the average users). My Freeradius sql configuration uses these procedures for assignments as such: group_membership_query = "SELECT determineGroup('%{Calling-Station-Id}','%{SQL-User-Name}') as groupname"; Again, perhaps this isn't ideal, and I wish my knowledge of ulang was better. :) But...it's been fantastically successful, modular, and allowed us to do some very...interesting things with our networks. ;) Thanks to all you guys on the list and especially Alan DeKok who's posts are most informative and often entertaining :) Attached is an example image of our VLAN distribution graph. it should show that the WPA users are pretty much distributed evenly between the two stateful networks given the simpleHash algorithm. Just my $0.02 of systems design. But it works :) Enjoy the day! On 02/18/2011 11:55 AM, Alexander Clouter wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
How do you deal with excessive broadcast protocols? We do nothing. We used to be very worried about this, but in practice we've found it's a non-existent problem. The world isn't 10Mbit/half-duplex ethernet any more ;o)
...it supposedly nukes the ability for workstations to do power saving (broadcast packets are always processed kernel land) and as broadcast/multicast is limited to the lowest common denominator speed for wireless network's, it can have a pained effect (no doubt most places are still set at 1Mbps).
500 Windows workstations on my local LAN would annoy my NO_HZ laptop :)
Cheers
On 18 Feb 2011, at 14:26, Phil Mayers wrote:
On 18/02/11 14:16, Dean, Barry wrote:
I have been asked to do just this and I am working on the solution now.
We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
There is no such thing as an "interim" authentication request.
Post-auth is called after every auth.
I suspect you are referring to feature(s) on the switch(es) you use where it will "re-auth" the client after X minutes. That's just another, separate authentication as far as FreeRadius is concerned
Yep, I was referring to the entries I see in my logs for "Interim-Update", which is of course an Accounting record, and I had always assumed this went with an Auth as well, but have never looked in detail to see! So I am most likely talking rubbish!
In my tests I have been creating a hash from the 'State' attribute
That's a very bad idea. It will change mid-session and cause you huge problems.
I will not be using this then :-)
We do pervasive VLAN assignment on a large scale here, and my advice is the same as others in the thread - don't use a hash value. Just map a user or group to a vlan.
If you need to "balance the numbers of users on a vlan" (why?) then you should log the vlan assignments to SQL and run a post-processing script that changes the assignment to keep the "load balanced".
Personally we just run big subnets to reduce the waste of IP space and configuration overhead.
I don't design the wireless network here, I just make the RADIUS work as best I can. It has been decided to have smaller private IP ranges each associated with a VLAN and balance the routing of these across two routers. Then I was asked if I can distribute the users across these VLANS evenly. I am beginning to think a round robin allocation might just do! However, the goal posts could move again yet! Latest news is that we will have 1 pool of VLANs, so time to tear up the existing code and take a fresh look! I currently have no idea how big these subnets will be either. ---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540 Skype: barryvdean
On Fri, Feb 18, 2011 at 03:02:49PM +0000, Dean, Barry wrote:
On 18 Feb 2011, at 14:26, Phil Mayers wrote:
On 18/02/11 14:16, Dean, Barry wrote:
I have been asked to do just this and I am working on the solution now.
We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
There is no such thing as an "interim" authentication request.
Post-auth is called after every auth.
I suspect you are referring to feature(s) on the switch(es) you use where it will "re-auth" the client after X minutes. That's just another, separate authentication as far as FreeRadius is concerned
Yep, I was referring to the entries I see in my logs for "Interim-Update", which is of course an Accounting record, and I had always assumed this went with an Auth as well, but have never looked in detail to see! So I am most likely talking rubbish!
In my tests I have been creating a hash from the 'State' attribute
That's a very bad idea. It will change mid-session and cause you huge problems.
I will not be using this then :-)
We do pervasive VLAN assignment on a large scale here, and my advice is the same as others in the thread - don't use a hash value. Just map a user or group to a vlan.
If you need to "balance the numbers of users on a vlan" (why?) then you should log the vlan assignments to SQL and run a post-processing script that changes the assignment to keep the "load balanced".
Personally we just run big subnets to reduce the waste of IP space and configuration overhead.
I don't design the wireless network here, I just make the RADIUS work as best I can. It has been decided to have smaller private IP ranges each associated with a VLAN and balance the routing of these across two routers. Then I was asked if I can distribute the users across these VLANS evenly.
This was the initial request from our network group as well.
I am beginning to think a round robin allocation might just do!
That is what they asked for, but the key is to provide a persistent VLAN allocation for the length of the client's connection to the network. You can either cache the current VLAN assignment from a pure round-robin allocation which requires managing the information, expiring it as needed and other sorts of maintenance activities. In the end, using the hash of a static client parameter such as User-Name or MAC address gives you an even distribution without the maintenance headaches. Cheers, Ken
However, the goal posts could move again yet! Latest news is that we will have 1 pool of VLANs, so time to tear up the existing code and take a fresh look! I currently have no idea how big these subnets will be either.
---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540 Skype: barryvdean
Content-Description: ATT00001.txt
--- Nice boy, but about as sharp as a sack of wet mice. -- Foghorn Leghorn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yep, I was referring to the entries I see in my logs for "Interim-Update", which is of course an Accounting record, and I had always assumed this went with an Auth as well, but have never looked in detail to see! So I am most likely talking rubbish!
No, that's accounting, which is completely different to authentication. You don't normally return *anything* in accounting - just an "ok, message received" to stop the retransmit logic. The packet flow for a wireless client normally looks something like this: ap/controller: access-request radius server: access-challenge ...repeated a few times to complete EAP & EAP-inner ap/controller: access-request radius server: access-accept w/ VLANs This is the "authentication". You then get: ap/controller: accounting-request Acct-Status-Type=Start radius server: accounting-response # then every Acct-Interim-Interval ap/controller: accounting-request Acct-Status-Type=Interim-Update radius server: accounting-response # You might have 0, 1 or more repeats of the authentication phase here, depending on how your wireless re-auth settings are. This may or may not stop/re-start the accounting session # then when the client disconnects ap/controller: accounting-request Acct-Status-Type=Stop radius server: accounting-response
Could you share your configuration and perl script? So I can learn from it?
I am thinking of use ldap status to decide the pool, then hashing mac
address of the client to get different VLAN.
This is actually similar to how some vendor VLAN pool works, except we
are not trying to get same result as its hash algorithm. And we
already have the flexibility in radius long long time ago.
Schilling
On Fri, Feb 18, 2011 at 9:16 AM, Dean, Barry <B.Dean@liverpool.ac.uk> wrote:
> I have been asked to do just this and I am working on the solution now.
>
> We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
>
> One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
>
> In my tests I have been creating a hash from the 'State' attribute which seems reasonably random and gives me a good even share across the VLANs in my pools, but would be completely non-deterministic. (My tests are not real world so this could prove untrue).
>
> A hash on User-Name may be more deterministic, but may not give me the balance I need.
>
> Students and Staff have different format usernames so I am sure this would result in un-balanced sharing across the VLAN pools. And we have un-even numbers of students on different courses and their usernames start the same.
>
> I am using a perl module called within post-auth that does some LDAP lookups as well to find the type of the user.
>
> Nothing is set in stone yet and I am still experimenting, I feel sure whatever method I use will end up being a "I wouldn't start from here" solution in 12 months time!
>
> # Staff in our world means Staff + Research Postgrads and Students are Students + Taught Postgrads...
>
> On 17 Feb 2011, at 23:52, Kenneth Marshall wrote:
>
>> On Thu, Feb 17, 2011 at 02:26:14PM -0800, Brett Littrell wrote:
>>> I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is.
>>>
>>> First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea.
>>>
>>> The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone.
>>>
>>> Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group.
>>>
>>> Anyway, that is my 2 cents on the whole deal.
>>>
>>>
>>> Brett Littrell
>>> Network Manager
>>> MUSD
>>> CISSP, CCSP, CCVP, MCNE
>>
>> I agree with you that random VLAN selection is not a good idea and it
>> wrecks havoc with most clients too. However, the problem we ran into was
>> balancing the usage of all of the VLANS to get both good performance and
>> minimize infrastructure costs. This can be done by assigning to groups
>> and then placing in the VLAN according to that group, but then you have
>> the problem of balancing the assignment to the named groups. In the end,
>> we used the hash function because it would deterministically assign a
>> user to a VLAN and balanced the hardware usage reasonably well. We used
>> the simple crc32, but a better hash function would distribute them even
>> better if all were connected simultaneously, but a crc32 was easy and
>> the size of the groups was within 10%. Calculating the group members
>> is easy, but they already have that information from VLAN/IP address of
>> the machine. It is also easy to have the network gear return who is
>> attached and what VLAN they are in.
>>
>> My 1.5 cents. :)
>>
>> Ken
>>>
>>>>>> On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
>>>
>>> schilling <schilling2006@gmail.com> wrote:
>>>>
>>>> I get dynamic VLAN assignment working in post-auth section with
>>>> help/hints from a lot of list members. Now I want to do one more
>>>> steps. I would like to hash the username or mac-address to distribute
>>>> users to different VLANs. The idea is to use freeradius to spread the
>>>> load on different smaller subnets to reduce the broadcast in bigger
>>>> VLANs.
>>>>
>>> You are however not reducing the broadcast domain, you might be
>>> segregating the noise though. If you have large L2 broadcast domains,
>>> splitting people up into different VLAN's is not going to in effect
>>> solve the problem.
>>>
>>> For background noise, you can actually reduce chatter by asking Windows
>>> clients to disable NetBEUI via DHCP and configure switches/wifi to not
>>> forward client<->client traffic where appropriate. For wireless networks
>>> you can also kill a lot of multicast traffic (5353/udp is a good example
>>> I would say).
>>>
>>> Another possible work around is that VLAN 'facstaff' at site A is not
>>> the same broadcast domain at site B.
>>>
>>> Better still, L3 is the way to go. We have and it solves a lot of
>>> problems, although there is upfront migration pains.
>>>
>>>> For example I want to do the following
>>>> if ( "%{User-Name}" !~ /@/ ) {
>>>> if ( %{User-Name}%2 == 0 ) {
>>>> update reply {
>>>> Service-Type = "Framed-User"
>>>> Tunnel-Type = "VLAN"
>>>> Tunnel-Medium-Type = "IEEE-802"
>>>> Tunnel-Private-Group-Id = "facstaff0"
>>>> }
>>>> elsif ( %{User-Name}%2 == 1 ) {
>>>> update reply {
>>>> Service-Type = "Framed-User"
>>>> Tunnel-Type = "VLAN"
>>>> Tunnel-Medium-Type = "IEEE-802"
>>>> Tunnel-Private-Group-Id = "facstaff1"
>>>> }
>>>> }
>>>> }
>>>>
>>>> Will I be able to do this in the post-auth with unlang?
>>>>
>>> You probably would get better millege calling on 'md5' xlat, I think
>>> the following sort of thing will work:
>>> ----
>>> authorise {
>>> update reply {
>>> Service-Type := Framed-User
>>> Tunnel-Type := VLAN
>>> Tunnel-Medium-Type := IEEE-802
>>> }
>>>
>>> # kludge to fake substr()
>>> if (%{md5:%{User-Name}} =~ /^(.)/) {
>>> if (%{1} =~ /^[0-7]/) {
>>> update reply {
>>> Tunnel-Private-Group-Id := "facstaff0"
>>> }
>>> } else {
>>> update reply {
>>> Tunnel-Private-Group-Id := "facstaff1"
>>> }
>>> }
>>> }
>>> }
>>> ----
>>>
>>> I would recommend L3-ising your network though if possible and as the
>>> rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise
>>> to a minimum.
>>>
>>> Cheers
>>>
>>> --
>>> Alexander Clouter
>>> .sigmonster says: RAM wasn't built in a day.
>>>
>>> -
>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>>
>>> -
>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
> ----------------------
> Barry Dean
> Principal Programmer/Analyst
> Networks Group
> Computing Services Department
> Tel: 0151 795 9540
> Skype: barryvdean
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
On 18/02/11 14:29, schilling wrote:
Could you share your configuration and perl script? So I can learn from it? I am thinking of use ldap status to decide the pool, then hashing mac address of the client to get different VLAN.
It seems like a lot of people are suddenly wanting to do this. Can any of you explain why, and why now? Just curious. It seems odd that so many people want to do it, all at the same time. Did an article appear online or in a magazine or something ;o)
Lol, probably. If these are large 802.11x nets, typically deployments of that scale use dumb WAPs and smart controllers that handle the load sharing. If they're wired nets, doesn't make any sense to me. ----- Original Message ----- From: Phil Mayers [mailto:p.mayers@imperial.ac.uk] Sent: Friday, February 18, 2011 08:36 AM To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: Re: Hash username or mac address to assign user to different vlan On 18/02/11 14:29, schilling wrote:
Could you share your configuration and perl script? So I can learn from it? I am thinking of use ldap status to decide the pool, then hashing mac address of the client to get different VLAN.
It seems like a lot of people are suddenly wanting to do this. Can any of you explain why, and why now? Just curious. It seems odd that so many people want to do it, all at the same time. Did an article appear online or in a magazine or something ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
I can explain my environment. We are migrating from traditional captive portal to new 802.1x WPA2-Enterprise, from fat AP to controller based wireless architecture, Wireless mobility comes into play too. At the same time, how to maintain the traditional source-based IP ACL/Firewall? We already implemented MPLS VPN based network virtualization, so we want to utilize both MPLS VPN and newer wireless architecture. That's why. Another thing is big VLAN broadcast scalability. So we want to chop off users in different VLANs at first by hash, later will try to implement group based VLAN assignment. Also, we agree with the consensus of use eap/peapv0 for 802.1x. Just no hassle to install third party supplicant to M$ computers. And it could work with either AD or LDAP with ntPassword hash. Schilling On Fri, Feb 18, 2011 at 9:36 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 18/02/11 14:29, schilling wrote:
Could you share your configuration and perl script? So I can learn from it? I am thinking of use ldap status to decide the pool, then hashing mac address of the client to get different VLAN.
It seems like a lot of people are suddenly wanting to do this.
Can any of you explain why, and why now? Just curious. It seems odd that so many people want to do it, all at the same time.
Did an article appear online or in a magazine or something ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 18/02/11 14:52, schilling wrote:
I can explain my environment.
This is getting OT for the list, and will be my last post.
We are migrating from traditional captive portal to new 802.1x WPA2-Enterprise, from fat AP to controller based wireless architecture, Wireless mobility comes into play too. At the same time, how to maintain the traditional source-based IP ACL/Firewall? We already implemented MPLS VPN based network virtualization, so we want to utilize both MPLS VPN and newer wireless architecture. That's why.
I'm not suggesting that you shouldn't do *any* VLAN assignment. We do VLAN assignment on wireless, and in fact each VLAN is inside an MPLS VPN, so we're doing something similar to you. I'm only suggesting that hashing or any other "load balancing" scheme to keep ~N clients in each of X VLANs might be either unnecessary or possibly even harmful.
Another thing is big VLAN broadcast scalability. So we want to chop off users in different VLANs at first by hash, later will try to implement group based VLAN assignment.
But why? Many (most?) controller-based wireless systems don't suffer from broadcast scalability problems. For example, our Cisco WiSMs simply don't forward broadcasts. They proxy ARP requests and handle the DHCP internally, so there's no need for clients to send broadcasts. I would talk to your vendor to see if they have a similar solution.
On Fri, Feb 18, 2011 at 03:00:48PM +0000, Phil Mayers wrote:
On 18/02/11 14:52, schilling wrote:
I can explain my environment.
This is getting OT for the list, and will be my last post.
We are migrating from traditional captive portal to new 802.1x WPA2-Enterprise, from fat AP to controller based wireless architecture, Wireless mobility comes into play too. At the same time, how to maintain the traditional source-based IP ACL/Firewall? We already implemented MPLS VPN based network virtualization, so we want to utilize both MPLS VPN and newer wireless architecture. That's why.
I'm not suggesting that you shouldn't do *any* VLAN assignment. We do VLAN assignment on wireless, and in fact each VLAN is inside an MPLS VPN, so we're doing something similar to you.
I'm only suggesting that hashing or any other "load balancing" scheme to keep ~N clients in each of X VLANs might be either unnecessary or possibly even harmful.
Of course balancing does not matter if each of your VLANs can support your entire complement of users. We are not that lucky and need to spread the assignments out. Cheers, Ken
Another thing is big VLAN broadcast scalability. So we want to chop off users in different VLANs at first by hash, later will try to implement group based VLAN assignment.
But why? Many (most?) controller-based wireless systems don't suffer from broadcast scalability problems. For example, our Cisco WiSMs simply don't forward broadcasts. They proxy ARP requests and handle the DHCP internally, so there's no need for clients to send broadcasts.
On Fri, Feb 18, 2011 at 02:36:55PM +0000, Phil Mayers wrote:
On 18/02/11 14:29, schilling wrote:
Could you share your configuration and perl script? So I can learn from it? I am thinking of use ldap status to decide the pool, then hashing mac address of the client to get different VLAN.
It seems like a lot of people are suddenly wanting to do this.
Can any of you explain why, and why now? Just curious. It seems odd that so many people want to do it, all at the same time.
Did an article appear online or in a magazine or something ;o)
If you need to spread a userbase across network hardware efficiently, you need to do something like this. With the increased importance of security on a network, this sort of process is needed and simply reflects a growing attention to security overall and the prevelance of 802.1x. Cheers, Ken
On Fri, Feb 18, 2011 at 02:16:25PM +0000, Dean, Barry wrote:
> I have been asked to do just this and I am working on the solution now.
>
> We wanted to use multiple pools of VLANs/Subnets and assign "Staff" to one pool and "Students"# to the other. Then to select a VLAN within the pool, use a hashing function and select a VLAN.
>
> One concern I have is when is post-auth called? Would it get called for interim authentication requests? Because I don't want to be changing the VLAN mid sessions, which could potentially happen with a non-deterministic hash!
>
> In my tests I have been creating a hash from the 'State' attribute which seems reasonably random and gives me a good even share across the VLANs in my pools, but would be completely non-deterministic. (My tests are not real world so this could prove untrue).
>
> A hash on User-Name may be more deterministic, but may not give me the balance I need.
>
> Students and Staff have different format usernames so I am sure this would result in un-balanced sharing across the VLAN pools. And we have un-even numbers of students on different courses and their usernames start the same.
>
> I am using a perl module called within post-auth that does some LDAP lookups as well to find the type of the user.
>
> Nothing is set in stone yet and I am still experimenting, I feel sure whatever method I use will end up being a "I wouldn't start from here" solution in 12 months time!
>
> # Staff in our world means Staff + Research Postgrads and Students are Students + Taught Postgrads...
You will always have fluctuations in the number of users per VLAN
with any method of assignment, unless you keep track of VLAN/user and
compensate. This will incur the I/O overhead of tracking this information
although using some type of memory store like memcached would make this
a lighter weight operation. In actual usage, there is very little need
to have such an accurate leveling of usage. The count of users per VLAN
does not reflect their actual load on the network. 10 users streaming
video would use more bandwidth than 100+ users reading their Email or
editing a document. You could also have every member of one group login
at the same time and fully populate one VLAN. This is more likely if you
group by role or class. The upshot is that you only need to be good-enough
and not perfect to get the benefit of leveling, and using a hash(User-Name)
is the simplest way to achieve that. In my code, we used a crc32 as the
hash function and it was fine. (We tested it against our population of
User-Names.) The md5 would be even better at randomizing, but it is a
much more CPU intensive function. Using a dynamic group assignment is
going to be more complicated, more bug ridden, and will not be any better
than the straight-forward hash(User-Name) method. I do think that the
amount of work for dynamic VLAN assignment adjustment is being discounted
by it advocates.
Cheers,
Ken
>
> On 17 Feb 2011, at 23:52, Kenneth Marshall wrote:
>
> > On Thu, Feb 17, 2011 at 02:26:14PM -0800, Brett Littrell wrote:
> >> I agree breaking the network up into separate VLANs then routing between them would help with broadcasting but I do not agree that hashing values and then using those hashing values as we randomizing agents to distribute vlans. There has to be a more elegant way to do this, I believe there is.
> >>
> >> First off by randomizing what network a host is going to be on is going to be extremely confusing when you try and troubleshoot other issues, for instance a virus outbreak, now you have to figure out who is on what subnet and who is sending what etc.. I can think of a lot of other issues that would cause headaches, suffice to say it is not a good idea.
> >>
> >> The better way to do this is to break people up by some logical means, such as Accounting, testing, personnel etc. Then create groups and assign group ids based on the users in those groups. This gives the benefit of segmenting and securing like minded traffic as well, maybe accounting can only talk to accounting, personnel can only talk to these servers, or those servers etc. Of course you would have to route to other subnets if you want them to talk but now you have control to say only this group of people can talk to that group of people and not just open it up for everyone.
> >>
> >> Even if you assign users by Group1, Group2, Group3 and you have a virus outbreak now you can at least look at it and say right away all Group1 subnet is crazy and have a list of all the stations/users in that group.
> >>
> >> Anyway, that is my 2 cents on the whole deal.
> >>
> >>
> >> Brett Littrell
> >> Network Manager
> >> MUSD
> >> CISSP, CCSP, CCVP, MCNE
> >
> > I agree with you that random VLAN selection is not a good idea and it
> > wrecks havoc with most clients too. However, the problem we ran into was
> > balancing the usage of all of the VLANS to get both good performance and
> > minimize infrastructure costs. This can be done by assigning to groups
> > and then placing in the VLAN according to that group, but then you have
> > the problem of balancing the assignment to the named groups. In the end,
> > we used the hash function because it would deterministically assign a
> > user to a VLAN and balanced the hardware usage reasonably well. We used
> > the simple crc32, but a better hash function would distribute them even
> > better if all were connected simultaneously, but a crc32 was easy and
> > the size of the groups was within 10%. Calculating the group members
> > is easy, but they already have that information from VLAN/IP address of
> > the machine. It is also easy to have the network gear return who is
> > attached and what VLAN they are in.
> >
> > My 1.5 cents. :)
> >
> > Ken
> >>
> >>>>> On Thursday, February 17, 2011 at 11:26 AM, in message <fc9038-7cg.ln1@chipmunk.wormnet.eu>, Alexander Clouter <alex@digriz.org.uk> wrote:
> >>
> >> schilling <schilling2006@gmail.com> wrote:
> >>>
> >>> I get dynamic VLAN assignment working in post-auth section with
> >>> help/hints from a lot of list members. Now I want to do one more
> >>> steps. I would like to hash the username or mac-address to distribute
> >>> users to different VLANs. The idea is to use freeradius to spread the
> >>> load on different smaller subnets to reduce the broadcast in bigger
> >>> VLANs.
> >>>
> >> You are however not reducing the broadcast domain, you might be
> >> segregating the noise though. If you have large L2 broadcast domains,
> >> splitting people up into different VLAN's is not going to in effect
> >> solve the problem.
> >>
> >> For background noise, you can actually reduce chatter by asking Windows
> >> clients to disable NetBEUI via DHCP and configure switches/wifi to not
> >> forward client<->client traffic where appropriate. For wireless networks
> >> you can also kill a lot of multicast traffic (5353/udp is a good example
> >> I would say).
> >>
> >> Another possible work around is that VLAN 'facstaff' at site A is not
> >> the same broadcast domain at site B.
> >>
> >> Better still, L3 is the way to go. We have and it solves a lot of
> >> problems, although there is upfront migration pains.
> >>
> >>> For example I want to do the following
> >>> if ( "%{User-Name}" !~ /@/ ) {
> >>> if ( %{User-Name}%2 == 0 ) {
> >>> update reply {
> >>> Service-Type = "Framed-User"
> >>> Tunnel-Type = "VLAN"
> >>> Tunnel-Medium-Type = "IEEE-802"
> >>> Tunnel-Private-Group-Id = "facstaff0"
> >>> }
> >>> elsif ( %{User-Name}%2 == 1 ) {
> >>> update reply {
> >>> Service-Type = "Framed-User"
> >>> Tunnel-Type = "VLAN"
> >>> Tunnel-Medium-Type = "IEEE-802"
> >>> Tunnel-Private-Group-Id = "facstaff1"
> >>> }
> >>> }
> >>> }
> >>>
> >>> Will I be able to do this in the post-auth with unlang?
> >>>
> >> You probably would get better millege calling on 'md5' xlat, I think
> >> the following sort of thing will work:
> >> ----
> >> authorise {
> >> update reply {
> >> Service-Type := Framed-User
> >> Tunnel-Type := VLAN
> >> Tunnel-Medium-Type := IEEE-802
> >> }
> >>
> >> # kludge to fake substr()
> >> if (%{md5:%{User-Name}} =~ /^(.)/) {
> >> if (%{1} =~ /^[0-7]/) {
> >> update reply {
> >> Tunnel-Private-Group-Id := "facstaff0"
> >> }
> >> } else {
> >> update reply {
> >> Tunnel-Private-Group-Id := "facstaff1"
> >> }
> >> }
> >> }
> >> }
> >> ----
> >>
> >> I would recommend L3-ising your network though if possible and as the
> >> rubberband-aid use DHCP/ACL's to keep broadcast/multicast traffic noise
> >> to a minimum.
> >>
> >> Cheers
> >>
> >> --
> >> Alexander Clouter
> >> .sigmonster says: RAM wasn't built in a day.
> >>
> >> -
> >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> >
> >> -
> >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> > -
> > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
> ----------------------
> Barry Dean
> Principal Programmer/Analyst
> Networks Group
> Computing Services Department
> Tel: 0151 795 9540
> Skype: barryvdean
>
Content-Description: ATT00001.txt
>
>
> ---
> Nice boy, but about as sharp as a sack of wet mice.
> -- Foghorn Leghorn
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Feb 17, 2011 at 02:06:18PM -0500, schilling wrote:
Hi All,
I get dynamic VLAN assignment working in post-auth section with help/hints from a lot of list members. Now I want to do one more steps. I would like to hash the username or mac-address to distribute users to different VLANs. The idea is to use freeradius to spread the load on different smaller subnets to reduce the broadcast in bigger VLANs.
For example I want to do the following if ( "%{User-Name}" !~ /@/ ) { if ( %{User-Name}%2 == 0 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff0" } elsif ( %{User-Name}%2 == 1 ) { update reply { Service-Type = "Framed-User" Tunnel-Type = "VLAN" Tunnel-Medium-Type = "IEEE-802" Tunnel-Private-Group-Id = "facstaff1" } } }
Will I be able to do this in the post-auth with unlang?
Thanks,
Schilling
I did not see how that could be done with just unlang and we implemented it with a perl function that calculated a 32-bit checksum of the User-Name and used that with the modulo function to assign to the appropriate VLAN. Here is the authorize function that we are using: # Function to handle authorize sub authorize { # For debugging purposes only # &log_request_attributes; # Here's where your authorization code comes # You can call another function from here: # &test_call; # # Calculate the 32-bit checksum of the User-Name to use for # assigning the VLAN number. $chksum_username = unpack("%32C*", $RAD_REQUEST{'User-Name'}); if ($RAD_REPLY{'Connect-Info'} =~ /visitor/i) { $RAD_REPLY{'Tunnel-Private-Group-Id'} = "visitor0" . ($chksum_username % 8 + 1); } elsif ($RAD_REPLY{'Connect-Info'} =~ /staff/i) { $RAD_REPLY{'Tunnel-Private-Group-Id'} = "staff0" . ($chksum_username % 8 + 1); } elsif ($RAD_REPLY{'Connect-Info'} =~ /student/i) { $RAD_REPLY{'Tunnel-Private-Group-Id'} = "student0" . ($chksum_username % 8 + 1); } return RLM_MODULE_UPDATED; } Regards, Ken
participants (8)
-
Alexander Clouter -
Brett Littrell -
Dean, Barry -
Gary Gatten -
John Douglass -
Kenneth Marshall -
Phil Mayers -
schilling