On Thu, Aug 09, 2007 at 02:06:39PM +0530, pankaj jain wrote: > It would be very helpful if you could please explain the issues which > we can face if we plumb the same IP address range on multiple interfaces > because I normally assign the ip addresses from the same subnet to all > of my interfaces. Good suggestion - why don't I just try it instead of discussing theory? :-) I tested on an i386 Linux machine with 2 ethernet cards, running ubuntu-6.06 (2.6.15-28-386) # ifconfig eth0 192.168.11.100 # ifconfig eth1 192.168.11.101 # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 I then ran tcpdump on eth0 and eth1 in two different windows, and checked what happened if I sent some pings: # ping 192.168.11.1 # ARPs out of eth0 # ping -I 192.168.11.101 192.168.11.1 # ARPs out of eth0 # ping -I eth1 192.168.11.1 # ARPs out of eth1 OK, this is looking promising. Then I took two brand-new Buffalo WHR-G54S wireless access points, which come factory-set to 192.168.11.1, and plugged one into eth0 and the other into eth1. # ping -c3 -I eth0 192.168.11.1 PING 192.168.11.1 (192.168.11.1) from 192.168.11.100 eth0: 56(84) bytes of data.64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=1.52 ms 64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=0.599 ms 64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=0.597 ms --- 192.168.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 0.597/0.905/1.520/0.435 ms # ping -c3 -I eth1 192.168.11.1 PING 192.168.11.1 (192.168.11.1) from 192.168.11.101 eth1: 56(84) bytes of data.64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=1.66 ms 64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=0.597 ms 64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=0.598 ms --- 192.168.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 0.597/0.951/1.660/0.502 ms # arp -an ? (192.168.11.1) at 00:16:01:AE:37:F6 [ether] on eth1 ? (192.168.11.1) at 00:16:01:AE:3A:1E [ether] on eth0 I can also run pings to both devices concurrently. OK, this is stunning :-) Unfortunately, telnet doesn't have an option to bind to a specific local interface by name. But presumably, an application which bound a TCP socket to an explicit interface would be able to do this (SO_BINDTODEVICE). This suggests that all I need to do is hack something like a SOCKS proxy which binds to an explicit interface when making outbound connections. So, next I built 'proxed' which has the ability to bind to an outbound interface: http://awgn.antifork.org/codes/proxed.c (*) I ran two instances of it: ./proxed -s any:800 -d 192.168.11.1:80 -i eth0 ./proxed -s any:801 -d 192.168.11.1:80 -i eth1 Pointed my web browser at http://localhost:800 and http://localhost:801, and found myself talking two different APs both on the same IP address. Astounding! I can't tell you how much I'm bowled over by this. This just *rocks*. Great kudos to the Linux networking developers is all I can say. Regards, Brian. (*) It might be even simpler if I were to use iptables to DNAT, say, port 800 -> eth0:192.168.11.1:80 port 801 -> eth1:192.168.11.1:80 but this would need to be done with some sort of policy routing to force the packets out of the correct interface. Thinking about NAT, suppose we have two devices on the same IP address, both pointing default route at the same Linux box, and using SNAT to reach the outside world. Is that going to work? 192.168.11.1 192.168.11.254 +----------------+ dev 1 -----------------------------------| eth0 |x.x.x.x 192.168.11.1 192.168.11.254 | Linux eth2 |------------> dev 2 -----------------------------------| eth1 | +----------------+ --- defroute ---> --- source NAT --> That is, does the NAT state contain sufficient information to route the return packets back out of the correct interface? I guess I should get around to testing that too :-) - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
