I've encountered many weird and wonderful IP Addressing schemes during my consulting engagements. During my early years, I'm sure I've contributed some less than optimal ideas into the mix. I'm going to try to mend my ways and introduce some ideas that I think make things better.
Friday, September 14. 2007
IP Addressing Best Practices (plus VRF and VLAN ideas)
Since the advent of Network Address Translation, network designers/architects/engineers have three basic address ranges from which to choose. These address ranges are based upon what is known as RFC 1918 - Address Allocation for Private Internets. The three ranges are:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
These are, what some call non-routable addresses. To be more specific, routers routing public addresses, will typically drop (not route) packets having destination addresses from these ranges. Of course, private networks are free to route these addressess as they see fit.
The commentary below assumes a basic knowledge of ip addressing, subnet allocation, host addressing, and routing.
When starting with small networks, a network installer may simply choose some random /24 block from one of the three ranges, and start assigning addresses to all devices on the network to that block. When installing IP Phones, some similar rationale may be used to pick some onother block for the phones. Some rationales that I've see included:
- let's choose 10.20.10.x for workstations and 10.20.20.x for phones, it keeps them in a similar big block, and keeps the octents nice workable numbers
- let's choose 10.20.30.x for workstations and 192.168.30.x for phones, it keeps them separate and identifiable, but yet similar in one octet
- let's add 172.20.30.x as a network management block as it is something completely different and identifiable as being not normal traffic
I'm sure you can come up with many other mechanisms. But what happens when you want to get another office joined in? Then suddenly one has a bunch of different blocks one has to add into a routing table. The lazy answer would be to simply use a statement like 'network 10.0.0.0'. There. All routes for that block are automatically known and added into the routing table (syntax and concept varies a bit depending upon which routing protocol you use).
I'm not sure if that is an optimal solution. I generally like to be very specific about which subnets or supernets I allow into a network table. With addressing scattered through three different address ranges, detailed route table maintenance becomes time consuming.
I like to use route aggregation whenever possible.
I left that statement by itself as it is a very powerful statement. It is also a strong, guiding principle in network/routing table design.
I've used that to come up with a hierarchical addressing structure that works with many of my client sites. There are some scalability issues for very large organizations with many large offices. For the majority of organizations, I think the following scheme works well. As I'm in Bermuda, Bermuda is the center of my universe, and the numbering is based partially on that concept. There is nothing saying you can't change things to match your own geographic realities.
Since the 10/8 address range has the most number of addresses to work with, I use that as a basis for most schemes. The hiearchy I use follows this pattern. I'll break the last three octets into a bit map and assign meanings:
octet bitmap: 00001010.wwwxxxxx.yyyyzzzz.00000000 bitmap meanings: www: region (NA (001), SA (010), Europe (011), PacRim (101), Asia (100) xxxxx: country [ BM 1, CA 2, US 3, UK 1, IR 2 ] yyyy: city [ HAM,BM 1; NY,US 1; PA,US 2 ] zzzz: VLAN
The region numberse, starting at 1, are loosley based upon contintents and how inter-country fibres are run. These categories help with aggregation. Within a region, countries are numbered, starting at 1. Within a country, cities are numbered starting at 1. I start the numbering for each bit section at 1, as I use the 000, 00000, and 0000 portions for addressing of inter-region, inter-country, and inter-city links. You can't really aggregate those addresses into the routes of either site, so they need to be kept separate.
Therefore, for a site in Hamilton, Bermuda, addressing would start at 10.33.16.0. Addresses from the range 10.33.0.0 to 10.33.15.255 would be used for inter-city links. Addresses from 10.32.0.0 to 10.32.255.255 would be used for inter country links. Addresses from 10.0.0.0 to 10.31.255.255 would be used for inter-region links. Ip address utilization in this range is acknowledged to be quite sparse.
You'll note that this scheme breaks when you have coverage in more than 15 cities. Therefor the scheme needs to be adjusted based upon how many locations you have, how many buildings in each location, and how many floors in each location. It doesn't matter how the bit map is structured, just so long as some rule for aggregation is followed as the level of aggregation grows.
At each site, I've been refining a strategy for vlan and ip address block assignments. Sixteen is a base(2) number, and therefore easy to aggregate. I assign 16 /24 blocks and 16 VLANs per site using a strategy similar to:
+0 Subnets for /30 links +1 Servers +2 Server ILO Ports +3 SAN, iSCSI Traffic +4 Voice Servers & Gateways +5 Lab/Classroom/Testing +6 Spare, To Be Assigned +7 DMZ +8 Workstations +9 Phones +10 Wireless Corporate +11 Wireless Phones +12 Wireless Guest +13 Wired Guest +14 Printers +15 Network Management
The first set of eight blocks are server related. The second block of eight are client related. If an organization has mulitiple floors, conceivably a sequential block of eight would be assigned to each additional floor.
For VLAN numbering, I have a couple of different schemes. One scheme starts at VLAN 100 and assigns vlans 100 through 115 to each /24.
A second scheme is more complicated. In some locations, I use VRF's to segragate and route traffic. VRF's are handy when you have guest traffic you want to keep separate from corporate traffic. Cisco has a number of SRND documents on how this is accomplished. Anyway, I've used up to 5 segragations: 1 global routing table plus four VRF's:
1XX global 100 2XX vrfExterior 200 3XX vrfData 300 4XX vrfVoice 400 5XX vrfGuest 500
The first column is are the VLAN identifying numbers, the second is the VRF name, and the third column is the OSPF process number. By adding this numbering scheme to the VLAN types previously provided, the following table might be used, where column 1 is the VLAN ID, column 2 is a relative offset of a sequential VLAN numbering system, and the third column is the description:
+0 Subnets for /30 links 301 +1 Servers 302 +2 Server ILO Ports 303 +3 SAN, iSCSI Traffic 304 +4 Voice Servers & Gateways 305 +5 Lab/Classroom/Testing +6 To Be Assigned +7 DMZ 308 +8 Workstations 309 +9 Phones 310 +10 Wireless Corporate 311 +11 Wireless Phones 512 +12 Wireless Guest 513 +13 Wired Guest 314 +14 Printers 115 +15 Network Management
Some don't have VLANs as they don't exist as VLANS, but are address ranges uses elsewhere at the site.
Here are some additional VLAN assignments I'll use:
- 1: turned off, or not used at all
- 2: trunk native VLAN
- 3: 802.1x unauhtorized clients
- 20 - 29: switch SPAN ports for various monitoring activities
- 299: vrfExterior router to firewall exterior
- 399: vrfInterior router to firewall interior
- 599: vrfGuest router to firewall interior
Here is a finished table for showing address assignments for two different locations:
VLAN Offset BM Office NY Office +0 10.33.16.0 10.35.16.0 Subnets for /30 links and loopbacks 301 +1 10.33.17.0 10.35.17.0 Servers 302 +2 10.33.18.0 10.35.18.0 Server ILO Ports 303 +3 10.33.19.0 10.35.19.0 SAN, iSCSI Traffic 304 +4 10.33.20.0 10.35.20.0 Voice Servers & Gateways 305 +5 10.33.21.0 10.35.21.0 Lab/Classroom/Testing +6 10.33.22.0 10.35.22.0 To Be Assigned +7 10.33.23.0 10.35.23.0 DMZ 308 +8 10.33.24.0 10.35.24.0 Workstations 309 +9 10.33.25.0 10.35.25.0 Phones 310 +10 10.33.26.0 10.35.26.0 Wireless Corporate 311 +11 10.33.27.0 10.35.27.0 Wireless Phones 512 +12 10.33.28.0 10.35.28.0 Wireless Guest 513 +13 10.33.29.0 10.35.29.0 Wired Guest 314 +14 10.33.30.0 10.35.30.0 Printers 115 +15 10.33.31.0 10.35.31.0 Network Management Default Gateway is x.x.x.254
This type of scheme, when implemented from the start, provides easy expansion of an organization's network, provides an ability to add protections between network devices, and simplifies inter-site routing.