All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Double gateway - Two interfaces to same subnet
@ 2003-02-03 16:50 Oliver Geisler
  2003-02-03 17:43 ` Martin A. Brown
  0 siblings, 1 reply; 2+ messages in thread
From: Oliver Geisler @ 2003-02-03 16:50 UTC (permalink / raw)
  To: lartc

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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [LARTC] Double gateway - Two interfaces to same subnet
  2003-02-03 16:50 [LARTC] Double gateway - Two interfaces to same subnet Oliver Geisler
@ 2003-02-03 17:43 ` Martin A. Brown
  0 siblings, 0 replies; 2+ messages in thread
From: Martin A. Brown @ 2003-02-03 17:43 UTC (permalink / raw)
  To: lartc


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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-02-03 17:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-03 16:50 [LARTC] Double gateway - Two interfaces to same subnet Oliver Geisler
2003-02-03 17:43 ` Martin A. Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.