Hotel case study - IP addressing
IP addressing and subnetting
Explanation
The network allocation you have been given is the 10.0.0.0 /8 network. This is a private address range that anyone can use so there is no shortage of these addresses.
In fact, there are more than 16 million addresses. Be careful of avoiding waste and creating complexity. You should allocate addresses with these priorities:
- Enough IP addresses to meet the current requirements.
- Enough room for growth so you can avoid having to restructure the addressing scheme when you outgrow it.
- A hierarchical scheme that allows you to summarise.
- A systematic and consistent approach that is easy to understand and new networks can be allocated using a template.
You should see an emerging theme of growth and simplicity. This is what makes a design scalable. If we get the design right for one hotel, we can scale this to 100 hotels easily.
Suggestion
Subnetting for scalability requires a different mindset than subnetting for address preservation. So it is important to know what you are trying to achieve. In this case, we have a lot of addresses so we should try to make the "best" design we can, not the one with the smallest subnets possible. We want to think in terms of a VLSM hierarchy. Our first cut will be a block of addresses to hold everything in an area we would like to summarise. What area might we summarise on? An entire hotel might be a start. So our routing table can have one entry per hotel (instead of entry for every floor and staff net). That sounds manageable. It will be easy to troubleshoot and it will make ACLs flexible. With a single statement, we can select traffic for an entire hotel. That might come in handy if a hotel falls victim to a cyber attack and we need to control traffic at an entire site.
But how big should that first cut of addresses be?
Given that the hotel subnet needs to include all the floor subnets, the staff subnet and a few point-to-point links, we really can't work out how big a hotel should be until we know how many floors there are and how many IP addresses are needed in each subnet.
But how big should the subnet for a floor be?
The scenario suggests that there are 56 rooms to be catered for. So one answer might be to use a /26 which would allow for 62 usable addresses (less one for the router/gateway) or 61 hosts. However, that's not much room for growth and it would be the maximum size that any hotel could have. What if we had a hotel with 100 rooms on a floor? A /25? In the past, this scenario has been used for a graded assignment and I have accepted a /25 as offering a reasonable growth. But what if we decide that on average guests need two IP addresses per room and we allow for a 200 addresses? We could provide a /24 subnet for each guest floor. At around this point students become uneasy, "We're wasting so many addresses; where will it end? What if we assume 5 IP addresses per room?". The answer is that it probably should end at /24. Not because the network will never grow bigger, but because a subnet (or VLAN) is a broadcast domain. Every host in that subnet will receive every broadcast. This impacts performance of both the network and the hosts which waste CPU time processing the broadcast. For mobile clients the added wireless traffic also impacts battery life. So while you can have a /23 or even a /22 (Murdoch University uses a /22) it isn't best practice. In general you should avoid creating a VLAN/Subnet larger than /24 for performance reasons. If you need more hosts add an extra subnet not a bigger one. The second reason I advocate using a /24 is that it is easy for humans to understand. All the subnets have a distinct three octet decimal number.
While having a /24 subnet is easy to work with, the bigger the subnet, the fewer we can have. So using a /24 guest subnet per floor is dependent on their being enough subnets to go around.
How many floors should we cater to?
For the case study you only physically model two floors. But your IP addressing scheme should be scalable and allow for a realistic number. The worlds biggest hotels seem to have around 100 floors so this is a pretty safe maximum. To represent 100 floors we would need 7 bits (128). To accommodate a single hotels guest requirements we need 8 bits (hosts) + 7 bits (floors) which gives us 15 bits or a /17 (32-15). Given that we started with 8 bits (10/8) and have a hotel subnet of /17, that leaves us with (17-8) 9 bits to represent hotel sites. That's 512 sites which would be a large chain of hotels. If you arrive at that solution I think it represents an answer that is the most scalable in terms of it being the least likely to need to be restructured in the future.
However, the addressing scheme I am going to propose compromises the ultimate growth in exchange for ease of management and understanding. If the hotel group had a modest number of existing sites (let's say 20) or we consider that the IP addressing scheme only needs to apply to a single country then I would suggest the following scheme:
8 bits representing Hotel sites 8 bits representing subnets (guests, staff and one to be used with VLSM for links) 8 bits representing hosts in the /24 networks.
This would allow for 256 hotels of 250+ floors with 253 (+gateway) hosts.
The reason I advocate this design it that it will allow us to form the following easy to understand summary addresses:
Each hotels addresses can be taken out of a /16 network.
10.1.0.0 /16 - First hotel 10.2.0.0 /16 - Second hotel 10.3.0.0 /16 - Third hotel | 10.255.0.0 /16 - Last hotel
I would reserve the 10.0.0.0 /16 network use for subnetting into links between hotels and any non-hotel site needs the group has. For example if they need a data centre, I would take the addressing from here. Again, I am planning on growth.
For the guest levels I would use the following approach (let's start with the first hotel (10.1.0.0/16)
10.1.1.0 /24 - Guests level 1 10.1.2.0 /24 - Guests level 2 10.1.3.0 /24 - Guests level 3 | 10.1.127.0 /24 - Guests level 127
Note that the third octet matches the floor number. That's why I didn't start with 10.1.0.0 /24.
The whole of the guests IP address range can be summarised with 10.1.0.0/17. Please take to understand that and think it through.
Later on, we may want an ACL that controls traffic to the Guests. Having all their addresses come from a single block of addresses will make it much easier.
How about the Staff subnet
We only need one subnet for the staff and I will allocate them 10.x.128.0 /24. Again a /24 network is the maximum I recommend. In a large hotel you may have more than 254 staff devices and so you would need more subnets. If I needed more I would add 10.x.129.0 /24. (Note that all staff could be summarised by 10.x.128.0 /23). For this case study I will just leave it as one /24 subnet for staff to keep it a bit simpler. But in a real network, deciding the upper end of your staff requirements and accommodating it would be an important early design decision.
OVERVIEW OF HOTEL ADDRESS STRUCTURE 10.0.0.0 /8 Initial allocation of entire 10 network | 10.0.0.0 /16 To be further subnetted for links between sites (/30) and other purposes not relating to individual hotel sites. | 10.1.0.0 /16 Summary address for Perth hotel site | | 10.1.0.0 /17 Summary address for Perth guests | | 10.1.0.0 /24 Future use | | 10.1.1.0 /24 Guest 1st floor | | 10.1.2.0 /24 Guest 2nd floor | | | | | 10.1.127.0 /24 Guest 127th Floor | | 10.1.128.0 /17 | | 10.1.128.0 /24 Perth Staff - first subnet | | 10.1.129.0 /24 Additional staff subnet if needed | | 10.1.130.0 /24 Future use | | | | | 10.1.254.0 /24 Future use | | 10.1.255.0 /24 For point-to-point links | | 10.1.255.0 /30 First Perth internal link | | 10.1.255.4 /30 Second Perth internal link | | | | | 10.1.255.252 /30 Last available Perth link subnet | | | 10.2.0.0 /16 Summary address for Sydney hotel site | | 10.2.0.0 /17 Summary address for Sydney guests | | 10.2.0.0 /24 Future use | | 10.2.1.0 /24 Guest 1st floor | | 10.2.2.0 /24 Guest 2nd floor | | | | | 10.2.127.0 /24 Guest 127th Floor | | 10.2.128.0 /17 | | 10.2.128.0 /24 Sydney Staff - first subnet | | 10.2.129.0 /24 Additional staff subnet if needed | | 10.2.130.0 /24 Future use | | | | | 10.2.254.0 /24 Future use | | 10.2.255.0 /24 For point-to-point links | | 10.2.255.0 /30 First Sydney internal link | | 10.2.255.4 /30 Second Sydney internal link | | | | | 10.2.255.252 /30 Last available Sydney link subnet | | | 10.3.0.0 /16 Summary address for the third hotel block. | | | | | 10.255.0.0 /16 Summary address for the last available hotel block.
Applying the above addressing to the Perth site we get this:
Note the links should be 255 not 253 and PerGuest 2 should be 10.1.2.11.
