Hotel case study using EVE - Overview

From csn
Jump to navigation Jump to search

Learning objectives and approach

This case study provides an opportunity to apply the topics and technologies explored in individual labs and bring them together in a larger scale network. Although there are no marks associated with the exercise, it is a crucial learning exercise and you will struggle pass the unit without full engaging. This case study leads to the following outcomes:

  • An opportunity to practice what was covered in class.
  • An opportunity to push yourself and your understanding in a less structured exercise.
  • An opportunity to work on a larger topology than could be handled in a lab session.
  • Exposure to the interaction of various technologies operating in combination.
  • Practice with troubleshooting and identification of issues.
  • Familiarity with the network topology and environment. This is important as your practical exam will based around the same topology.

Each week, a portion of the case study will be developed, in line with the teaching topic. You should aim to complete the portion of the case study relating to weekly teaching topic soon after completing the labs, while things are fresh in your mind.

Keep in mind that this is a learning exercise and there are many ways to learn. You can seek assistance from others but your objective, at all times should be to learn. If you seek assistance from your peers or your tutors, it should be to aid your understanding or obtain feedback so that you can eventually complete the case study on your own and obtain the most benefit possible. There is NO benefit in merely obtaining someone's completed case study and trying to memorising it. The configuration will tell you nothing about the interaction of technologies or help you develop your trouble shooting skills.

Scenario

To give the case study some context this is the scenario:

You have been tasked with designing a network for the Hotel California Group (HCG). At this stage HCG is opening two hotels in Australia on a small scale to refine their business model before expanding. One hotel is in Perth and one in Sydney. Both hotels consist of two floors with with 56 guest rooms on each floor. Each guest room will have a single RJ45 Ethernet jack that you need to provide connectivity for. In addition there are various hotel and hotel staff facilities that require network access on each floor.

Using the provided EVE topology you should configure the routers, switches and hosts to provide the functionality outlined in this document.

Note that the requirements listed may not answer all of your questions as to what is needed. In some cases it may be appropriate to seek further information from your client (Unit Coordinator). You are encouraged to make use of the general forum on LMS to ask questions. In this way all students will receive the benefit of advice given.

Overall requirements

Listed below are the overall requirements for the Hotel network.

If it seems overwhelming, don't worry. They are listed here for completeness but each week you will tackle a portion of the problem in a structured way.

Spreading the task over the semester, focussing on one element at a time will make it much more manageable.

IP Addressing Requirements

California Hotel Group will use the 10.0.0.0 /8 private network.

  • The IP subnet structure should follow a system that will make it easy to add more hotels in the future.
  • Ensure your subnets and address allocation allows for some growth and also choose subnet sizes that are easy to understand and work with. This will aid development and reduce errors.
  • Structure your addressing in a hierarchical fashion to allow for address summarisation.

Routing Requirements

You must provide intervlan routing, such that all devices can ping one another.

  • Configure intervlan routing on all DL switches.
    • Users on level one should make use of DL1 as their default gateway.
    • Users on level two should make use of DL2 as their default gateway.
    • Use HSRP with the active router for each guest floor being on a different router.
  • OSPF should be used as the routing protocol.
    • Area zero consists of the WAN links between the core routers.
    • Area one consists of the Perth hotel network links except the WAN.
    • Area two consists of the Sydney hotel network links except the WAN.
  • OSPF should be used to distribute default routes to the Internet.
  • In order to make the network more scalable and easier to configure, you should maximise your use of OSPF. Only use static routes where they are absolutely needed.
  • Configure summarisation so that the other hotel can be represented as a single route in the routing table of the other.

Connection to ISP

Hotel California has connections to its ISP in both Perth and Sydney. The ISP has been pre-configured and should not be altered, although you can use it for testing.

The ISP connection details are as follows:

Perth
ISP router address: 200.100.50.129
Customer IP address: 200.100.50.130 /30
Protocol: PPP
Username: PERCore
Password: h4rd2gue55
Global address pool (NAT): 123.123.123.68 /30
Sydney
ISP router address: 200.100.50.5
Customer IP address: 200.100.50.6 /30
Protocol: PPP
Username: SYDCore
Password: h4rd2gue55
Global address pool (NAT): 123.123.123.64 /30


Example Perth Core PPP configuration (Translate this for Sydney)
username ISP password 0 h4rd2gue55
!
interface Serial1/1
 ip address 200.100.50.130 255.255.255.252
 encapsulation ppp
 ppp authentication chap
 ppp chap hostname PERCore


  • You should provide Internet access for Hotel staff and Guests.
  • NAT will need to be implemented at each site, making use of the pools of global addresses allocated by the ISP.
  • The desired behaviour is that traffic from each hotel exit to the Internet at the local site to prevent unnecessary use of the WAN link between the Perth and Sydney sites.
  • In the event that one of the hotels Internet links fails, Internet traffic for the entire hotel group should make use of the remaining link.

