Jay,
<snip>
This interface is connected to 1 switch and then 5 or more switches are
connected to this main switch. Those 5 or more switches are then scattered
to every area of the building. I know you are thinking a lot of negative
things about this setup, but this is what it really looks right now.
You didn't define how large your client base (number of machines) was (or at
least give us a guesstimate).
The MIS suggested a LAN transition project, and I was assigned to lead the
team. Right now, we are only two in this very big team. :-) I'm just
wondering if I will ever gonna finish this project or not. I have a lot of
stuffs mixed up in my mind right now but I really don't know where to
start.
Just sitting down with a piece of paper and working through the issues in a
command and conquer fashion gets the job done. That's the stuff that
engineers are made of :).
I have these in my mind right now:
Connectivity
1. wired
2. wireless
Only do wireless if you intend to have a semi-smart setup with a set of
wireless routers that restrict the clients connecting who are not known to
force them to login. You can ensure that the clients are known (registered)
by recording their Mac addresses and records; that's how the dept I work for
does things, and it works pretty well. Otherwise, there's always an SSL
login via wireless each time that ties into a domain/kerberos login.
Machines being hooked into the network:
1. servers
2. workstations
3. testbeds
4. personal (laptops etc.)
As said before, just isolate the testbed machines from the servers and
workstations because it will pose less of a security risk, and just in case
something goes awry with a testbed machine, the odds of the problems
cascading over into the other subnets will be reduced.
Will use DHCP
Will use centralized directory service
Will use centralized authentication
We have at most 150 employees...
We don't have that much to spend on equipments like managed switches,
powerful servers, etc.
Don't need something powerful unless you want something 'simple' or
dedicated to use; with proper setups and Unix machines (one of FreeBSD's
definite forte's), you will probably be able to take a upper level P3 and/or
a lower level P4 and service an entire subnet with little latency issues. I
don't suggest running more than sshd, ipfw (or an equivalent firewall),
sendmail, and a syslog daemon, just to keep things light and traffic moving
quickly.
We have a lot of political issues that needs to be resolved regarding
network usage policies
Again, registration and port blocking can solve this by restricting the
ports and 'punishing' the rule breakers. Be aware that no solution's perfect
and someone will always come up with something to beat your clever
'mousetrap'.
All these stuffs, basically mixed up in my mind. I really have no idea
where to start aside from creating a purchase request for a new PC router
and a multiple port lan card, which I already did a week ago..And it has
not arrived yet. :-)
If you've already done this, make sure to make this your central machine;
that way the machine sifting through all of the traffic and redirecting
requests can be the best equipped to meet the issue at hand.
Please help me. I told my partner that services configuration is just a
piece of cake once we already have a definite plan.
Shouldn't have said that... building up client expectation isn't a wise
thing necessarily if one can't deliver due to unexpected issues or turns.
I really don't know where to start. I'm not even tasked to do this... I'm
just tasked to help my partner who is a member of the poor MIS. At first, I
thought this would be just as easy as upgrading the machine to FreeBSD 6.0
and then reconfiguring the firewall ruleset, but I was wrong.
Stuff isn't always as easy as it seems. That's what I've learned through my
little experience in the real world.
If you have any Network Transition plan that you may want to share to me,
please do so. Even if we don't have that much similarities in our network
setup, at least the non technical part like planning etc...
Uhm... don't mean to be rude, but aren't you getting paid to think of ideas
and not me ;)?
Just thought you might want to mull over those points I just mentioned a
bit. Basically follow the advice given already, which essentially is:
1. Calm down
2. Think stuff over
a. Write down what needs to be accomplished and the requirements that
need to be met.
b. Eliminate unnecessary components.
c. Draw up a new plan.
3. Execute your new plan
HTH,
-Garrett
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
