Need some tips in reorganizing our LAN.

[lars]

Benjamin Lutz <benlutz at datacomm.ch> wrote:
> Hello jay,
> 
> On Wednesday 29 March 2006 05:55, Mark Jayson Alvarez wrote:
> > 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.
> 
> If you don't have it already, I'd start cleaning up the old system without 
> changing it's structure. Remove the redudancies, eg unnecessary cascading 
> switches, or computers that are no longer used. This will give you a clear 
> idea of what the current layout looks like, making it easier to plan changes, 
> and with some luck it'll also give you a hardware stockpile that you can then 
> recycle for your new LAN.
> 
> >  I have these in my mind right now:
> >
> >  Connectivity
> >  1. wired
> >  2. wireless
> 
> I see no place for a wireless network in a professional network. It's hard to 
> secure it (it's possible, encrypted-VPN-over-WLAN works, but it's difficult 
> and expensive to set up). Stick with a wired LAN, and there'll be one 
> security threat less that you have to worry about.
> 
> >  Machines being hooked into the network:
> >  1. servers
> >  2. workstations
> 
> Make a list of the servers you have, and which user groups need them. Make a 
> list of which logical user groups there are. Then design a network layout to 
> match those needs. You could, for example, put each use group into its own 
> subnet, including the servers it needs. Access between user groups could then 
> be restricted at will*.
> 
> Alternatively, put some or all servers into a dedicated subnet. This will also 
> allow protecting them better.
> 
> I realize I'm being very unspecific, but you didn't give us all that much 
> information.
> 
> >  3. testbeds
> 
> If there are users accessing those, treat them as servers. Otherwise, isolate 
> them from the production network.
> 
> >  4. personal (laptops etc.)
> 
> This is a difficult one. Personal laptops are machines you have no direct 
> control over (you cannot control what software is installed on it), and as 
> such they are a high risk factor when they are connected to your network. 
> They might introduce malware into the company, or evade your file storage 
> procedures.
> 
> This is a matter of policy basically. Try to restrict personal machines as 
> much as you can. Forbid connecting them to the LAN. If you can't do that, 
> maybe have specialized laptop ports that are firewalled off from the rest of 
> the network.
> 
> >  Will use DHCP
> 
> Keep in mind that a DHCP server needs to be in the same subnet it serves. 
> Other services do not have this requirement.
> 
> >  Will use centralized directory service
> >  Will use centralized authentication
> 
> Sounds good. Personal laptops will undermine this though, another reason to 
> try to keep them away.
> 
> >  We have at most 150 employees...
> >  We don't have that much to spend on equipments like managed switches,
> > powerful servers, etc. We have a lot of political issues that needs to be
> > resolved regarding network usage policies
> 
> You don't need powerful hardware to manage a network with just 150 employees. 
> Some gigabit hardware for popular servers would be nice, but the network 
> management will use very little CPU resources (unless of course you decide to 
> play around with VPNs). So don't worry about that too much.
> 
> >  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. :-)
> 
> It sounds like you're planning to have all subnets connected through this one 
> FreeBSD box. This is not necessary. You can put a router in between subnets, 
> and have that one located elsewhere, where it's more convenient. It can also 
> make perfect sense to have firewalls on these routers. If you isolate user 
> groups that need to communicate with each other into different subnets and 
> block traffic between them, it'll be easier to contain a worm outbreak.
> 
> And oh yeah: in my opinion, the firewall, ie the outermost machine that's 
> connected to the internet, should have 2 or 3 interfaces only, and carry data 
> only on 2 of them. Do not give it several interfaces for the purpose of 
> routing your LAN. It'll make creating an airtight firewall ruleset much more 
> difficult. Instead, have one or several routers inside your LAN that handle 
> it, that don't need to deal with malicious outside traffic too.
> 
> > Please help me.
> 
> Feel free to be more specific about your plan or with your questions, I'm sure 
> people here will happily comment on or answer them.
> 
> I'm also sensing that you feel a bit overwhelmed. Try to keep pressure on 
> yourself low, by having as few disruptive changes as necessary. Don't try to 
> change your whole network over a weekend, it's too large for that. Install 
> the new parts bit by bit, and try to do so with the rest of the old system 
> still working, until you change it. In other words: take it slow, and plan 
> your steps well.
> 
> And here's another thought: reliability and redundancy. Computers fail. If you 
> have one central router that everything goes through, not only is it a 
> performance choke point, but it'll also bring the whole agency to a 
> standstill if it should fail. Maybe there isn't a better way to do things 
> given your resources, but if there is, try to limit the impact of potential 
> failures. Distribute things like routing, and most of the network will keep 
> working if one machine fails. Or, if you can, make things redundant.
> 
> Cheers
> Benjamin

I agree with Ben's assessment.

Don't change all at once.

Divide and conquer.

Step by step you'll change the whole spaghetti pile.

Draw the LAN.

Simplify the setup by reducing the number of cables, devices, machines
and connections. Less devices - less problems. 

Prioritize the problems you discovered.
Begin with the problem that has a high impact and high probability
when/of happening. The FreeBSD box maybe?

If you can get away with it, make unnoticable changes without asking.
Saves you losing your mind in discussions and politics.

You'll be fine.

Cheers
Lars