I have connected two nics in the same machine with a null modem cable...
I have configured nic 1 to be 156.15.16.1 and nic 2 to be 156.15.16.2
I have adjusted the routes so that nic 1 routes to nic 2 and vice versa...
how come when I ping 156.15.16.1 it does not go out nic 2...
am I missing something?
Regards,
Mike
"This message may contain company proprietary information. If you are not
the intended recipient, any disclosure, copying, distribution or reliance on
the contents of this message is prohibited. If you received this message in
error, please delete and notify me."
On Thursday 18 March 2004 21:20, [email protected] wrote:
> I have connected two nics in the same machine with a null modem cable...
> I have configured nic 1 to be 156.15.16.1 and nic 2 to be 156.15.16.2
> I have adjusted the routes so that nic 1 routes to nic 2 and vice versa...
> how come when I ping 156.15.16.1 it does not go out nic 2...
> am I missing something?
Yes. The ping packet is already at it's destination.
-- robin
[email protected] wrote:
> I have connected two nics in the same machine with a null modem cable...
>
> I have configured nic 1 to be 156.15.16.1 and nic 2 to be 156.15.16.2
>
> I have adjusted the routes so that nic 1 routes to nic 2 and vice versa...
>
> how come when I ping 156.15.16.1 it does not go out nic 2...
>
> am I missing something?
Kernel sees that it have a ping packet destined for 156.15.16.1
Kernel notices it has several NICs available, so it chooses
the one closest to the destination. NIC1 _is_ 156.15.16.1 so it
_is_ the destination.
Kernel figures that the packet is already here, and never sends it
out on the wire.
A crossed cable between two NICS in the same machine is
a testing setup, right?
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.
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. If you really need traffic to go out on a wire, then
you likely need two or more machines for a realistic test too.
Helge Hafting
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.
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...).
Cheers,
Willy
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