What are the effects of incorrectly setting the netmask? I have a C++ application that sets the network mask of a device. If the netmask is set incorrectly, tftp doesn't seem to work properly. Why would this happen? What other problems occur when the netmask is not properly set for a device/PC?
While this question is probably more about IP networks than programming it is a challenging subject for many developers.
The netmask delimits the host address (your PC or server) and the network address (the part of the logical network infrastructure in which your system lives). The two parts are used to deliver the data packet to the correct device. The network address is obtained by ANDing the netmask with the IP Address. Consider the following scenario:
IP Address: 10.0.1.1
Netmask: 255.255.0.0
The host address portion of the IP address for our PC is 1.1, so the PC knows that any host addresses starting 10.0. are local to it. Any addresses that then start 10.1, etc, are not 'local' and will need to be forwarded to a router. If you have another device intended to be on the same network that is:
IP Address: 10.0.2.1
Netmask: 255.255.255.0
Here the netmask is wrong for our example setup, this device is now going to see the network address as 10.0.2 and the host address as 1, if it tries to communicate with 10.0.1.1 it will see a network address of 10.0.1! Not local and so will refer it to the default router for forwarding. If the netmask was correctly set (i.e. the same as the first example, assuming that's the correct setting for your network) then the second device would see the first as local, i.e. on the 10.0 network and wouldn't attempt to forward the packet to a router.
Many protocols will happily cope with this but tftp is intended to operate within a single network and so will fail as there's a perception that the target is on a different network.
This may not describe your exact situation but I hope that the example demonstrates the important principle that configuration matters, you can't have an inaccurately configured environment and expect it to work.
The netmask determines which IP adresses are local (non-routed); IP adresses outside that range go through the router. If the netmask is wrong, the program tries to directly access sites where it has to go through the router, or vice versa.
The netmask defines, which part of the IP-address is used as address for the network and which part is used for the workstations.
First Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.0.0
Both IPs are in the same net. They can communicate with each other without needing a router. That's because the IP-addresses will result in the same bitmask when you or it with the netmask.
Second Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.128.0
Now both IPs are in different networks because when you or the IP-addresses with the Netmask, the resulting bitmask will be different and they wont be able to communicate with each other without a router that routes between the two networks.
You can test this by yourself with ipcalc.
Possible implications of mismatched netmask are explained here. In short:
The host is likely to construct routing table incorrectly.
The host will miss some broadcast packets and not send broadcasts properly.
Mis-function of TFTP is almost for sure caused by the first reason. It affects any other IP protocol in the same way.
Other answers mention only the first problem (which is OK, as the second one is rather marginal). Note that it is not the netmask of the interface itself which determines how the IP packets would be routed - it is the routing subsystem of the host; but the netmask is normally used for constructing the routing table.
Related
I have a Linux machine with two interfaces eth0 and eth1.
eth0 has 192.168.2.30 and eth1 has 172.16.30.20. eth0 is connected to a router which is the gateway too for the WAN. eth1 is connected to LAN. All is working well until I had to connect a
set of devices with IP rage 192.168.2.5 - 192.168.2.15 to the LAN to which eth1 is also connected.
I want to send a multicast packet to these devices. Since the multicast works on the same subnet, I created an IP alias using following.
system("ifconfig eth1:1 192.168.2.100 netmask 255.255.255.0 up");
Despite adding the above, the packets are not going through eth1. This is found to be because eth0 is also having the same subnet as that of eth1: 1.
I tried calling ip route add <multicast ip> dev eth1. But, no success.
Appreciate if anyone could offer suggestions.
From the looks of it you have at least two problems here and depending on the solution you choose other issues may arise.
Problem one, Overlapping subnets: The absolute 100% correct way to resolve this is to change the subnets so they don't overlap. I can't stress enough how important this is in your situation. If these computer on 192.168.2.5 - 192.168.2.15 are suppose to be connected to the same network as eth0 then you need to reconsider your setup as this would never work because you will create a networking loop or bad routes.
In the first situation where 192.168.2.5 - 192.168.2.15 and 192.168.2.15 aren't physically connected in any way and if someone above you says you can't do this you can try creating a NAT on eth1 so that your system sees the subnet on a different network. But this can make understanding the routes confusing and may interfere with multicast traffic.
After this is done run a tracerroute to ensure traffic is passing correctly. If not please provide the output and the route you expect it to take along with the current setup.
If multicasting doesn't work still then I recommend to create another question for it.
I am just preparing for a test in college about networking.
I'm currently trying around with sub netting and I found out that two devices attached to a layer 2 switch can talk to each other although they have different subnets!
Device A: 192.168.0.1 subnet mask : 255.255.255.0
Device B: 192.168.1.1 subnet mask : 255.255.255.0
The question is why I can ping from device A to B and vice versa?
There's no router, just the two devices and a switch.
From my understanding they should not see each other.
The OS should not even send the ARP request when the unknown IP is in a different subnet.
Could this be a caching issue?
Many Cisco Layer 2 switches are capable to ping the connected systems.
It is possible that your computer might have a route entry that sends a packet which matches no other specific route entry to your router. This is also called as the default gateway. Conventionally the computers in the same subnet are connected directly and most of the times, do not go through the gateway.
To explain it more clearly, If you're on a Linux machine, run route -n.
Destination Gateway Genmask
14.0.1.0 0.0.0.0 255.255.255.0
0.0.0.0 172.16.80.1 0.0.0.0
The first entry has a destination ranging from 14.0.1.0 to 14.0.1.255. The gateway for this match is 0.0.0.0. The table implies that these systems are connected directly. On the other hand, the entry 0.0.0.0 in the destination field will get matched when the packet matches none of the other entries. The gateway for this is the router address (which in my case in 172.16.80.1). All the packets that do not have IPs in the range that I specified above go to the router for further routing. Once the router gets the packet, it takes the further decision based on its routing information that it posses.
In your case the router happens to know that the other subnet is attached to it and hence passed your packet onto that subnet.
Have a closer look at the ARP. The ARP would be addressed to the router in your case of pinging to the other subnet. On the other hand, if pinging within the network, the ARP would be to the destination directly. This is the conventional case. Of course, it all depends on the routing tables in your system. You can always make all packets go through the gateway or no packets to go through the gateway.
Can a computer with an IP address of class C like 192.168.0.1 and subnet mask 255.255.255.0 communicate and share resources with another computer having the IP 192.168.1.1 and the same subnet mask 255.255.255.0 ? I'm asking this because the first 3 octets in this case tell us that these IPs are running on different networks (network 192.168.0.0 and network 192.168.1.0).
Also, does "network" mean the same thing as "subnetwork" (or "subnet") in this context?
Thank you!
To fully understand how computer networks work, you need to take a look at OSI model (or in practice - TCP/IP or DoD model. For your question you need to look at first three layers: physical, data link and network.
Physical connection is self explanatory, and represents direct connection via some medium (copper, glass, air).
When a host A tries to send a packet to host B first thing it will do is look at the destination IP address and based on it's own IP configuration determine if host B is in the same subnet as a host A. This is done as Eugen Rieck explained to you already: subnet mask bits are used to mask the bits of the IP address (logical AND operation). Now, we have two cases:
Host A and B are in the same subnet.
Host A and B are not in the same subnet.
You should note that on layer 2, which network adapters use to send and receive frames, there is no IP addresses (which are present on layer 3) but instead the communication between devices is done by using MAC addresses. Because of that, host can directly communicate only with hosts in their subnet (1st scenario). For sending a frame host A needs the MAC address of host B. So host A first looks up the MAC address mapped to the IP address of host B in his ARP table. If he can't find it, it sends broadcast ARP request asking all host on the subnet who has that specific IP. If he gets a response it adds the MAC address of the host he got the reply from and builds a packet with destination MAC address of that host and IP address of that host.
If both hosts are not in the same subnet (2nd scenario) the packet is sent to default gateway which is responsible for finding a route to the destination. The crucial point to make here is that even if the destination MAC address in this case is the MAC address of the router (default gateway), the destination IP address is still the IP address of host B as in the first scenario. As the packet flows from router to router the source and destination MAC addresses will change, as they are locally significant, but the source and destination IP address will stay the same. This is how every layer provides a service (so to speak) to upper layers, and upper layers use it transparently without needing to know what is happening below.
So you have:
1st scenario.
----------------
L2:
Src MAC: host A
Dst MAC: host B
----------------
L3:
Src IP: host A
Dst IP: host B
----------------
2nd scenario:
----------------
L2:
Src MAC: host A
Dst MAC: router
----------------
L3:
Src IP: host A
Dst IP: host B
----------------
To sum it up (the answer #Eugen Rieck already gave you):
Two hosts which are not in the same subnet as in your example (192.168.0.1/24 and 192.168.1.1/24) will not be able to communicate on layer 2, and will require a L3 capable device such as router to act as a default gateway and to route the traffic between two networks (broadcast domains) for layer 3 connectivity.
Yes and no:
Yes: Those two computers can communicate, if there is a (properly set up) router in between and both sides have knowledge of it.
No: Those two computers can not communicate, if simply wired to the same dumb switch.
Rule of thumb: IP & SNM must be identical for all participants to allow direct communication.
You'd need to change the subnet mask to 255.255.254.0, or use a router or layer-3 switch to communicate.
Network generally means the whole network you're referring to, while subnet refers to a specific separate portion of it. However, the terminology is pretty loose.
I have 2 machine. One's IP is 169.254.41.172 and the other is 169.254.72.175. They are both connected to the same router. Why is the 'subnet?' different? I'm referring to the 3rd number between 41 and 72.
These are linklocal addresses, they use 255.255.0.0 as subnet mask, so both addresses are in the same subnet.
These addresses are generated automatically, if you want more control over them you will either need a DHCP server, or configure static IP addresses.
Your router is not acting as a DHCP server it seems.
169.254 is a special range usually for Windows machines when they can't obtain an IP address automatically.
From: http://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/
Occasionally you may encounter a host which has somehow assigned
itself an IP address in the 169.254.0.0/16 range. This is a
particularly common symptom of Windows machines which have been
configured for DHCP but for whatever reason are unable to contact a
DHCP server. When a host fails to dynamically acquire an address, it
can optionally assign itself a link-local IPv4 address in accordance
with RFC 3927. Microsoft's term for this is Automatic Private Internet
Protocol Addressing (APIPA).
These machines are not getting an IP address. The beginning octets of "169.254" identify these addresses as "link-local".
http://en.wikipedia.org/wiki/Link-local_address
For what it's worth, the addresses are not on different subnets as the full link-local definition is 169.254.0.0/16, or a "Class B" subnet. That being said though, there's no way you'll be getting these computers to communicate any time soon. Is the router powered on, are the cables connected and are there uplink lights on the actual RJ45 jacks on both the router and computers? Is DHCP enabled on the router?
Was just wondering why I seem to get different values for my IP address from different sources. If I go to one of the many different 'what's my ip' sites on the net I get a completely different value from when I use ipconfig (on win7)
And no, it's not the subnet mask I'm looking at, these are the actual ipv4 addresses, why would they be resolving to different addresses? Are these 'what's my IP' sites only able to hit an exchange and not determine the IPs of my actual box itself?
If your PC is on a network and not directly connected to your ISP via a modem, there will be at least one router between your machine and the internet. That router will almost certainly be doing NAT (Network Address Translation) and possibly DHCP (Dynamic Host Configuration Protocol) too.
The router will have been assigned an address by the ISP when it established the connection. This address might be static (unchanging) or, more commonly, dynamic (changes periodically as the ISP sees fit). So your 'public' address - the one the router has been assigned and which is visible to the internet - may change from time to time.
Your PC will be connected to the router, and will either have a fixed IP address assigned to it (typically in the 192.168.x.x range) through your OS networking config, or will be given one by the router each time it connects (when you switch on or reboot) via DHCP. In this case, the address will be in whatever range the DHCP service has been told to use (again, the default is likely to be in the 192.168.x.x range).
So your PC has its' own internal address, and your router has its' public address. When you exchange internet traffic, the machine at the other end of the connection will see your public address, not your internal address - the router takes care of forwarding data to the right internal address automatically.
Depending on what IP-checker service you're using, it might display your public address (from the router, which may change if the ISP assigns dynamic addresses) or your internal address (typically when a script runs inside the browser and asks the machine directly).
The answer won't clarify anything, but I'll tell you anyway.
They're both right.
No, your machine doesn't really have two IP addresses, but the IP it shows as depends on who's looking, and from where.
•
What you're seeing is the result of what's called a NAT router. NAT stands for "Network Address Translation". The router manages the IP addresses on a LAN, or Local Area Network, and then translates to the appropriate IP address it was assigned on the external network, usually the internet.
details