Saturday, July 14, 2012

Designing subnets for Company X

The following is a semi-logical guide I use to design my subnet and supernets for organizations.  This guide is by no means a guide you should use word for word on your implementation as different requirements may make this guide a sub-optimal solution.  Make sure you contact any VARs or Service Providers to validate your design prior to implementing.

Step 1: Shut down your computer and talk to people
You need to learn the organizations geographical footprint, 5 -10 year growth strategy, organizational structure, security and regulatory requirements, etc...  The biggest mistake you can make is to start allocating subnets prior to having all this information as it will cause you to go back and re-design as you learn new information.

Step 2: Logical Design
Figure out if the best way to break up your subnets and supernets are geographical, by building, department, security zone, etc...  This is where all the information gathering in Step 1 comes in handy.  For example, a business with hundreds of stores spread out over multiple states will probably be broken up geographically first and then by individual stores, a company in a campus design may be broken up by building and floor, and a single data center may be broken up by customer, security zone or application.

Step 3: Plan for the future
If the company says they plan to open 10 locations in the next 10 years, plan for at least double that in your initial design, more if you can based on your final design.  Private IP space is free, no need to be stingy.


Step 4: Supersized Supernet
Pick a private supernet large enough to blanket the entire company today, tomorrow and 10 years from now.  As I said in Step 3, the IPs are free, so why not go as large as possible?  Unless a really convincing, driving reason not to, I will always use 10.0.0.0/8 as my company supernet.  This gives me 16 million IPs to work with and almost unlimited flexibility when it comes to subnetting it out.


Step 5: Supernet and Subnet
Now that you have your starting point in Step 4, it's time to start the actual subnetting.  Always design on the principal of being able to take subnets and summarize them into larger subnets (supernets) as much as possible.  For example:


Site A MDF: 10.30.0.0/20
Site A IDF 1: 10.30.0.0/21
Site A IDF 1 Closet 1: 10.30.0.0/22
Site A IDF 1 Closet 2: 10.30.4.0/22
Site A IDF 2: 10.30.8.0/21
Site A IDF 2 Closet 1: 10.30.8.0/22
Site A IDF 2 Closet 2: 10.30.12.0/22

In the above example each closet IDF had a /22 assigned to it and was able to break out individual subnets from that supernet.  Since all the subnets in that closet lived within the same supernet, it could summarize a single /22 route up to IDF 1 rather than dozens of smaller more specific subnets.  Also since both closets for each IDF were within that IDFs /21 it could send up a single summarized route to the MDF rather than two /22 or multiple smaller routes.  There is no need for the MDF to know about individual subnets living in IDF 1 Closet 2.  That this point if Site A was connected to a WAN or other aggregation network for mupltiple sites, it could easily pass a single /20 subnet representing everything within Site A out to the world.  This reduces the size of routing updates and makes your routing tables much smaller and more manageable.






Real world example:


Company A - Global Distributors, Inc. 25 world wide locations on 3 continents and 7 countries with medium growth of 1 site every year averaging 200 employees per site

I would use a geographical design here in how I subnet:

10.0.0.0/8: starting point
 - 10.0.0.0/10: Americas
  - 10.0.0.0/11: North America
   - 10.0.0.0/16: Head Quarters (and data center)
   - 10.1.0.0/20: NYC
   - 10.1.16.0/20: Los Angeles
  - 10.32.0.0/11: South America
   - 10.32.0.0/16: Rio
 - 10.64.0.0/10: Asia
  - 10.64.0.0/12: China
  - 10.80.0.0/12: Korea
 - 10.128.0.0/10: Europe
 - 10.192.0.0/10: Everywhere Else

I did fill in all the sites in the above example but you can get the idea.  I first break everything out by major geographical region, then by country, and then by site.  This makes routing simple when you want to route by geographical region or by a country for regulatory reasons.  For example, when connecting into China via a private WAN which bypasses their national content filtering you are not supposed to use that private WAN for Internet connectivity out of the country.  By having China defined as a /12 I can easily now set up PBR on my routers to say anything coming from 10.64.0.0/12 needs to use this specific Internet gateway which is local to China.  Also additional sites that come online in China which are put inside the China supernet automatically have their Internet traffic routed out the correct way and there is no need to go back in and add the new site to the rules.