Configure VLANs on Flat Class B network

I have an issue... I just moved into managing a network which is configured haphazardly. The network is a Class B ( /16) set up with one VLAN (VLAN1) being used across about 12 switches - including a 6-switch stack. My questions are these... given the attached configuration, what would I need to do/change in order to make this into a routed and multi-VLANed Class C type network? The Gateway currently is set to be the firewall... I don't think this is a proper way to have it set up and would like to remove the firewall from being the gateway because when or if it drops, the whole network is affected. It seems that when the network here was configured, it was done very basically with Cisco-defined templates for voice and data. Currently, even though the attached config  shows multiple VLANs configured, it seems that everything is actually working on VLAN1. I need to make this is into a more managed system where I can create seperate VLANS for each switch, do the routing through here, and stop this from being a flat, one dimensional network which iseems to be pushing voice and data across one vlan. Can anyone help? Thanks in advance!
Who is Participating?
lrmooreConnect With a Mentor Commented:
Some good advice above, but I'd like to throw out a few cautions/ideas.
1. What problem are you trying to solve? The simple fact that there are not multiple vlans in play? You do have 2 vlans now. Data - VLAN 1 and Voice - VLAN 800. How many devices are on the data network? How many devices have static IP addresses that need human touch to re-IP? How would that affect things like printers/print queues?

2. VLAN's are broadcast boundaries. Some applications, both client and server, have dependencies on broadcast packets. Windows NetBIOS, name resolution is highly dependent on broadcasts. You need to understand exactly what ramifications there will be if you put a server in one vlan and a client in another. For example, if this was a hospital and there were medical devices on every floor that needs to be in the same broadcast domain as a particular server, then you must have that VLAN span the entire network. This rules out a Layer 3 routed network design.

3. Multicast use can also affect how you segregate the network. Do you use Multicast for Music on Hold on the voice network? Do you use a multicast paging system? Be very careful about segregating these over Layer 3 routed links.

4. Moving the core routing to the core switch stack is a good idea and can be the logical first step. I like to use a transit vlan/subnet between the core router and the firewall. This protects the firewall interface from having to deal wit h all the local broadcast packets. The simple thing to do would be to create this transit vlan and change the ip address of the firewall, then make the core switch vlan IP which is probably the firewall now, and point the switch's default to the new IP of the firewall.  Example:

Firewall new IP = /24
Firewall add route:

On the core switch
ip routing
interface vlan 3
 ip address
interface vlan 1
 ip address  <-- everything is still pointing to this default IP address, so no changes on device
ip route

interface gig 1/0/24
 descript firewall interface
 switch access vlan 3


5. You probably have VTP running now. You need to know the VTP domain, VTP password, and which switch is the VTP server and are the access switches transparent mode or client mode. I recommend the core stack be the VTP server and access switches be VTP client. This way as soon as you define a new VLAN on the core stack, it is automagically propogated to all other switches. I also recommend setting a VTP password. It looks something like this:
Core stack:
  vtp domain DOMAIN
  vtp password VTPPASSWORD
  vtp mode server

Access switch
 vtp domain DOMAIN
 vtp password VTPPASSWORD
 vtp mode client


6. Now, create a new vlan on the core switch, make sure you have IP addressing services like DHCP scope and create a new L3 interface on the core switch:

 vlan 4
 name NEW_VLAN
interface vlan 4
 ip address
 ip helper-address 10.1.xx.xx  <== ip address of DHCP server with scope setup for network

Now go to an access switch and verify that you see vlan 4 and assign ports to that vlan:

sho vlan (do you see vlan4 NEW_VLAN?)
 interface fast 0/2
 switch access vlan 4  <== given your existing config, this is all you have to do!
 no shut  <== this will bounce the port and the phone will reboot so it gets the vlan assignments for its ports

Simply follow this pattern to create your new vlans and assign the appropriate access ports to the vlans and you're golden.
You don't say if you have any spare L3 capable switches laying around or if (hopefully) the firewall has more than one inside interface.  It's pretty great that you have 3750 client access switches as you can go fully routed and get rid of spanning tree woes.  Also, you don't mention any kind of high availability requirements or dynamic routing with OSPF/EIGRP etc...  But I would say setting up a new network core would be the logical first step.  Here's a migration strategy that would be effective and allow for moves "as time permits"  This setup would allow for a HA setup in the future as budget allows, though with 3750s you may already have the budget....

1. Think up a new IP addressing scheme for client access vlans.  Maybe use a /24 for each in the 192.168.x.x space.  Don't forget your voice vlans, so minimum of 2 vlans per client access switch, not including management vlan.  Also think about the IP addressing between the core and client access switches and between the core and firewall.  Here it makes sense to use a /30 for each connection.  Maybe set aside the 192.168.0.x for all your /30s

2. Find out where the spanning tree root bridge is.  Try to keep an L2  star topology through the transition with the switch-to-switch interconnections.

3. Setup network core with the route pointing at the firewall inside.  Add static routes for the all the new client data and voice vlans.

4. Set up a routed port on an existing client access switch and hook it to a corresponding routed port the new core.  Set the default route on the client access switch pointing to the new core switch IP.

5. As you can, transition the client ports to the new vlans.  Probably best to work one switch at a time starting from a less crucial one or a test one if you can.

A fully redundant design approach is here:
eporteniAuthor Commented:
Thanks for the info - it does help me get thoughts in order. I also was trying to get some perspective on the current setup I have and whether or not it is feasible or possible to do "in place" changes to the network via config changes on the access switches and core stack. Given the next two configs  (Access switches in place currently), I guess I would be looking for help building a basic configuration (or guidelines toward one) that will put routing on the core, and change the access switches currently in place to be on their own VLANS (with voice and data). Does this make sense? I have a fairly good understanding of data switching, but I haven't worked with VoIP much and could use the guidance on an effecient and practical setup.
Thanks again!
access-switch-1.txt access-switch-2.txt
Never miss a deadline with

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

eporteniAuthor Commented:
This is excellent help - thanks very much! So if I wanted to essentially also shut down VLAN 1 and move the access switches into their own VLANs, would I then, on the access switches, do something like what is attached as a config? In the attached config, would the default GW still be or would it be Is my thought process on this config similar to what you are proposing, or am I headed in the wrong direction with it? Should I just scrap it and go with the config additions that you have proposed? ;) The end user devices are Cisco phones (7975) with PCs hooled through them... given that info. do the proposed changes make sense? Would I also have to set up static routes on the core for each VLAN created or is this not necessary?

Sorry if these all seem like basic and silly questions... I appreciate the help and just want to make sure that my thoughts are correct before trying anything.

The IP address of vlan1 on the access switches is purely to manage the switch itself. There is no real requirement that you change it's IP address to vlan4.  You might consider creating a network management vlan and using that vlan IP addresses on the switches and disable vlan1

Vlan 23
 name NET_MGMT
interface vlan 23
 ip address

ACCESS (best to do this via CONSOLE):
interface vlan 23
 ip address 10.4.23.XX
 no shut
interface vlan 1
 no ip address
ip default-gateway

No, you do not have to add any route commands on the core stack. All VLAN's are directly connected.
Yes, the proposed switch interface config looks good, but as above, you do not have to put the switch itself into vlan4 or create a vlan4 interface at all. Phones will still be in VLAN 800 and any PC connected to the phone will be in VLAN4.
eporteniAuthor Commented:
Thank you very much for your help! You are definitely an asset to the Experts-Exchange site!
All Courses

From novice to tech pro — start learning today.