Large Flat Network to VLANs

[Ed Willson]

I've got a network that I've inherited, which is also the company HQ and internet headend. At the moment there are about 700 devices on the LAN. Wireshark plugged into any switchport will yield about 5-7Mbps of broadcast traffic. This is also the first network I've worked on (outside of a few computers) and I'm really the only one who can work on the Cisco gear, or anything layer 2-4. I'm sure that this is a story that's been told many times

The previous admin left a good IP scheme. It's being used at all 14 branches now. Here's the example:

10.Branch.Type.ID/16

10.10.0.0/16 = HQ, ex. 10.10.40.1 = HQ Switch (40) position 1 (1)

10.5.0.0/16 = Vancouver, ex. 10.5.60.45 = Vancouver Machine (60) Bay 4 machine 5 (45)

10.40.0.0/16 = Boise, ex. 10.40.190.1 = Boise Timeclock (190) position 1 (1)

ETC...

We've got a category for every type of device.

What I'm comtemplating is taking the 10.10.0.0/24 network at the HQ and making it the 10.1.0.0/24 network. This would let me maintain the IP scheme so an IP could ID a device. This also gives me 256 VLANS to deal with, although we have only about 20 device types. There aren't more than 256 of any type by a long shot...

This facility spans many acers with types of devices spread pretty evenly. All of the servers and external resources are centrally located.

If you were to subnet this network would you divide it by geography, device, etc...? Also - I'd like to roll out the same IP scheme at all branches to allow for growth as well.

Any thoughts or links appriciated.

Thanks,

      Ed

[m.glosson]

Sounds like a fine approach. One thing that I have done in this situation is to leave the original subnet in tact as a "legacy server" subnet so you don't have to re-IP all the servers as well. Then create a new server subnet or subnets for future devices.

I would divide it by geography and use as many layer 3 interfaces as it seems right to do. Cisco design guidelines are helpful here. I often designate the top range of a third-octet for /30 point-to-point addresses (e.g., 10.1.255.0/30, 10.1.255.4/30, etc) so as to link layer-3 devices in the various buildings together. You can make a loop like this as well and utilize OSPF or EIGRP for routing and fault-tolerance.

Finally, I would say that having a flat network lets you get away with some sins you can't get away with in a routed network. This was more true in the bad old days of NetBIOS, etc, but make sure that DNS servers are pointed correctly, every device has a default gateway, etc.

Good luck.

[Ed Willson]

Thanks for the vote of confidence. All of the access switches at various parts of the branch are L3 capable, statically. So the infrastructure is sound, and ready to be built on. At least I was left with decent infrastructure.

So you would divide it based on geography rather than purpose? This is the biggest question I have - So why would you do so?

Thanks,

     Ed

[m.glosson · Accepted solution]

Hello. Cisco generally recommends doing it geographically if possible, and if you think about the way the network works, it makes sense. If you do it based purely on function, you basically have to run all your locations back to a central set of layer-3 switches. Those links will all have plenty of broadcast traffic on them, which makes more effort for the core switches as well. Layer-3 has generally been less dangerous in terms of messing up your network as well. If some device goes crazy on the network or a loop forms, it can wreak havoc on the CPU of switches connected at layer-2. Of course spanning-tree can do its job, but having layer-3 boundaries is more safe imo, as well as routing protocols can allow multiple equal-cost paths whereas doing that at layer-2 is a bit trickier, although it can be done with MSTP.

I don't know the "shape" of your campus. If all the buildings have fiber connected directly back to the data center, you can use EIGRP stub on the distribution switches at each building. If you have "strings" of switches leading out from the core, EIGRP stub would not be good enough and you would have to use full-blown EIGRP so the switch can relay networks it has learned from other upstream switches.

Give this a read and trust it more than you would trust me though. The whole document is good of course, but you can start out by zeroing in on where the link takes you.

Good luck,

Matt

[Ed Willson]

Thanks Matt.  I was already coming to the conclusion that you suggested, but was hoping it could be otherwise. Looks like we'll have to give up the sweet sweet IP scheme for a more functional one. Bummer.

I can see a few things that are bright sides though. I'll be able to buy true L3 switches at the access points, and I bet I can get some more fiber run for redundancy. I just hate moving away from the 10.branch.0.0 model.

Thanks,

    Ed