Hi everybody,
Last week I posted a message concerning how to gain control on routing
aliased IP with the goal to establish two gateways to the localnet. It
became a problem ''two interfaces to same subnet''. Thanks to
Martin for
your hints:
http://mailman.ds9a.nl/pipermail/lartc/2003q1/006930.html
I''ve read the docs mentioned. The arp-flux problem should be solved by
switching /proc/sys/net/ipv4/conf/(all,eth0,eth1)/arp_filter and
../rp_filter to 1. But there remained a problem. only one interface is
ansering the arp requests, even for ip of the other interface.
for more understanding this is my setup:
hamburg:~# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
link/void
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:7d:e2:9e:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.10.9/24 brd 192.168.10.255 scope global eth0
6: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:7d:e2:9e:8f brd ff:ff:ff:ff:ff:ff
inet 192.168.10.8/24 brd 192.168.10.255 scope global eth1
7: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:7d:e2:9e:94 brd ff:ff:ff:ff:ff:ff
inet 62.x.x.90/29 brd 62.x.x.95 scope global eth2
8: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:7d:e2:9e:96 brd ff:ff:ff:ff:ff:ff
inet 62.x.x.90/29 brd 62.x.x.95 scope global eth3
9: eth4: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:7d:dc:95:2f brd ff:ff:ff:ff:ff:ff
inet 192.168.11.8/24 brd 192.168.11.255 scope global eth4
hamburg:~# ip route
62.x.x.89 dev eth2 scope link
62.x.x.88/29 dev eth3 scope link
192.168.11.0/24 dev eth4 proto kernel scope link src 192.168.11.8
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.9
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.8
default via 62.x.x.89 dev eth0
from a host within the localnet an arping to both ips results in:
moskau:~ # arping -c 3 192.168.10.9
ARPING 192.168.10.9 from 192.168.10.1 eth0
Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.665ms
Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.619ms
Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.619ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
moskau:~ # arping -c 3 192.168.10.8
ARPING 192.168.10.8 from 192.168.10.1 eth0
Unicast reply from 192.168.10.8 [00:E0:7D:E2:9E:8D] 0.680ms
Unicast reply from 192.168.10.8 [00:E0:7D:E2:9E:8D] 0.635ms
Unicast reply from 192.168.10.8 [00:E0:7D:E2:9E:8D] 0.631ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
so it seems for both arp-requests the interface eth0 on machine hamburg
is responding.
with the docs from julians site and others I think the arp response is
based on the reverse routing path. both interfaces eth0 and eth1 set a
path to the localnet 192.168.11.0/24. so eth0 responds for both ips
becaue it''s in the first place in the routing table. right?
my next idea was to use julians ''ip arp'' extension to
iproute2, in order
to gain control to the arp mechanism.
I''m running a debian system with kernel 2.4.18 with lodable module
support switched off and a minimal driver support, but all ipnetworking
modules compiled in.
I''ve downloaded
ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz
http://www.linuxvirtualserver.org/~julian/iproute2-iparp-3.diff
after unpacking the tar-ball and moving the directory iproute2 to
iproute2-2.4.7-now-ss020116-try, I patched the source with
hamburg:/usr/src# patch -p0 < iproute2-iparp-3.diff
patching file iproute2-2.4.7-now-ss020116-try/ip/Makefile
patching file iproute2-2.4.7-now-ss020116-try/ip/ip.c
patching file iproute2-2.4.7-now-ss020116-try/ip/ip_common.h
patching file iproute2-2.4.7-now-ss020116-try/ip/iparp.c
patching file iproute2-2.4.7-now-ss020116-try/ip/ipmonitor.c
(option -p1 didn''t work, however)
setting a link /usr/src/linux to my actual kernel source and running
make in the iproute2 source directory ... somethings going terribly wrong.
(...)
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o
iproute.o iproute.c
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o
iprule.o iprule.c
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o
iparp.o iparp.c
iparp.c:68: `ARPA_TABLE_INPUT'' undeclared here (not in a function)
iparp.c:68: initializer element is not constant
iparp.c:68: (near initialization for `arp_tables[0].code'')
iparp.c:69: `ARPA_TABLE_OUTPUT'' undeclared here (not in a function)
iparp.c:69: initializer element is not constant
iparp.c:69: (near initialization for `arp_tables[1].code'')
iparp.c:70: `ARPA_TABLE_FORWARD'' undeclared here (not in a function)
iparp.c:70: initializer element is not constant
iparp.c:70: (near initialization for `arp_tables[2].code'')
iparp.c:113: `ARPA_TABLE_ALL'' undeclared here (not in a function)
iparp.c:113: initializer element is not constant
iparp.c:113: (near initialization for `f.tb'')
iparp.c: In function `print_arprule'':
iparp.c:174: `RTM_NEWARPRULE'' undeclared (first use in this function)
iparp.c:174: (Each undeclared identifier is reported only once
iparp.c:174: for each function it appears in.)
iparp.c:174: `RTM_DELARPRULE'' undeclared (first use in this function)
iparp.c:180: dereferencing pointer to incomplete type
iparp.c:184: dereferencing pointer to incomplete type
iparp.c:187: dereferencing pointer to incomplete type
(...)
iparp.c:861: `ARPA_OIF'' undeclared (first use in this function)
iparp.c:879: `RTM_GETARPRULE'' undeclared (first use in this function)
make[1]: *** [iparp.o] Error 1
make[1]: Leaving directory
`/usr/src/iproute2-2.4.7-now-ss020116-try/ip''
make: *** [all] Error 2
can anybody tell me what''s missing?
... and am I on the right way to solve my initial problem ''two
interfaces on the same subnet?''
thanks in advance,
oli:-)
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Oliver,
The reason that arp_filter is not working for you is as follows (let''s
tell a little story about an inbound ARP requset):
- inbound ARP request received on ethernet interface(s)
- kernel realizes it''s for a locally hosted IP
- it looks up the requestor''s IP in its routing table
- it responds with the link layer address of the interface
through which it would route IP packets to this requestor
I probably mislead you last week by suggesting that arp_filter was a good
solution for your particular need. Although it is one of the solutions
for ARP flux, it won''t work for your case because of the route lookup
incurred by arp_filter.
Sorry for the lack of clarity on this point in my previous post, Oliver.
As for your ip arp compilation problem....did you patch your kernel, as
well?
http://www.linuxvirtualserver.org/~julian/arprules-2.4.18-2.diff
The ip arp userspace utility has to have something in the kernel to talk
to!! :)
: ... and am I on the right way to solve my initial problem ''two
: interfaces on the same subnet?''
Absolutely.
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
lartc@docawk.org
2003-Feb-03 20:23 UTC
Re: Re: Double gateway - Two interfaces to same subnet
Hi Martin, Thanks for your hint. I downloaded the patch this weekend but didn''t apply it. Because of a lack of time I compiled the kerned today. Patching was out of my mind. Anyway. Additionally installing the libdb3-dev package, everything works fine with the compelation of patched iproute2 package. Recompiled the kernel. (with the arprule-patch no change in the config, right?) Ok, the new kernel works fine, and so does the patched iproute2. Now to solve my arp problem ... To prevent eth0 (192.168.10.9) from answering arp-requests to 192.168.10.8 on eth1 and vice versa, I added the following rules: hamburg:~# ip arp add iif eth0 to 192.168.10.8 deny hamburg:~# ip arp add iif eth1 to 192.168.10.9 deny The result is getting no reply for an arping to 192.168.10.8, but to 192.168.10.9 with the proper answer: moskau:~ # arping -c 3 192.168.10.9 ARPING 192.168.10.9 from 192.168.10.1 eth0 Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.671ms Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.646ms Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.660ms Sent 3 probes (1 broadcast(s)) Received 3 response(s) hamburg:~# tcpdump -i eth0 | grep arp 20:44:05.344206 arp who-has 192.168.10.9 (Broadcast) tell moskau 20:44:05.344248 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d 20:44:06.338178 arp who-has 192.168.10.9 (0:e0:7d:e2:9e:8d) tell moskau 20:44:06.338211 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d 20:44:07.338334 arp who-has 192.168.10.9 (0:e0:7d:e2:9e:8d) tell moskau 20:44:07.338366 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d hamburg:~# tcpdump -i eth1 | grep arp 20:44:05.344214 arp who-has 192.168.10.9 (Broadcast) tell moskau moskau:~ # arping -c 3 192.168.10.8 ARPING 192.168.10.8 from 192.168.10.1 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) hamburg:~# tcpdump -i eth0 | grep arp 20:44:16.168356 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:17.220001 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:18.220148 arp who-has 192.168.10.8 (Broadcast) tell moskau hamburg:~# tcpdump -i eth1 | grep arp 20:44:16.168365 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:17.220009 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:18.220155 arp who-has 192.168.10.8 (Broadcast) tell moskau On the gateway (hamburg) there was nothing announced in the kernlog. The arp-requests reach eth1 slightly later than eth0 but that souldn''t influence the reply? Based on Martins little story about an inbound ARP requset, mayby my routing is faulty:> - it responds with the link layer address of the interface > through which it would route IP packets to this requestorSo here is my routing (again): hamburg:~# ip route 62.x.x.89 dev eth2 scope link 62.x.x.88/29 dev eth3 scope link 192.168.11.0/24 dev eth4 proto kernel scope link src 192.168.11.8 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.9 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.8 default via 62.x.x.89 dev eth2 The values of arp_filter and rp_filter are set to 1 for ''all'', ''eth0'' and ''eth1'' I''ve got no further ideas right now. Does anybody? Thanks, oli PS: To answer sabats question why not using two boxes. The main advantage I see in combining both gateways in one box is to keep the dmz with routable IPs accessible for both gateways. Installing another box would force me to loose another IP from my dmz-range. Applying firewall rules to only one box seems to be another advantage. ... And now I hope that I''m that near having solved this problem with great help from you guys .. I dont want to give up. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Martin A. Brown
2003-Feb-03 20:46 UTC
Re: Re: Double gateway - Two interfaces to same subnet
Short reply--gotta run, Don''t forget that the "ip arp" utility works in conjunction with the other ARP management features of the kernel, so you do not want to use arp_filter while using "ip arp" (in this case). Snipped from iparp.txt: The ARP filtering rules are considered only when the ARP code is ready to reply to remote ARP request or to send ARP request. As result, the default action for tables "input" and "forward" depends on other things such as device flags (rp_filter, arp_filter, medium_id, proxy_arp) and the routing rules. If the default action is to ignore the remote ARP request the ARP rules are not analyzed. For table output the default action is always allow. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
lartc@docawk.org
2003-Feb-03 21:48 UTC
Re: Re: Re: Double gateway - Two interfaces to same subnet
Thank you Marin. This was the final tip to hit the goal. Turning off arp_filter and rp_filter did it. Setting a routing table for iif eth1 with default gw to the ADSL connection works fine. The rest of the packets coming in the other interfaces is leaving to gw T3 by default route in the main table. Thanks, again. oli:-) _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/