two interfaces one subnet

Mon May 11 22:01:29 UTC 2009

On May 11, 2009, at 5:40 PM, Ben Scott wrote:
> On Mon, May 11, 2009 at 5:28 PM, Hector Herrera <hectorherrera at gmail.com 
> > wrote:
>> On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber
>> <ddevereauxweber at gmail.com> wrote:
>>> ... both> interfaces are on the same subnet, the OS sees the same  
>>> router (gateway)
>>> address on both interfaces, and the results are sub-optimal ...  
>>> around 50%
>>> packet loss.
>>
>> packet loss is probably due to the network switch having to re-learn
>> the location of the MAC address constantly as it sees packets on two
>> or more ports with the same MAC address (think STP loops).
>
>  My understand of the scenario is: Two physical interfaces, each with
> a unique IP address, in the same Ethernet broadcast domain, on the
> same IP (sub)network.
>
>  If that's the case, the MAC address won't change.  The cards stay
> put.  So a layer two switch will be none the wiser.
>
>  The reason this doesn't work (for most implementations) is that most
> IP routers look only at the destination IP address, and keep no state.
> (Here, I'm using "router" to include the routing engine built-in to
> any full IP implementation, not just dedicated equipment from Cisco,
> et. al.)
>
>  So we have a host with IP addresses A and B on the same subnet.  A
> packet comes in from some other host X.  The application software does
> whatever it does, and sends a response.  The router looks at the
> destination IP address X, and sees that it has two routes, A and B.
>
>  Depending on implementation, the router may send everything out the
> first interface it finds in the routing table (e.g., use A and ignore
> B), or round-robin between the two, or who-knows-what.  Either way, if
> the packet *from* X was addressed *to* B but the response comes back
> from *A*, then host X is going to drop the packet as
> invalid/irrelevant/etc.

You are assuming facts not in evidence.  It doesn't matter which  
physical interface transmits the packet.  For instance, if I ping a  
router's loopback interface, there is nothing stopping the router from  
making the loopback the source IP address of the return packet even  
though the (virtual) loopback interface _obviously_ did not physically  
transmit the packet.

Another example: Imagine a web server with two uplinks in _different_  
subnets running Quagga.  Now assume the web server gets an HTTP  
request and the route back to the requesting host changes before all  
the packets are returned.  Does the download break?  Sure, if you use  
an implementation too broken for words.  If not, things work just fine.

Could everyone please stop coming up with "if people are stupid and  
break things, things don't work" examples.  We all agree on that.

Back in reality land, things that broken tend not to be used.  (And  
please no jokes about cisco or microsoft or whatever.)

-- 
TTFN,
patrick

>  With Linux, at least, you *can* use the routing policy database to
> configure the kernel router to pay attention to more than just the
> destination IP address.  For example, you can have it look at the
> source IP address (A or B), and route out the appropriate interface.
> However, IIRC, this only works if the application software binds to
> individual network interfaces.  If the app software just listens for
> anything (0.0.0.0), then the kernel gets to pick the source IP address
> for any response.
>
>  I can post examples with gory details from our firewall, if anyone  
> needs them.
>
> -- Ben
>