Datacentre IP address design

danc_101

Hello,

I am about to start a dual site migration to a single datacentre. As all the networking equipment will be newly installed I have the chance to design the network / IP addressing scheme from scratch.

Does anyone know of any Cisco best practices for IP address design within the Datacentre ?

Thanks

networker050184

Not sure what information exactly you are looking for. Can you clarify?

pert

Think he's looking for best practices for IP address management, assignment, planning etc. I don't know of one personally. From personal experience I've noticed that problems are usually from lack of planning, and only rarely from a poor plan. T

the best schemes I've see assign meaning to the various octets. If you have a multinational network. 10.x.y.z where x= country code, y = city code, and z = an ip scheme for each site that is the same for every single site. That way if someone says the LDAP server in Taipei is broken you'd know the IP without looking it or having a putty database.

Further, try to have a consistent cabling scheme across the network all the way down. Going back to the IP scheme example, you should be able know which switch and port the ldap server is on for any site without needing to look it up.

danc_101

Thanks pert - that's exactly what I was asking and indeed what I was already planning.

Thanks

Dan

malcybood

Key things to consider when developing a new IP addressing scheme are that you should be able to summarize the address block easily so it reduces the overhead on the network hardware and routing tables / protocols.

I usually do something along the lines of the following for data centre hosting designs.

If I had a data centre in London for example I'd use the following addressing schemes to start with:

London = 10.200.0.0 /16

At London you could build the data centre hosting environment up as per below:

10.200.1.0 /24 = Web servers
10.200.2.0 /24 = Database Servers
10.200.3.0 /24 = Active Directory

If the London site was not a dedicated data centre and also had user LANs for voice and data etc you could then allocate the London Data LANs to be configured under 10.201.0.0 /16 and voice LANs to be configured under 10.202.0.0 /16.

VLAN numbering can then be mapped in the same way as per below where data is in the "tens" and voice is in the "hundreds". The numbering scheme that is used and how it ties together is the choice of the designer but best practice is these should be related somehow.

I've given an example below for the user LANs.

London LAN User Floor 1 Data 1= 10.201.11.0 /24, Data VLAN 11
London LAN User Floor 1 Voice 1 = 10.202.11.0 /24, VLAN 111

London LAN User Floor 1 Data 2 = 10.201.12.0 /24, Data VLAN 12
London LAN User Floor 1 Voice 2 = 10.202.12.0 /24, VLAN 112

There may be multiple segments on each floor but in my experience there is not usually more than about 4 or 5 wiring closets on each floor in large buildings i.e. hospitals, schools etc that I've done designs on.

Floor 2 would then look something like the below.

London LAN User Floor 2 Data 1 = 10.201.21.0 /24, Data VLAN 21
London LAN User Floor 2 Voice 1 = 10.202.21.0 /24, VLAN 211

This approach means you only need to advertise two or three (you may want 10.203.0.0 /16 for network management using private VLANs for example) /16's into your routing protocol i.e. OSPF / BGP despite having up to hundreds of networks.

If you added another data centre in Amsterdam for example, you could use 10.208.0.0 /16 for the Amsterdam DC the .1 for web servers and so on following the same design logic. Basically mirror London's design with a different second octet.

As Pert mentioned the advantage to this approach is that you can narrow down where something is quickly i.e. 10.200 - 207.0.0 = London, 10.200.1.0 = London DC, 10.200.1.0 /24 = London web servers

Therefore if you had web servers in Amsterdam they would be put onto 10.208.1.0 /24 and so on. The same would be the case for the user subnets and again you would only have to advertise some /16s into the routing protocol despite potentially having hundreds of subnets, saving on resources and complexity.

Having some kind of logic where subnet octets relate to something is best practice, along the lines of something like the following example

10.site/location.function(web servers).host = 10.200.1.10 = Intranet webserver in London

This greatly simplifies future rollout of services, network troubleshooting and summarization of the network.

If you read the CCDP ARCH book there is a section on optimal layer 3 IP address design for IPV4 and IPV6, which validates the above. This is also how I was taught to design by mentors / senior designers when I started out in the design game a few years ago.

Hope it helps.

PsychoFin

That was extremely informative and helpful, malcyblood! Thanks!