Only to agree to a communication though. For communication to be understood, they have to agree. The router is still only a bunch of interfaces interpreted by its firmware.. then maybe the ip is more dependent on the host service, transduced by its interfaces, not necessarily by a device called 'router'.. I can connect two puters together- eth0 on puterA and eth0 on puterB, assign diff ips and they would still *attempt* to communicate, and would rely on protocol to do so depending on first on network address, and which machine is initiating protocol that allows the other to understand it.

Example: puterA ip = 10.0.0.1, puterB ip = 10.0.0.2, both machines communicate normally (given); now if puterA ip = 10.0.0.1, and router ip = 192.168.1.1, would they still talk to each other? then comes in the protocol. They do talk, but then agree to not communicate anything - no protocol lock. The actual signal is transferred through the medium, but no handshake. basic. But in the case of the router (assuming its not only switching), it's acting as the host for machines outside the network, and as a switch for what's In the network.

I agree that networks are configured to communicate; that is according to the router that you're deploying the machine, but I don't see how the router by itself justifies it to 'own ip', but instead determines the ip of the device you wish to plug into it to comense communication.. unless you want the router to cohere to the machine's ip you wish to connect the router to... the point is that this determination is objectionable. The thing that actually owns the ip would have to be the protocol that the machine is built to disseminate, not the machine itself, as Spampig expressed. When the documentation says 'system', it's not a reference to a single piece of hardware, but the interaction of many pieces of hardware (and by extension the software that switches it) as a System. Without protocol there is no communication for those interfaces to link to other machines that make up the network- just line voltage.

A single interface by assigning it an ip (whether a router/switches' interface or a puter's interface) is simply allowing it to tune-in to that station's frequency (going back to my radio analogy, not implying that data carrier's frequency is re-tuned or anything) to communicate. The Local Network is simply a by-product of the System's communication, as determined by protocol.

The Interface by itself doesn't know what the System wants to do with the communication, so it doesn't bother; it's left up to the host/client software to determine that and give the interface instructions so its switches its switches in such a way to conform to transmission-and treats packets accordingly. Much like a radio caller would depress the transmitter to initiate voltage through a mic to embed into existing hardware voltage to create signal, the OS/firmware tells the interface that it's ready to send/receive.

If you're having issue with the packets hitting available 'transmitters' that are available globally and you wish to only route relevant packets to a specific interface that can't interpret it, the OS doesn't know which interface to route to.. The System's lo ip is so that the OS's virtual interface can allow it to transmit to/from hardware interface, and to be flexible to keep communication on that protocol for God-knows-what's-to-come software, without changing the data format everywhere it touches. Any software (theoretically) should be able to statically address any piece of hardware, and thus manipulate whatever data passes through it, depending on the code & its logic (of course).

I guess a suggestion would be to use expression instead of statically addressing a single ip which could change dynamically to a communication stream.. don't confuse the lo virtual device as a global variable.

a rough example:
hasty, but you get the point..

again, let me know if I'm off-question or off-base with any of this..

The router is just another 'host' but (usually) multi-homed. You can have a local network, with IP addresses assigned, without any router. A couple of hosts and a hub for example.

ip address belongs to the interface(eth0,eth1).

What about 127.0.0.1 (and the whole 127 class A for that matter)? There is no interface there and none needed to ping it, nc/telnet to it etc. An IP address 'belongs' to the TCP/IP stack running on the device.

I don't know how a specific configuration helps answer a generic question.

But I am dealing with the following setup. There will be 2 separate ethernet switches (red and green). Each machine will have 2 ethernet ports, each connected to a different switch using a red cable in eth0 and a green cable in eth1.

The configuration I am currently trying is to configure each IP address on each machine (each machine has more than one when it does more than one service) ... on both ethernet ports. So, the machine doing one of the DNS roles will have the IP address 172.30.0.13 as one if its addresses. So 172.30.0.13 will be configured on eth0 and on eth1.

Previously I have tried having 172.30.0.13 ONLY configured on eth0. It did answer ARPs for 172.30.0.13 via eth1, so the principle that IP address is owned by the whole system seems to apply here. The problem was, if eth0 was taken down for any reason, then 172.30.0.13 did not work at all on eth1. It was like the IP address was completely taken away. Effectively it was. So it makes sense to have 172.30.0.13 configured on both eth0 and eth1 to make sure it is available somewhere.

