# IT Network Management Scenarios

• December 28, 2023/

## Scenario 1-1: Calculation of Subnets

Scenario 1-1: Calculation of Subnets

Save Time On Research and Writing
Hire a Pro to Write You a 100% Plagiarism-Free Paper.

As provided by Arthur the network will be designed as follows:

Network Address:   172.16.85.0           10101100.00010000.01010101.0 0000000
SubNetmask:   255.255.255.128 = 25      11111111.11111111.11111111.1 0000000
Factor:  0.0.0.127                       00000000.00000000.00000000.0 1111111
=>

Network Address:   172.16.85.0/25        10101100.00010000.01010101.0 0000000   (Class B)
Broadcast: 172.16.85.127         10101100.00010000.01010101.0 1111111
HostMin:   172.16.85.1           10101100.00010000.01010101.0 0000001
HostMax:   172.16.85.126         10101100.00010000.01010101.0 1111110
Hosts/Net: 126                   (Private Internet)

Therefore, according to Arthur the subnets would have been stated as follows:

Save Time On Research and Writing
Hire a Pro to Write You a 100% Plagiarism-Free Paper.

The total number of subnets would have been 4 and denoted according to the networks below with a total host of around 120. With the formula (2^n)/(x+2), n represents the number of bits in host portion whereas x is the number of hosts in each subnet. The new requirement by Arthur requires 60 + 2 hosts for the whole network. Therefore, we can trace backwards using the formula used to calculate number of hosts 2^n-2. Therefore, grouping the hosts into six subnets of each 10 hosts will proceed as follows.

Nevertheless, to satisfy his needs 6 subnets are required so as to suit Arthurs specifications of 10 hosts per subnet. The procedure is explained in the following steps:

Calculating the number of bits in the network address host portion having predetermined the number of subnets needed as 6.

Binary: 11111111.11111111.11111111.1 0000000

Address:   172.16.85.0           10101100.00010000.01010101.0 0000000
Netmask:   255.255.255.128 = 25  11111111.11111111.11111111.1 0000000
Wildcard:  0.0.0.127             00000000.00000000.00000000.0 1111111
=>

Network:   172.16.85.0/25        10101100.00010000.01010101.0 0000000   (Class B)
Minimum Host:   172.16.85.1              10101100.00010000.01010101.0 0000001
Maximum Host:   172.16.85.126            10101100.00010000.01010101.0 1111110
Users: 126

Subnets

Netmask:   255.255.255.240 = 28  11111111.11111111.11111111.1111 0000
Wildcard:  0.0.0.15              00000000.00000000.00000000.0000 1111

Network 1:   172.16.85.0/28        10101100.00010000.01010101.0000 0000 (Class B)
Minimum Host:   172.16.85.1              10101100.00010000.01010101.0000 0001
Maximum Host:   172.16.85.14             10101100.00010000.01010101.0000 1110
Users: 14

Network 2:   172.16.85.16/28       10101100.00010000.01010101.0001 0000 (Class B)
Broadcast: 172.16.85.31          10101100.00010000.01010101.0001 1111
HostMin:   172.16.85.17          10101100.00010000.01010101.0001 0001
HostMax:   172.16.85.30          10101100.00010000.01010101.0001 1110
Hosts/Net: 14

Network 3:   172.16.85.32/28       10101100.00010000.01010101.0010 0000 (Class B)
Broadcast: 172.16.85.47          10101100.00010000.01010101.0010 1111
HostMin:   172.16.85.33          10101100.00010000.01010101.0010 0001
HostMax:   172.16.85.46          10101100.00010000.01010101.0010 1110
Hosts/Net: 14

Network 4:   172.16.85.48/28       10101100.00010000.01010101.0011 0000 (Class B)
Minimum Host:   172.16.85.49             10101100.00010000.01010101.0011 0001
Maximum Host:   172.16.85.62             10101100.00010000.01010101.0011 1110
Users: 14

Network 5:   172.16.85.64/28       10101100.00010000.01010101.0100 0000 (Class B)
Broadcast: 172.16.85.79          10101100.00010000.01010101.0100 1111
HostMin:   172.16.85.65          10101100.00010000.01010101.0100 0001
HostMax:   172.16.85.78          10101100.00010000.01010101.0100 1110
Hosts/Net: 14

Network 6:   172.16.85.80/28       10101100.00010000.01010101.0101 0000 (Class B)
Broadcast: 172.16.85.95          10101100.00010000.01010101.0101 1111
HostMin:   172.16.85.81          10101100.00010000.01010101.0101 0001
HostMax:   172.16.85.94          10101100.00010000.01010101.0101 1110
Hosts/Net: 14

Network 7:   172.16.85.96/28       10101100.00010000.01010101.0110 0000 (Class B)
Minimum Host:   172.16.85.97             10101100.00010000.01010101.0110 0001
Maximum Host:   172.16.85.110            10101100.00010000.01010101.0110 1110
Users: 14

Network 8:   172.16.85.112/28      10101100.00010000.01010101.0111 0000 (Class B)
Minimum Host:      172.16.85.113         10101100.00010000.01010101.0111 0001
Maximum Host:      172.16.85.126         10101100.00010000.01010101.0111 1110
Users: 14

