Hash username or mac address to assign user to different vlan
Kenneth Marshall
ktm at rice.edu
Fri Feb 18 15:59:44 CET 2011
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 at chipmunk.wormnet.eu>, Alexander Clouter <alex at digriz.org.uk> wrote:
> >>
> >> schilling <schilling2006 at 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
More information about the Freeradius-Users
mailing list