VLan Help

HP 5308xl
October 4, 2006 at 05:52:43
Specs: HP, ??
Hello... I am a network administrator trained in Windows Server administration... My knowledge of advanced networking techniques is limited... So my company has recently been reaching the limits of their choosen subnet (192.168.200.x/24)... So I am working on moving them to a class A ( We have 3 buildings each conntected via a fiber backbone... Each with their own switch stack... My plan was/is to have each building on their own subnet...

My question is this... What configutation will need to be done to make sure that each vlan can communicate with the servers (all located in one building, could be setup on their own vlan) and the internet (in the same room as the servers, again could be on it's own vlan or even same as servers)...

Hopefully someone can help me with this I just need some basic direction... No step-by-step is needed...

Thanks to all in advance...

Joe S.

See More: VLan Help

Report •

October 4, 2006 at 08:10:20
This is kind of tough to answer without knowing more about your infrastructure but I will try to give you a basic outline.

I highly recommend you spend some serious time researching/reading about VLAN's.

One of the most important features of VLAN's are the ability to have a WAN and have subnets that span your WAN, but appear (act) like they're all a local subnet even when crossing remote boundaries. Depending on your infrastructure, you might find it necessary (or beneficial) to have a subnet (or subnets) that span all 3 locations. Say for example, you have programmers in all 3 locations. Say they work on projects together. If you created a VLAN and all of them were on it it would span all 3 sites yet behave as if they were all sitting physically in the same room connected to the same switch.

I bring this up because your idea of having each site as it's own VLAN (subnet) may not be the best way to do it and VLAN tagging will allow you a lot of flexibility in the long (and short) run.

Having said all that and assuming you're going to go ahead with the "3 site - 3 subnets" idea, here's how I would start my design.

VLAN1 = management VLAN
VLAN2 = server VLAN
VLAN3 = site 1 VLAN
VLAN4 = site 2 VLAN
VLAN5 = site 3 VLAN
VLAN6 = printer VLAN

You would probably want a router that is VLAN capable to route traffic between VLAN's and ensure communication between them. This may not be necessary though depending on what type of switches you have.

Where I'm working, we're using teamed servers running UNIX that do all routing and firewalling. We use extensive firewall filtering to control access. Certain VLAN's are inaccessible to others and external (DMZ) VLAN's strictly prohibit internal access etc etc.

We also have dual core switches that act as our gateways for each VLAN and do a lot of the forwarding. The gateway addresses for all VLAN's are configured on the core switches (ie: xxx.xxx.xx.250) and all switches are connected to the core via a fibre backbone. Effectively, incoming traffic hits the core switches and since they're capable, they'll forward tagged traffic appropriately. With our present layered firewall/router design, no matter what, traffic ends up passing through a router/firewall before hitting the core switches and are filtered forwarded (or dropped) again from there to their desination. In almost all cases, the traffic passes through at least one more firewall after leaving the core switch. Sometimes several before it finally hits it's final destination. Each of our remote sites has it's own firewall/router setup to handle traffic coming from and going to that location.

Depending on the size of your company, number of remote locations and number of devices communicating on the network it can easily become very complex. This is why I highly recommend you understand VLAN's before you begin. If possible, a one or two day training course on them would prove very beneficial. Especially if you can find a "hands on" course where you actually get to design, setup and deploy multiple VLAN's. The most important thing in any case is to have a well thought out plan before you begin and to really understand what you're working with, what you're doing, where you want to end up when you're done, and also, to allow for future growth and/or changes.

I hope this helps give you an idea what you're dealing with. Again, I can't stress enough the need to know as much as possible about VLAN'ing before you begin. It will save you a lot of grief later on in time.

Report •

October 4, 2006 at 10:18:47
Thanks for the reply... I understand your point of research and plan... That's why I'm talking to the community.. I've been working on this for about a month or two now... I think I have a plan but I would like to iron the wrinkles out...

There is one thing though I think you mis-understood the layout of my infrastructure... Although I do have a WAN and remote offices... The VLAN deal is only concerning 1 of the locations (HQ)... They have 3 buildings right beside each other and we have run our own fiber between the buildings... Currently the buildings all run off the same subnet... It also works out that if I make one building it's own VLAN then I essentialy give each department it's own VLAN, that's just the way we're setup...

Also I think I pretty much understand how to configure the end-user nodes... My really issue is how to configure the ports the servers and firewall is plugged into.. Do I tag them with all of the "user" VLAN's or do I put them in their own VLAN and use a router?? If so I think my HP 5308xl switches are capable or doing this type of routing internally... Is that the best way to do it or should I put an actual router on the network...

Either way.. Thanks for your help so far... It is greatly apprieciated...

Joe S.

Report •

October 4, 2006 at 14:23:41
You could either use a router to talk between them or get a good l2/3 switch which can do switching or wirespeed routing , this is a better choice if you don't need wan serial interfaces , otherwise you will need a router or a combo of both. A l2/3 switch is a good choice to break out your vlans and do the routing .

Report •

Related Solutions

October 4, 2006 at 14:39:09
I'm not familiar with the equipment you're using but the documentation should tell you if you require any further hardware to perform VLAN tagging. I suspect you wouldn't actually require a router, but it's possible.

As to setup of the switches themselves. Leave youself one port for the management interface (say Port #1) and set that to "untag all". You will want your uplink port (or ports) set to "tag all" so they can carry all VLAN's. The uplink ports are of course the interfaces between switches. The rest of the ports can be tagged for the particular VLAN that will be running over it. So for example lets say your management VLAN is VLAN1 and the VLAN for this particular switch is VLAN 4.

Port 1 = VLAN 1 (untag all)
Port 2 - 47 = VLAN 4
Port 48 = Uplink port (tag all)

You might wonder why you need a management interface when you likely have a console (serial) port. Most of the managed switches I've worked with (ie: Cisco, 3com, Nortel) all require you to do any software/firmware upgrades through a management port because you need to use tftp to upload the upgrade to the switch. With one port defined for the management VLAN, you plug a laptop into it and do the upgrade through that interface. Also, once you've got the switches setup and ready for production, you can again use the management interface to tftp a copy of the configuration onto your laptop. Having backups of your configuration(s) is priceless in the case of a catastrophic hardware failure. If it happens, you whip out your spare, plug it in, upload the config and plug everything in and you're back up and running in minutes instead of an hour or two. We keep backups of all switch config's for this purpose. It can be a bit of a pain in the butt having to constantly update the backups whenever any changes are made but it's paid off for us a couple of times in the last year alone. Less than a month ago one of the switches carrying outward facing VLAN's (a DMZ) failed. This left no external communication to our website and a couple other necessary services. I had the broken switch swapped out and everything back up and running in less than 15 minutes. I wouldn't have been able to do that anywhere near as fast if I had had to program a switch from scratch.

Report •

Ask Question