>> So, as far as I can tell from the respected gurus' responses, this behavior >> is >> expected, works as designed, and won't be fixed. Correct?
> No, I think that goes a bit too far. It's just software. It can be changed. > ;-} Well, I exagerrated a bit. I hope sometime in the realistic future these more common scenarios are ironed out, and that yelling "it is indeed a real-life problem" helps speed up the process ;) > A "connected network" is a network on which we have an interface. > Yes, for interface types that require a next hop address (i.e., > non-point-to-point), the _destination_ address for the next hop must > be on the same subnet as the configured interface, but that says > nothing about the source address. Now I'm not quite understanding. Which meaning of terms such as "network", "subnet", "address" and "configured interface" do you imply? L2 or L3? Or a mixture of them all? ;) My understanding is that in order for L2 ethernet frames with payload to go between two hosts, their L3 IP "addresses" must be in the same L3 "subnet" as defined by network address bits and the mask size. Moreover, these L3 IP addresses should be configured on the (L1/L2 = physical/MAC) interfaces which are connected to the same ethernet collision domain (VLAN in our case). When this is the case of two servers talking to each other within a subnet, there is no need for a router. My expectation was that the same rules should automagically apply for a server talking to a router in order to pass a packet to a remote destination (in another, unconnected, subnet). This is where my knowledge didn't match reality ;) All in all, there are more variables in this equation to me, than the current implementation considers: 1) destination IP address - it's currently the only criterion for picking a gateway IP address from the routing table (after considering metrics or balancing for equivalent routes); 2) gateway address - it is produced after a lookup in the routing table by the destination address, completely disregarding the source address value; 3) source address - I thought it should have been in the same IP subnet and/or ethernet segment as the gateway (reverse actually: gateway should have been in the same subnet as the source address). But it's not considered at all. After a gateway is picked, its MAC address is evaluated and used to craft an L2 ethernet frame going out of the physical interface (hopefully matching the same ethernet segment as the selected gateway). This process pays no attention to whatever src/dst IP addresses are in the packet inside the ethernet frame. > If this weren't so, then routing itself wouldn't work. Once you get > one hop away, you're no longer transmitting a packet whose source IP > address matches the outbound interface -- and that's exactly what's > expected. Yes - but only for an L3 router device ;) Anyway, for now the problem is solved. My understanding of Solaris is updated. I don't consider the current implementation perfect (it's even counter-intuitive!) but the workaround seems acceptable. I hope "just changing the software" in this algorithm would improve the situation. I.e. consider the source address to boost priority of a certain gateway (of several equivalent ones). And use these "boosted" gateways unless there's indeed a link failure detected. Something like that... ;-} //Jim -- This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
