2007 Sep 14 - Fri
IP Addressing Best Practices (plus VRF and VLAN ideas)
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.
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.
|
