IP Address Scheme

Answered Question

We are trying to come up with a new addressing scheme for our network. Does anyone have any reason not to use a /24 and setup multiple VLAN's and route between them when necessary? For example, maybe I have 10 VLAN's for PC's all with a max of 254 hosts. Then I have 10 VLAN's for IP phones all 10 VLAN's would have a differnt IP scheme. Would it become a routing nightmare? Would we be better off to have larger VLAN's and sacrafice some readability of the IP address (by that I mean being able to look at the IP address and know which VLAN and location the IP address is from). We plan to have all routing stay within the switching infrastructure rather than leave the switch to hit a router only to be routed back to a differnt port in the switch. Any help would be appreciated!

I have this problem too.
0 votes
Correct Answer by burleyman about 8 years 3 months ago

We use IP Addressing like this

• The first octet, 10., is just the class A private IP address block we choose for our network.

• The second octet, 10.X., is to designate which office or building the IP address range is assigned to.

a. Main Site - 10.1.0.0

b. Site 2 - 10.2.0.0

c. Site 3 - 10.3.0.0

d. Site 4 - 10.4.0.0

• The third octet, 10.X.X., is to designate the VLAN the IP address is a part of.

a. VLAN 1 is Network equipment (routers, switches, etc.)

b. VLAN 3 Lets say is for Servers

c. VLAN 5 Lets say is for Printers

d. Desktop and Laptop VLANS are assigned based on floor of the building. We add 100 to the floor number and we get the VLAN ID based on that, for example, the third octet for 18th floor would be 118, so a user in site 2 would be 10.15.118.X

e. VoIP VLANS are assigned based on floor like the Desktops and Laptops except we add 200 to the floor number. (so that means no floors over 54)

• The fourth octet, 10.X.X.X, is assigned manually or by DHCP depending on the type of equipment.

Here are some examples:

1. 10.3.3.55 - this is a server in Site 3 in VLAN3 and it is either named.

2. 10.2.118.54 -This is a workstation in Site 2 on the 18th floor in VLAN118.

3. 10.2.218.64 - This is a VoIP Phone in Site 2 on the 18th floor in VLAN218.

4. 10.4.5.20 - This is a printer in Site 4 in VLAN5.

5. 10.3.1.1 - This is a piece of network gear in Site 3 and is in VLAN1

Hope that helps,

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Correct Answer
burleyman Thu, 08/14/2008 - 08:26

We use IP Addressing like this

• The first octet, 10., is just the class A private IP address block we choose for our network.

• The second octet, 10.X., is to designate which office or building the IP address range is assigned to.

a. Main Site - 10.1.0.0

b. Site 2 - 10.2.0.0

c. Site 3 - 10.3.0.0

d. Site 4 - 10.4.0.0

• The third octet, 10.X.X., is to designate the VLAN the IP address is a part of.

a. VLAN 1 is Network equipment (routers, switches, etc.)

b. VLAN 3 Lets say is for Servers

c. VLAN 5 Lets say is for Printers

d. Desktop and Laptop VLANS are assigned based on floor of the building. We add 100 to the floor number and we get the VLAN ID based on that, for example, the third octet for 18th floor would be 118, so a user in site 2 would be 10.15.118.X

e. VoIP VLANS are assigned based on floor like the Desktops and Laptops except we add 200 to the floor number. (so that means no floors over 54)

• The fourth octet, 10.X.X.X, is assigned manually or by DHCP depending on the type of equipment.

Here are some examples:

1. 10.3.3.55 - this is a server in Site 3 in VLAN3 and it is either named.

2. 10.2.118.54 -This is a workstation in Site 2 on the 18th floor in VLAN118.

3. 10.2.218.64 - This is a VoIP Phone in Site 2 on the 18th floor in VLAN218.

4. 10.4.5.20 - This is a printer in Site 4 in VLAN5.

5. 10.3.1.1 - This is a piece of network gear in Site 3 and is in VLAN1

Hope that helps,

Mike

Joseph W. Doherty Thu, 08/14/2008 - 10:25

Mike's suggestion is very attractive, but you must carefully contrast the operational impact to maintain such addressing vs. the delivered value. If you're network is extremely static and/or small, this approach is very nice. If the network is larger or subject to change, this host type and host location complex addressing approach often creates needless work.

burleyman Tue, 08/19/2008 - 04:01

To make sure I am not missing anything can you elaborate on what you mean about operational impact to maintain such addressing? We are not a small network but we are not huge either, and we don't seem to have many issues, in fact it helps greatly in troubleshooting as it helps us narrow the scope of the problem very quickly. I always value input to help make our network better.

Thanks,

Mike

Joseph W. Doherty Tue, 08/19/2008 - 05:15

The operational impact is caused by the fact you've tied a logical meaning structure to a network topology. This works fine, and is indeed attractive, until such time as a topology requirement causes a conflict. Or, even when there are no conflicts, there's the extra work involved in configuration maintenance.

For instance, you've allocated /16s to buildings. Tomorrow, one site has expanded into another building on a campus. You easily assign another /16, but now the two /16s are not within the same /15, so you can't summarize an address block for the campus pair.

Or for another instance, you have a user VLAN on a floor that's using a /24 and it grows to the point where it needs a /23. (Different issue about subnet sizes.) Or, part of the user VLAN is now split across floors or buildings. Your being tied to the physical infrastructure topology precludes you from keeping all the users within the same VLAN. Today, with modern L3 switches, you avoid some possible performance issues doing this, but you might now have to replicate, and maintain, special access control to two VLANs where there used to be one.

The foregoing examples, may or may not be likely or important to you. What is important is you're aware of the trade offs involved in locking yourself into a logical addressing structure. Again, nothing wrong with doing so, and for many, its advantages outweigh its disadvantages, but do understand all the ramifications.

PS:

(A real world example.)

Several years ago I was consulting on a large campus LAN. Others wanted core-distribution point-to-point links (many) to make troubleshooting easier (so they could watch traceroutes). I recommended keeping the topology as tight as possible. My advice was disregarded. Then came the day of a link flap and the whole campus went into meltdown. Afterwards, my advice was implemented and later link flaps did not take out the whole campus.

Again, in this real world example, there was nothing wrong with the desire for p-2-p links, but on the scale involved, and for the routing protocol used, more consideration should have been given to "what if".

burleyman Tue, 08/19/2008 - 05:30

Thanks. I can see now where it would pose some challenges. That would not affect us.....yet, but it is still something to keep in mind. Thank you for your reply.

Mike

Richard Burts Thu, 08/14/2008 - 08:27

Blake

If we knew a bit more about your environment we might be able to give somewhat better answers. But based on what you have described so far I think that it sounds fine to create multiple VLANs for PCs and multiple VLANs for phones. Especially if the addressing scheme were carefully prepared and laid out on a logical basis I would see no reason why it should become a routing nightmare.

HTH

Rick

cowetacoit Thu, 08/14/2008 - 08:56

Burleyman is right, that is the best ip scheme you can do. I am in the process of IP restructuring and i am doing the exact same IP scheme as he suggested. i'll give you a rating burleyman.....nice suggestion. Very well structured for plenty of future growth.

burleyman Thu, 08/14/2008 - 09:32

Thanks. It also helps greatly in narroing the scope of any problems quickly. I left off for servers we give our server names numbers at the end of the name and make the last octet that number..... server57 at site 4 would be 10.4.3.57. Again that helps quickly ID the server.

Mike

Actions

This Discussion