Configure IPv4 Static Addressing

In this activity, we will discover the effect on connectivity when you adjust the subnet mask applied to an IP configuration.

DC10 is configured with an IP address of 10.1.16.1 and a subnet mask of 255.255.255.0, while MS10 has the IP address 10.1.16.2. In CIDR notation, these addresses can also be expressed as 10.1.16.1/24 and 10.1.16.2/24.

We'll begin by pinging 10.1.16.1 to verify the link in Command Prompt and then switch over to DC10 and ping 10.1.16.2.

It's worth noting that a packet sniffer such as Wireshark can be very helpful when troubleshooting network errors and misconfigurations. Running Wireshark on DC10 and MS10 would allow you to see exactly how the packets are addressed as changes are made.

Here, we'll introduce a configuration problem by changing DC10's subnet mask to 255.255.0.0.

We'll open up Network Connections by right-clicking the start button. Then we'll navigate through Ethernet > Change adapter options > Right-clicking Ethernet > Properties > double-clicking Internet Protocol Version 4 (TCP/IP) and setting the subnet mask to 255.255.0.0.

We go back to PowerShell and ping 10.1.16.2 again and see that ping still works. 

When switching back to our MS10 VM and pinging 10.1.16.1, the ping still works. MS10 can reply to DC10 and DC10 can reply to MS10, as the network IDs match one another regardless of which of the two masks is used.

Here, we'll change the IP address of MS10 to 10.1.254.2, and test the effect.

We'll change the ip address using the command propmt and then try pinging 10.1.16.1 and display the results.

MS10 needs to use a router to reach a 10.1.16.0/16 subnet from a 10.1.254.0/24 subnet, but it cannot reach the router configured as its default gateway (unsurprisingly, as it doesn't exist). This can produce a mix of Request timed out errors (because ARP cannot identify the default gateway) and Destination unreachable errors (because there is no other route in the local routing table).

Let's change the subnet mask of MS10 to 255.255.0.0, and test the effect.

Switching ober to the DC10 machine, we ping 10.1.254.2 and we see the result is successful.

Back at the DC10 VM we change the subnet mask back to 255.255.255.0, and test the effect.

This initially fails, with Destination net unreachable messages. Since we ran the command quickly, we also see a General failure message. This is a transitory error because the new configuration isn't properly initialized.

Back on the MS10 VM, we ping 10.1.16.1 and we receive Request Timed Out messages.

Now MS10 can send to DC10 as it thinks both are on the 10.1.16.0/16 network, but DC10 cannot deliver replies to MS10 as it has no route to a 10.1.254.0/24 network.

Consequently, MS10 generates a Request timed out error because it thinks the network path is valid, but the host is not responding. In the captures, you should be able to see that DC10 receives Echo Requests and generates Echo Reply packets but that no replies are received by MS10

Applying inconsistent subnet masks may or may not break communications between hosts and can sometimes be difficult to identify. Hosts in the same subnet should be configured with the same mask, ideally from an autoconfiguration service such as DHCP.

In the command prompt, we set the original configuration on our MS10 VM with: 

netsh interface ip set address "Ethernet" static 10.1.16.2 255.255.255.0 10.1.16.254

In powershell, we set the original network configuration for our DC10 VM:

netsh interface ip set address "Ethernet" static 10.1.16.1 255.255.255.0 10.1.16.254

Things to keep in mind: a router would be required for HostA at 10.1.16.42/24 and HostB at 192.168.2.200/16 to communicate

a router is not required for HostA at 10.1.16.42/24 and HostB at 10.1.16.200/16 to communicate