Re: Network equipment testing with two NICs

2006-08-02 Thread Matthew R. Dempsky
On Wed, Aug 02, 2006 at 06:04:19PM +0200, Michal Soltys wrote:
> [ reminder about the routing table works ]

Whoops, you're right.  It wasn't anything specific to sk0 and sk1, just 
because of how I assigned IP addresses.

> Small correction to my prev post - messing with route / PF to enforce going 
> over cable in both ways shouldn't probably yield any results here.

The following seems to work:

# ifconfig sk0 192.168.50.1
# ifconfig sk1 192.168.51.1
# route delete 192.168.50
# route delete 192.168.51
# route add 192.168.50 -interface 192.168.51.1
# route add 192.168.51 -interface 192.168.50.1
# ping 192.168.50.1
# ping 192.168.51.1

(I put sk0 and sk1 on separate subnets because route didn't seem to like 
routing packets for a single host via an interface.)

``tcpdump -i lo0'' shows no output during the pings, so it seems like 
the packets are all going over the ethernet cable.

Thanks.



Re: Network equipment testing with two NICs

2006-08-02 Thread Michal Soltys
Anwyay. With "fresh" routing table - let's assume that the only thing there 
is localhost. When you did:


$ ifconfig sk0 192.168.50.1
$ ifconfig sk1 192.168.50.2

The first command would add something like:

192.168/255.255.0.0 link#1   UC sk0

Flag C (check netstat man page) is important here. Now every new connection 
you would normally do to subnet 192.168 will add direct routes to hosts. 
That includes 192.168.50.2, which isn't on sk0. 192.168.50.1 otoh, on sk0, 
will add similar entry, but going through lo0 (as going to itself, through 
sk0, is not the thing to do).


The first of your ping will send requests to "host" .2 going through sk0, 
but the replies from that "host" will go locally through loopback, as per 
routing table. Similary, the second ping command, will send requests through 
lo0, but replies through sk0.


If you changed ifconfig sequence, you would see something similar, but 
traffic to .1 would go through sk1 and to .2 through lo0.


Small correction to my prev post - messing with route / PF to enforce going 
over cable in both ways shouldn't probably yield any results here.




Re: Network equipment testing with two NICs

2006-08-01 Thread Michal Soltys

Matthew R. Dempsky wrote:

On Tue, Aug 01, 2006 at 11:24:17PM +0200, Michal Soltys wrote:

icmp's replies would go through loopback in such case.


Really?  I got the impression from tcpdump that traffic from sk0 to sk1 
(whether ICMP request or reply) always went over the ethernet cable 
while traffic from sk1 to sk0 did not.


I meant the case of the first ping - you requests were sent through cable, 
but not replies . I think I know why you have this "assymetrical" situation, 
but I must check it myself first, before posting further.




The output of ``tcpdump -i sk0'' shows only and all packets that were 
sent through or received from sk0's PHY, right?


Yes.



Re: Network equipment testing with two NICs

2006-08-01 Thread Matthew R. Dempsky
On Tue, Aug 01, 2006 at 11:24:17PM +0200, Michal Soltys wrote:
> icmp's replies would go through loopback in such case.

Really?  I got the impression from tcpdump that traffic from sk0 to sk1 
(whether ICMP request or reply) always went over the ethernet cable 
while traffic from sk1 to sk0 did not.

The output of ``tcpdump -i sk0'' shows only and all packets that were 
sent through or received from sk0's PHY, right?  (And if not, what 
output will?)

> If you wanted to force it to go over the cable, you could use route(8) to
> manually set routing or use pf and set reply-to option on interface, where 
> icmp request is incoming.

I'll give those a try.  (FYI, later I plan to replace ping with iperf or 
something more thorough/intensive, so ICMP-specific fixes will not 
suffice.)

Thanks.



Re: Network equipment testing with two NICs

2006-08-01 Thread Michal Soltys

Matthew R. Dempsky wrote:


Is my guess correct?  If so, is it possible to have OpenBSD route 
traffic both ways across the ethernet cable?


Thanks.



icmp's replies would go through loopback in such case.

If you wanted to force it to go over the cable, you could use route(8) to
manually set routing or use pf and set reply-to option on interface, where 
icmp request is incoming.