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.

Polycom IP330 and 0x4020

I have been an avid Trixbox user for years now and recently decided to begin an implementation at my office.  Using the latest 2.4 release and my trusted Polycom IP330 desk phones, I decided to set up a small test setup to show the power and benefits of the system to senior management, in hopes they would upgrade our antiquated system.  Surprisingly, after configuring the system, running a "yum install polycom-firmware" and then a "setup-polycom" all my phones started displaying an "Config error 0x4020" during boot up and constantly rebooting.  I was using the tftp option to boot from.  They all upgraded to the latest bootrom and sip image but refused to load the config.

I found a posting at Trixbox called 0x4020.  I tried the config rperkins had posted using his ftp settings and to my surprise, my phones booted up without any issue.  Next, I downloaded all his files into my /tftpboot directory on my Trixbox server in order to test his configs in my environment.  Same problem as before, it would load everything but then get a 0x4020 error and reboot.  I finally decided to install an ftp server on my trixbox and point the root directory for ftp to /tftpboot.  Again, I rebooted my IP330s and changed the server config to ftp instead of tftp with the proper username / password combo and they were working again in my environment.

I decided to point the ftp root directory to /tftpboot so that I could continue to use the Endpoint Manager option in Trixbox without having to edit the code where it outputs the configs.

I hope that this helps anyone else who was having similar problems.