I also tried 172.30.0.13 as an alias on the loopback interface ("lo:0", etc).

In the two scenarios of configuring ethernet interfaces with the IP address (either one of them or both of them), the kernel ignores packets arriving on one of the interfaces (usually, but not always, eth1), despite having answered ARP queries on the interface it ignored packets on.

In the scenario of configuring loopback, the kernel answers the ARPs OK on either ethernet port, but ignores the packets coming in.

I'm trying to find out the fundamental basis for configuring IP addresses so I can at least narrow down configurations to just exactly what way is right, so I can focus on that one and try to figure out what the problem is.

You mean the settings in the route tables ... the route entries? Like these?
The issue I'm running into is NOT "which interface will packets go out via". Instead, it's "what happens when a packet comes in interface X" ... asked for X=eth0 and also asked for X=eth1. Why should the answers to the later be different?

I'm interested in just the basic network scenario, without necessarily having any router. I'm concerned about communication within that ethernet segment and how each machine handles it when there are two separate, but identically configured, ethernet interfaces. And I am concerned about how the system (Linux in particular) handles getting a packet addressed to an IP address configured somewhere on that machine (either on one interface, on many interfaces, or on all interfaces).

No!! My simple example was several computers connected to a router.

The router can be configured to have fixed local IP addresses or to use DHCP. Either way, it is the router that controls what IP is used at each interface.

This simple example is directed at the original question of "which side controls the IP addresses". I don't understand routing tables and other nuances, but I think the basic principle stands----the local network environment establishes the IP address used by individual computers.

Kernel documentation disagrees. But if that documentation is correct, then why do we even have the notion of configuring an IP address to an interface.

IWSTM the clear way would be a central table of "IP addresses we will respond to" and a set of rules to narrow the scope of that response where needed (such as "don't respond to packets addressed to 172.29.44.53 if they arrive on eth3, even though that IP address is in the central list of IP addresses").

That makes sense. But why do we bother with configuring IP addresses in the context of an interface (even if it is a virtual one that exists only in the imagination of the TCP/IP stack).

The kernel is conflicted. It documents, and tries to behave as if IP addresses are system-wide. It fails to completely behave that way. And it fails to even if the same IP address is configured on every interface (real or imagined).

I'm looking at this in terms of inside a single machine once the IP address is configured, whether that is done by a static IP address configuration, or it gets the IP address from DHCP, or even some combination. My interest is whether the IP addresses configured anywhere in the machine are fundamentally supposed to operate across the whole machine, or only on the individual interface. People seem to have beliefs that span the full spectrum. Kernel behaviour is somewhere in between, and possibly not stable.

Look Skaperen, one machine can have many interfaces (physical or logical, like eth1, wlan0, lo, ppp0, etc.). They all get IP addresses (static or dynamic-assigned by dhcp), then there must be some program running on the machine that retrieves that data from an interface and writes data back to the interface.

Take apache for example. If you assign 192.168.0.200 to eth1, you can tell apache to listen to 192.169.0.200. You can make apache to listen to all IP addresses that come to this machine if you want.

There is no notion of global IP address for a machine. It's up the software to decide what IP use for their purpose.

No!
The interface asks the router for an available IP address. It is the dhclient that makes the request.
You can choose to not get an address from the router at all. You assign it a static IP address.

This field is getting well plowed....

If the router is set up for DHCP, you cannot arbitrarily assign a static IP to one of the connected computers. If you want to have a static IP, then you have to first configure it in the router.

DHCP: The router assigns the IP
Static IP: The router assigns the IP
In the simple example I cited, the router is in control of what IPs are used on the local network. I am not aware of how it could be otherwise.

Indeed.

My whole perspective on this question wasn't "where do the IP addresses come from" but rather, "how do the configured IP addresses behave" ... once they are configured, from whatever source. In particular, if I configure ONE interface with an IP address, can I use that IP address on another interface. Mostly that appears to be YES. So why is the assignment mechanism interface specific if the IP addresses work on the whole machine, anyway?

I have done a mix, where the machine gets one IP address via DHCP, but also has a static IP address configured. I did this at home using DHCP acquired public IPs and static private IPs paralleled on the same LAN.

I don't know if DHCP can give a machine 2 IP addresses; I never tried that.