Re: 2 NICs and the source ip address
Hi,
> It depends on your routing configuration where the packets go to.
> Could you send the output of
ok. Let's be specific now. This is the setup:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/ \
( LAN (192.168.3.0/24) )
\ /
------------------------------------
| |
| |
------------ ------------
| eth1 | | eth1 |
| | | |
host A | | | | host B
| | dedicated line | |
| eth0|-------------------------|eth0 |
------------ 10.0.0.1 10.0.0.2 ------------
(please note that I interchanged eth0 and eth1 when I copied this
picture from my previous posting in order to match with the reality)
eth1 (host A) has ip address 192.168.3.23
eth1 (host B) has ip address 192.168.3.24
The closest approximation to the desired setup that I can achieve
is to route *all* traffic from host A to host B (and vice verca)
via the dedicated line, so here is my /etc/network/interfaces
from host A (all configs are symmetric in A and B)
/etc/network/interfaces:
....
auto eth1
iface eth1 inet static
address 192.168.3.23
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
up route add default gw 192.168.3.250 dev eth1
down route del default gw 192.168.3.250 dev eth1
auto eth0
iface eth0 inet static
address 10.0.0.1
pointopoint 10.0.0.2
broadcast 10.0.0.1
netmask 255.255.255.255
up route add -host 192.168.3.24 gw 10.0.0.2 dev eth0
down route del -host 192.168.3.24 gw 10.0.0.2 dev eth0
> ip route show -- or -- route -n
> ifconfig -a
host A# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.3.24 10.0.0.2 255.255.255.255 UGH 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.3.250 0.0.0.0 UG 0 0 0 eth1
host A# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:07:E9:06:30:3B
inet addr:10.0.0.1 Bcast:10.0.0.1 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:202 errors:0 dropped:0 overruns:0 frame:0
TX packets:355 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:15758 (15.3 KiB) TX bytes:26492 (25.8 KiB)
Interrupt:31 Base address:0x2000 Memory:fe6e0000-fe700000
eth1 Link encap:Ethernet HWaddr 00:07:E9:06:30:3A
inet addr:192.168.3.23 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3170 errors:0 dropped:0 overruns:0 frame:0
TX packets:1431 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:421006 (411.1 KiB) TX bytes:148710 (145.2 KiB)
Interrupt:30 Base address:0x2040 Memory:fe6c0000-fe6e0000
....
> Depending on your configuration, they should. However, it depends on
> your host configuration, i.e. where packets are sent from. Usually,
> your host-name is resolved for the IP address (IIRC). Thus, the node
> itself is identified by one IP address only. Can you send the tcpdump
> -i eth1 for a couple of simple pings?
(pinging to 192.168.3.24)
host A# tcpdump -i eth0
tcpdump: listening on eth0
17:08:32.051811 arp who-has 10.0.0.2 tell 10.0.0.1
17:08:32.051967 arp reply 10.0.0.2 is-at 0:7:e9:6:2c:fb
17:08:32.051980 10.0.0.1 > 192.168.3.24: icmp: echo request (DF)
17:08:32.052216 192.168.3.24 > 10.0.0.1: icmp: echo reply
17:08:33.044191 10.0.0.1 > 192.168.3.24: icmp: echo request (DF)
17:08:33.044356 192.168.3.24 > 10.0.0.1: icmp: echo reply
17:08:34.044241 10.0.0.1 > 192.168.3.24: icmp: echo request (DF)
17:08:34.044491 192.168.3.24 > 10.0.0.1: icmp: echo reply
(pinging to 10.0.0.2)
pcrz355:~# tcpdump -i eth0
tcpdump: listening on eth0
17:10:58.413148 10.0.0.1 > 10.0.0.2: icmp: echo request (DF)
17:10:58.413426 10.0.0.2 > 10.0.0.1: icmp: echo reply
17:10:59.412818 10.0.0.1 > 10.0.0.2: icmp: echo request (DF)
17:10:59.413062 10.0.0.2 > 10.0.0.1: icmp: echo reply
17:11:00.412872 10.0.0.1 > 10.0.0.2: icmp: echo request (DF)
17:11:00.413073 10.0.0.2 > 10.0.0.1: icmp: echo reply
Now my intention is to dedicate the crossover cable between
host A and host B to a specific service, say replicating
a block device between host A and host B. All "normal" traffic
between host A and host B should do through the LAN. (More
generally, one could dedicate an "internal" network 10.0.0.0
to a set of hosts A,B,C,D,... for NFS traffic). Therefore I
discard the route from 192.168.3.23 to 192.168.3.24 via
10.0.0.1 and vice verca:
host A# route del -host 192.168.3.24 gw 10.0.0.2 dev eth0
host A# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.3.250 0.0.0.0 UG 0 0 0 eth1
(pinging to 192.168.3.24)
host A# tcpdump -i eth0
-> nothing, all packages are routed via eth1)
(pinging to 10.0.0.2)
host A# tcpdump -i eth0
17:27:57.219934 arp who-has 10.0.0.2 tell 10.0.0.1
17:27:57.220200 arp reply 10.0.0.2 is-at 0:7:e9:6:2c:fb
17:27:57.220213 10.0.0.1 > 10.0.0.2: icmp: echo request (DF)
17:27:57.220449 10.0.0.2 > 10.0.0.1: icmp: echo reply
17:27:58.212726 10.0.0.1 > 10.0.0.2: icmp: echo request (DF)
17:27:58.212962 10.0.0.2 > 10.0.0.1: icmp: echo reply
17:28:02.215872 arp who-has 10.0.0.1 tell 10.0.0.2
-> just fine
But opening a tcp connection from host A to 10.0.0.2 fails,
The src ip address of the initiating syn package is set to
192.168.3.23, so the answer from host B is probably routed
through the eth1, actually the tcp connection fails)
(telnet 10.0.0.2)
host A# tcpdump -i eth0
17:33:56.676307 192.168.3.23.32784 > 10.0.0.2.telnet: S 83211668:83211668(0)
win 5840 <mss 1460,sackOK,timestamp 376358 0,nop,wscale 0> (DF) [tos 0x10]
17:33:59.673463 192.168.3.23.32784 > 10.0.0.2.telnet: S 83211668:83211668(0)
win 5840 <mss 1460,sackOK,timestamp 376658 0,nop,wscale 0> (DF) [tos 0x10]
17:34:01.673574 arp who-has 10.0.0.2 tell 10.0.0.1
17:34:01.673759 arp reply 10.0.0.2 is-at 0:7:e9:6:2c:fb
17:34:05.673805 192.168.3.23.32784 > 10.0.0.2.telnet: S 83211668:83211668(0)
win 5840 <mss 1460,sackOK,timestamp 377258 0,nop,wscale 0> (DF) [tos 0x10]
....
I guess that if the src ip address of the packages would be
set to 10.0.0.1, then I could telnet to 10.0.0.2 via eth0
(or more generally: open a tcp connection via the dedicated line)
because:
* telnetting from host A to 192.168.3.24 works fine.
* Before I deleted the route via eth0, telnetting to 10.0.0.2
also worked fine.
Thanks for any hint!
Cheers, Thomas
(Hey, why did the ICMP echo request package get src address
10.0.0.1 but the tcp syn package got 192.168.3.23 ???)
Reply to: