comp.os.linux.networking

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

On Tue, 1 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in article
<0154fb3d-f659-4789-8cb2-a4d7b1a2694d@u10g2000prn.googlegroups.com>, Topi wrote:

>I have a Linux box with six ethernet adapters eth[0-5]. eth1 is for
>internet access and works as a dhcp client. The others are for lan
>cameras. I have a dhcp server running on eth{0,2,3,4,5} and it
>delivers addresses in 192.168.1.0/24 to all cameras.

I assume you are doing this because the cameras can not be statically
configured. If you must use one DHCP server to hand out addresses
from the same /24, kick your server in the nuts so that it gives out
specific addresses to specific MAC (hardware) addresses, and set the
routing tables to use _host_ routes (/32) to each camera.

>All camera interfaces have the same static ip 192.168.1.1.

This sentence does not make sense.

>My problem is that I cannot find a way to set up routing tables so
>that traffic would get delivered to the correct interface, because all
>cameras are in the same subnet. Since traffic gets delivered to the
>interface of the first matching routing table entry, a camera in
>another device will never get the ip packets. Let's assume the
>situation is as follows:
>
>eth1: default route via 10.10.10.1
>eth0: connected to camera with ip 192.168.1.2
>eth2: connected to camera with ip 192.168.1.3

[example ~]$ Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
192.168.1.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth3
192.168.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth4
192.168.1.6 0.0.0.0 255.255.255.255 UH 0 0 0 eth5
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 20 lo
0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 eth1
[example ~]$

>Now, if I set up a static route to 192.168.1.0/24 through eth0,
>packets to 192.168.1.3 will be routed to eth0, and the camera in eth2
>will never see them.

You are connecting a single host to the other end of the cable. Why do
you feel the need to use a /24 mask? The other solution would be to
use one interface for all of the 192.168.1.0/24 traffic, and connect
all of the cameras to it.

>I could, of course, solve the problem by giving the cameras static IP
>addresses, but this isn't feasible in my application.

Now you see one of the disadvantages of DHCP. Easy to set up on the
client end - a real bastard to do on the server.

>Another problem that could not be solved with static addresses is with
>multicast traffic. The cameras are detected with UPnP, which builds on
>IP multicasts. The class D address space UPnP uses is 239.0.0.0/8.
>Now, whenever I send a UPnP message, it apparently goes down eth1,
>which is my default route.

You have to set up a route first, but I've never tried to run
multicast on more than one interface.

>One camera starts working if I set up a static route to 239.0.0.0/8
>through its interface, but the others won't, of course. My second
>question is: how do I make sure multicast messages will always get
>delivered to all the interfaces?

I can't help there, and I don't think this problem is addressed in the
Multicast-HOWTO - which is rather dated anyway.

-rw-rw-r-- 1 gferg ldp 73834 Mar 2 2000 Multicast-HOWTO

>I'm sure this is possible because even a simplest 15 EURO switch will do
>the trick. If I connect the cameras to such a box and attach it to my
>eth0, everything is fine. But how do I configure Linux to do the same
>thing with many network adapters?

You are comparing apples and oranges - a switch is working at the OSI
Layer 2 (Datalink) level moving packets based on hardware addresses,
while the computer is working at the Layer 3 (Network) level moving
packets based on IP addresses.

>Any help is appreaciated.

Personal opinion - if you really must use a setup with one camera per
Ethernet interface, and can't use static addresses, fix your DHCP server
to hand out addresses based on MAC Address, and set host routes on the
individual interfaces. This will not solve your multicast problem. If
you can tolerate having all cameras on one interface (your PCI bus is
still likely to be the bottleneck no matter which way you go), that
would be the desired solution.

Old guy