Re: 2 nics in the same machine...

[Helge Hafting <helgehaf@aitel.hist.no>]

On Fri, Mar 19, 2004 at 11:36:56PM +0100, Willy Tarreau wrote:
> Hi,
> 
> On Fri, Mar 19, 2004 at 10:16:36AM +0100, Helge Hafting wrote:
>  
> > If you want to test NICs (or cables & hubs) do this:
> > 
> > 1. Run a packet sniffer on the "listening" NIC.  Run it in
> >   promiscuous mode so it'll even sniff packets not meant for it.
> > 
> > 2. Set a default route to the "sending" NIC.  Or at least a route
> >   to some network that isn't on your machine.
> > 
> > 3. Ping the remote network.  You will not get an answer, but:
> >   The packet will be sent through the "sending" NIC, 
> >   and sniffed by the "listening" NIC.  So you'll verify that
> >   NICs and cable works.  Optionally make a script that reverses
> >   the roles of the two NICs if you want to test both ways.
> 
> Nearly right. He will need to enter static ARP entries for this to
> work because his host will try to resolve the gateway's address first,
> so nothing except ARP will go out.
> 
I didn't think of that.  Of course, capturing an ARP broadcast is probably
good enough for testing cables.  One might want better than that
for testing the NIC driver though.

> DNAT out + SNAT in may be OK. I've used this setup in the past, but didn't
> not go on because of performance problems. Now, Julian Anastasov has written
> a wonderful patch named "send-to-self" which does the trick automagically.
> You can get it on his site ( http://www.ssi.bg/~ja/ IIRC ).
> 
> > If, on the other hand, you're testing apps/protocols, don't worry that 
> > the traffic don't hit the wire.  A test utilizing internal loopback
> > is just as good.
> 
> Right. Except that in some very weird cases, the higher MTU on loopback may
> affect the app's behaviour (less packets, or bigger reads at once, etc...).

ifconfig lo mtu 1500  :-)

Helge Hafting