Links

  • Links should be manually configured and not left to negotiate their parameters.
  • Parallel links should be configured as Etherchannels.

VLANs and trunks

  • Use VTP mode transparent as this will force EVE to save your VLAN information in the running configuration.
  • You should create and name one VLAN (10) for hotel staff and a separate VLAN for Guests on each floor of the hotel (101 and 102). This will require three VLANs at each site.
  • Trunks should be implemented between the distribution and access switches to provide redundant connections.
  • The access switch port connecting to each PC should be placed in an appropriate VLAN.

Security

  • Only communications initiated from within HCGs network should be allowed to enter the hotel from the Internet.
    • No direct traffic is allowed to flow between the guest subnets and the hotel systems and hotel users.
    • No user should be able to access addresses in the range 1.2.3.4-10 as these are known phishing sites.
    • All users should be able to ping any Internet address. You can test with the simulated Google.com (172.217.25.164).
    • Guests are only allowed to browse the web. They are not allowed to use protocols other than HTTP, HTTPS (ping is OK).

Optimisation

Wherever possible, within the limitations of EVE, you should:

  • Maximise the redundancy of links and devices through configuration. Note however that the topology cannot be altered from that provided. You are also not permitted to add any additional routers or switches to the topology.
  • Ensure sensible and efficient traffic paths. In particular, you should pay attention to the STP topology and the allocation of gateway addresses.
  • Ensure full use of the available bandwidth, link and router capacity through the use of redundant links and devices. Note that the use of the load-balancing features of some routing protocols is outside the scope of this assignment.
  • Take into account the convergence, or recovery, time after a device failure and select protocols and techniques that minimise the time taken to recover. Note there is no need to alter any default timers. Merely to choose sensibly among the available protocols and techniques.

Although there are constraints imposed by EVE, the design, technology and techniques used are left to your professional judgment. You should examine each of the technologies and techniques explored in ICT535. Where relevant and appropriate to the scenario you should include the technology in your design. Don't include a technology if it is not justifiable in the context of a hotel network.

In the absence of specific requirements, you should use best practices with a view to creating a design that performs well, is fault-tolerant, scalable and maintainable. Where there is a choice between a proprietary technology and a standards-based approach, the standards-based approach should be adopted unless there is a compelling performance or functional reason for choosing the proprietary approach.

ISP Configuration

hostname ISP
!
username SYDCore password 0 h4rd2gue55
username PERCore password 0 h4rd2gue55
!
interface Loopback100
 description google.com
 ip address 172.217.25.164 255.255.255.255
!
interface Loopback1
 description phisher
 ip address 1.2.3.1 255.255.255.255
! 
interface Loopback2
 description phisher
 ip address 1.2.3.2 255.255.255.255
!
interface Loopback3
 description phisher
 ip address 1.2.3.3 255.255.255.255
!
interface Loopback4
 description phisher
 ip address 1.2.3.4 255.255.255.255
!
interface Loopback5
 description phisher
 ip address 1.2.3.5 255.255.255.255
!
interface Loopback6
 description phisher
 ip address 1.2.3.6 255.255.255.255
!
interface Loopback7
 description phisher
 ip address 1.2.3.7 255.255.255.255
!
interface Loopback8
 description phisher
 ip address 1.2.3.8 255.255.255.255
!
interface Loopback9
 description phisher
 ip address 1.2.3.9 255.255.255.255
!
interface Loopback10
 description phisher
 ip address 1.2.3.10 255.255.255.255
!
interface Loopback11
 description phisher
 ip address 1.2.3.11 255.255.255.255
!
interface Loopback12
 description phisher
 ip address 1.2.3.12 255.255.255.255
!
interface Serial1/0
 description link to Hotel California - Perth
 ip address 200.100.50.129 255.255.255.252
 encapsulation ppp
 ppp authentication chap
 no shutdown
!
interface Serial1/1
 description link to Hotel California - Sydney
 ip address 200.100.50.5 255.255.255.252
 encapsulation ppp
 ppp authentication chap
 no shutdown
!
ip http server
no ip http secure-server
ip route 123.123.123.64 255.255.255.252 200.100.50.6
ip route 123.123.123.68 255.255.255.252 200.100.50.130
!
banner motd ^C You may not make changes to this router other than updates provided by the Unit Coordinator^C
!