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....@chipmunk.wormnet.eu>, Alexander Clouter >>>>> <a...@digriz.org.uk> wrote: >> >> schilling <schilling2...@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
<<attachment: h1_a.png>>
--- 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