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