## Scenario 1-2: Network Expansion

Scenario 1-2: Network Expansion

2^n-2 = 500 is the formula to determine the subnet network address for the intended regional offices. Together with the accommodated 40 sites of each 100 users will require a total of around 4500 host addresses from the network 172.16.0.0/24. However, implementation of the Network Address Translation will be partial and not backward compatible. The transition can amply be accomplished using the dual stack technology which allows ipv4 and ipv6 to exist in a similar network, hence, it is able to connect to remote servers. Scenario 2-1: DNS Server Deployment

As prescribed by Syngress (2003), planning for the network’s zone replica is essential in a DNS infrastructure. The process entails determination of where to position the DNS servers, specifically deciding which servers to load with files from sections of the network’s domains. By distributing the files across the network poses pros such as reducing the network traffic resulting from DNS queries. Therefore, the administered zone files can increase network’s tolerance to faults, ascertain of load balancing as well as lead to brief query response times. The requirement procedure would thus include replication of zone information amongst all DNS servers, bolstering AD replication associated traffic since Active Directory- integrated zones are enabled (STIG Viewer, 2018). Lastly, the zone files will ensure an increase in distribution efforts fundamental in maintaining a DNS infrastructure.

Scenario 2-2: Web Server Management

As implemented in Windows Server 2012 R2, DirectAccess and Routing as well as Remote Access Service denoted as RRAS virtual private network are integrated to a common role of remote access. The technologies are handy for configuration of seamless access to corporate data by employees. Through the web application proxy, corporate resources can be published as well as a multi-factor authentication. Similarly, users can amply access web services through the bolstering of defined access policies as soon as they connect to the organization network.

Scenario 2-3: Web Server Traffic Distribution

In the scenario of three web servers, load balancing for each will ensure an administration of workloads amid various nodes. The process involves balancing HTTP dealings over the servers which are actively serving on the sites front-end. The load balancer will enable all users to knowingly administer traffic to one IP amid the three servers using various protocols (Phokeer et al., 2016). As such the methods of load balancing to be used may include round robin, least connect or a historical intelligence also referred to as the perceptive algorithm.

## Scenario 2-1: DNS Server Deployment

Scenario 3-1: DNS Implementation

So as to ensure availability of the information system implemented for corporate office, engineering and manufacturing sites; eliminating any one point of loss in the network architecture is mandatory. Since DNS is the core service for the network since it allows resolution of host name to IP address (Joshi, 2017). Therefore, elimination of those failure points, ensuring redundancy is enabled by using a minimum of two classical domain name servers (DNS). Firstly, one is set up as primary while the other secondary. Secondly, positioning of the servers can be made on different subnets of the network as well as a different physical condition.

Scenario 3-2: DNS Updates Manipulation

Manual maintenance of DNS records is challenging thence the need for dynamic DNS updating using Microsoft DNS server. However, caution is taken so as to ensure safety in the process. A secure update of static DNS records mandates for a limitation among users authorized through rights to update. Dynamic DNS records which are formed by DNS systems on behalf of users allows updates with minimal efforts of maintaining DNS zones (Faccin et al., 2014). The configurations can be done in three separate ways including

• None – only allows static management or records.
• Non-secure and secure allow for dynamic updates without need to check if source is trusted or not.
• Secure only are dynamic updates that emanate for only trusted sources and is present for primary DNS zone as an AD-integrated DNS zone hosted on a Domain Controller.

Scenario 3-3: Time To Live (TTL) Configuration in DNS

Regarded as the hop limit in ipv6, Time-to-live (TTL) is an IP packet that instructs the router on the packets duration on the network. It is initially set by the sender system and could be set amid values 1 and 255 depending on the operating system, each having its default value. Using BIND resource records, explicit TTL values are allowed to override the area file’s TTL for the particular record (McHenry, 2018). The latter is implemented to prevent non-classical servers from hoarding the records as a preliminary change of the server’s IP.

References

Faccin, S., Purnadi, R., Hulkkonen, T., Rajaniemi, J., Tuohino, M., & Sivanandan, M. (2014). U.S. Patent No. 8,862,751. Washington, DC: U.S. Patent and Trademark Office.

Joshi, P. S. (2017). U.S. Patent No. 9,584,360. Washington, DC: U.S. Patent and Trademark Office.

McHenry, Q. (2018). DNS/BIND: set TTL for individual resource records. Retrieved from https://www.tech-recipes.com/rx/310/dnsbind-set-ttl-for-individual-resource-records/

Phokeer, A., Aina, A., & Johnson, D. (2016, December). DNS Lame delegations: A case-study of public reverse DNS records in the African Region. In International Conference on e-Infrastructure and e-Services for Developing Countries (pp. 232-242). Springer, Cham.

Syngress, S. (2003). MCSE Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (Exam 70-293). Elsevier Science.

STIG Viewer | Unified Compliance Framework®. (2018). The DNS implementation must be fault-tolerant.. [online] Available at: https://www.stigviewer.com/stig/domain_name_system_dns_security_requirements_guide/2012-10-24/finding/V-34261 [Accessed 17 Oct. 2018].