delicate DHCP problem with bridged eth devices

Hi all,

In our student home, we got a new connection that offered us 128 public
IPs, for a maximum of 63 people living in here, that's a quite nice
thing to have.
It gave me some headaches though, I solved most cases, but I still have
a DHCP problem. First I gotta tell you the delicate situation:

[For better reading, I'll substitute the constant xx.xx.xx part of the
addresses to X (so xx.xx.xx.0 becomes X.0) in the following writing.]

Our provider has a gateway installed at the X.1 address of our subnet,
which is set to the full netmask of this subnet and we can't reconfigure
that.
We want all of our packets to run through our Linux server to be able to
filter as well as monitor the traffic of our clients, eventually even
shape their bandwidth or similar things.
The clients themselves are wired to three 24-port switches, that's why
we have 4 network cards in the server, one leading to the provider, the
other three to our switches / clients.
I've set up transparent bridging, and went through some loops with
ebtables and routing so that all does work now (at least it's supposed
to, it's tested to be working but the clients don't get their IPs
assigned like that yet):

subnet xx.xx.xx.0/25 [X.0/25] (128 addresses, netmask 255.255.255.128)

|---------| X.1 X.2 |------------------|
---| gateway |------------| eth0 --- eth1 |--- clients (X.34-X.56)
|---------| | | | |
| br0 ---+-- eth2 |--- clients (X.66-X.88)
| X.3 | |
| --- eth3 |--- clients (X.98-X.120)
|------------------|
Linux server

Don't be disturbed by br0 and eth0 having two IPs on the same subnet, I
was able to solve the routing problems with that...

We want to serve the clients' IP addresses via DHCP, as we do now, but
here's where I'm running into problems.
Wait a minute, I'm telling "as we do now" but I didn't tell what we do
now...
Well, eth1-eth3 do have 192.168.xx.xx addresses with seperated subnets
assigned, which do get NATed to X.2, and DHCP assigns IPs to the clients
on those subnets. That does work well, and has done so for a while.
If I manually assign a public IP to a client, it does work as well.

But here's the problem:
How do I tell DHCP to assign an IP on the bridged subnet?

I have 4 subnet declarations in dhcpd.conf:

subnet xx.xx.xx.0 netmask 255.255.255.128 {
server-identifier xx.xx.xx.2;
option routers xx.xx.xx.1;
}

subnet 192.168.23.32 netmask 255.255.255.224 {
server-identifier 192.168.23.33;
option routers 192.168.23.33;
}

subnet 192.168.23.64 netmask 255.255.255.224 {
server-identifier 192.168.23.65;
option routers 192.168.23.65;
}

subnet 192.168.23.96 netmask 255.255.255.224 {
server-identifier 192.168.23.97;
option routers 192.168.23.97 ;
}

Those are followed by a bunch of host blocks like:
host test {
hardware ethernet zz:zz:zz:zz:zz:zz;
fixed-address 192.168.23.85;
}
[same for addresses on the bridged public subnet]

The first problem is seen in syslog when starting dhcpd:

dhcpd: Multiple interfaces match the same subnet: eth0 br0
dhcpd: Multiple interfaces match the same shared network: eth0 br0
dhcpd: Listening on Socket/eth3/192.168.23.96/27
dhcpd: Sending on Socket/eth3/192.168.23.96/27
dhcpd: Listening on Socket/eth2/192.168.23.64/27
dhcpd: Sending on Socket/eth2/192.168.23.64/27
dhcpd: Listening on Socket/eth1/192.168.23.32/27
dhcpd: Sending on Socket/eth1/192.168.23.32/27
dhcpd: Listening on Socket/br0/xx.xx.xx.0/25
dhcpd: Sending on Socket/br0/xx.xx.xx.0/25

Then, for 192.168.23.xx addresses, everything works, see e.g.

dhcpd: DHCPDISCOVER from zz:zz:zz:zz:zz:zz via eth2
dhcpd: DHCPOFFER on 192.168.23.85 to zz:zz:zz:zz:zz:zz via eth2
dhcpd: DHCPREQUEST for 192.168.23.85 (192.168.23.65) from
zz:zz:zz:zz:zz:zz via eth2
dhcpd: DHCPACK on 192.168.23.85 to zz:zz:zz:zz:zz:zz via eth2

OTOH, dhcpd thinks it shouldn't hand out the public addresses because it
fails to know the bridged subnet does apply to the eth1-eth3 subnets:

dhcpd: DHCPDISCOVER from 00:50:da:74:7f:79 via eth1: network
192.168.23.32/27: no free leases
last message repeated 2 times

How can I get dhcpd to offer the public addresses on eth1-eth3?

[The Linux system is SuSE 9.1 with a self-compiled Linux-2.6.8.1, btw.]


Thanks in advance for your help,

Robert Kaiser

> How can I get dhcpd to offer the public addresses on eth1-eth3?
>
> [The Linux system is SuSE 9.1 with a self-compiled Linux-2.6.8.1, btw.]

Looks like noone here can answer that.
Can anyone here tell me where I could get an answer?

Robert Kaiser

KaiRo - Robert Kaiser <(E-Mail Removed)> wrote:
> > How can I get dhcpd to offer the public addresses on eth1-eth3?
> >
> > [The Linux system is SuSE 9.1 with a self-compiled Linux-2.6.8.1, btw.]
>
> Looks like noone here can answer that.
> Can anyone here tell me where I could get an answer?

To what question? dhcp always "offers addresses" (whatever you mean by
that) on the interfaces it is run on. Bridging (as I see you mention
in your subject) doesn't affect that in any way that I can immediately
think of. I don't know if the bootp packets would be bridged or not,
but they might be! If they are, do you want them to be? I'm not sure I
would.

Peter

>>>How can I get dhcpd to offer the public addresses on eth1-eth3?
>>>
>>>[The Linux system is SuSE 9.1 with a self-compiled Linux-2.6.8.1, btw.]
>>
>>Looks like noone here can answer that.
>>Can anyone here tell me where I could get an answer?
>
> To what question? dhcp always "offers addresses" (whatever you mean by
> that) on the interfaces it is run on. Bridging (as I see you mention
> in your subject) doesn't affect that in any way that I can immediately
> think of. I don't know if the bootp packets would be bridged or not,
> but they might be! If they are, do you want them to be? I'm not sure I
> would.

The whole point is, if you read my original question (or at least the
end of it), that it does NOT send a DHCPOFFER as it recieves the
DHCPDISCOVER on the eth1 device and thinks there is no IP address it can
offer to the client on that device, as the fixed-address for this MAC
does sit on the subnet of the bridge device and dhcpd doesn't know that
it can DHCPOFFER it to a client on the eth1 device.

I hope that sentence is understandable...

Robert Kaiser

KaiRo - Robert Kaiser wrote:
> Hi all,
>
> In our student home, we got a new connection that offered us 128 public
> IPs, for a maximum of 63 people living in here, that's a quite nice
> thing to have.
> It gave me some headaches though, I solved most cases, but I still have
> a DHCP problem. First I gotta tell you the delicate situation:
>
> [For better reading, I'll substitute the constant xx.xx.xx part of the
> addresses to X (so xx.xx.xx.0 becomes X.0) in the following writing.]
>
> Our provider has a gateway installed at the X.1 address of our subnet,
> which is set to the full netmask of this subnet and we can't reconfigure
> that.
> We want all of our packets to run through our Linux server to be able to
> filter as well as monitor the traffic of our clients, eventually even
> shape their bandwidth or similar things.
> The clients themselves are wired to three 24-port switches, that's why
> we have 4 network cards in the server, one leading to the provider, the
> other three to our switches / clients.
> I've set up transparent bridging, and went through some loops with
> ebtables and routing so that all does work now (at least it's supposed
> to, it's tested to be working but the clients don't get their IPs
> assigned like that yet):
>
> subnet xx.xx.xx.0/25 [X.0/25] (128 addresses, netmask 255.255.255.128)
>
> |---------| X.1 X.2 |------------------|
> ---| gateway |------------| eth0 --- eth1 |--- clients (X.34-X.56)
> |---------| | | | |
> | br0 ---+-- eth2 |--- clients (X.66-X.88)
> | X.3 | |
> | --- eth3 |--- clients (X.98-X.120)
> |------------------|
> Linux server

if I understand well your problem
i think you could see about shared-network option in dhpcd.conf


--
Weill Philippe - Administrateur Systeme et Reseaux
CNRS Service Aeronomie - Universite Pierre et Marie Curie -
Tour 45/46 3e Etage B302 - 4 Place Jussieu - 75252 Paris Cedex 05 - FRANCE
Email(E-Mail Removed) | tel:+33 0144274759 Fax:+33 0144273776

KaiRo - Robert Kaiser wrote:

> subnet xx.xx.xx.0/25 [X.0/25] (128 addresses, netmask 255.255.255.128)
>
> |---------| X.1 X.2 |------------------|
> ---| gateway |------------| eth0 --- eth1 |--- clients (X.34-X.56)
> |---------| | | | |
> | br0 ---+-- eth2 |--- clients (X.66-X.88)
> | X.3 | |
> | --- eth3 |--- clients (X.98-X.120)
> |------------------|
> Linux server
>
> How do I tell DHCP to assign an IP on the bridged subnet?
>
> I have 4 subnet declarations in dhcpd.conf:
>
if you don't do dynamic dhcp on more than one subnet
or if all your dhcp entries are mac-locked you could put this in your dhcpd.conf
# Shared network declaration is used to group subnets which share the same
# physical network together. The name is specified so that the shared
# network can be referred to in log messages - it serves no other function.



shared-network Mystuff {
subnet xx.xx.xx.0 netmask 255.255.255.128 {
server-identifier xx.xx.xx.2;
option routers xx.xx.xx.1;
}

subnet 192.168.23.32 netmask 255.255.255.224 {
server-identifier 192.168.23.33;
option routers 192.168.23.33;
}

subnet 192.168.23.64 netmask 255.255.255.224 {
server-identifier 192.168.23.65;
option routers 192.168.23.65;
}

subnet 192.168.23.96 netmask 255.255.255.224 {
server-identifier 192.168.23.97;> option routers 192.168.23.97 ;
}
}


Hope this help

>


> Those are followed by a bunch of host blocks like:
> host test {
> hardware ethernet zz:zz:zz:zz:zz:zz;
> fixed-address 192.168.23.85;
> }
> [same for addresses on the bridged public subnet]
>
> The first problem is seen in syslog when starting dhcpd:
>
> dhcpd: Multiple interfaces match the same subnet: eth0 br0
> dhcpd: Multiple interfaces match the same shared network: eth0 br0
> dhcpd: Listening on Socket/eth3/192.168.23.96/27
> dhcpd: Sending on Socket/eth3/192.168.23.96/27
> dhcpd: Listening on Socket/eth2/192.168.23.64/27
> dhcpd: Sending on Socket/eth2/192.168.23.64/27
> dhcpd: Listening on Socket/eth1/192.168.23.32/27
> dhcpd: Sending on Socket/eth1/192.168.23.32/27
> dhcpd: Listening on Socket/br0/xx.xx.xx.0/25
> dhcpd: Sending on Socket/br0/xx.xx.xx.0/25
>
> Then, for 192.168.23.xx addresses, everything works, see e.g.
>
> dhcpd: DHCPDISCOVER from zz:zz:zz:zz:zz:zz via eth2
> dhcpd: DHCPOFFER on 192.168.23.85 to zz:zz:zz:zz:zz:zz via eth2
> dhcpd: DHCPREQUEST for 192.168.23.85 (192.168.23.65) from
> zz:zz:zz:zz:zz:zz via eth2
> dhcpd: DHCPACK on 192.168.23.85 to zz:zz:zz:zz:zz:zz via eth2
>
> OTOH, dhcpd thinks it shouldn't hand out the public addresses because it
> fails to know the bridged subnet does apply to the eth1-eth3 subnets:
>
> dhcpd: DHCPDISCOVER from 00:50:da:74:7f:79 via eth1: network
> 192.168.23.32/27: no free leases
> last message repeated 2 times
>
> How can I get dhcpd to offer the public addresses on eth1-eth3?
>
> [The Linux system is SuSE 9.1 with a self-compiled Linux-2.6.8.1, btw.]
>
>
> Thanks in advance for your help,
>
> Robert Kaiser

--
Weill Philippe - Administrateur Systeme et Reseaux
CNRS Service Aeronomie - Universite Pierre et Marie Curie -
Tour 45/46 3e Etage B302 - 4 Place Jussieu - 75252 Paris Cedex 05 - FRANCE
Email(E-Mail Removed) | tel:+33 0144274759 Fax:+33 0144273776

> if you don't do dynamic dhcp on more than one subnet
> or if all your dhcp entries are mac-locked you could put this in your
> dhcpd.conf
> # Shared network declaration is used to group subnets which share the same
> # physical network together. The name is specified so that the shared
> # network can be referred to in log messages - it serves no other function.
>
> shared-network Mystuff {
> subnet xx.xx.xx.0 netmask 255.255.255.128 {
> server-identifier xx.xx.xx.2;
> option routers xx.xx.xx.1;
> }
>
> subnet 192.168.23.32 netmask 255.255.255.224 {
> server-identifier 192.168.23.33;
> option routers 192.168.23.33;
> }
>
> subnet 192.168.23.64 netmask 255.255.255.224 {
> server-identifier 192.168.23.65;
> option routers 192.168.23.65;
> }
>
> subnet 192.168.23.96 netmask 255.255.255.224 {
> server-identifier 192.168.23.97;> option routers 192.168.23.97 ;
> }
> }

Man, if I had only tried that...
All the time that solution was sitting right in front of me and I didn't
see it because it sounded just too simple.
Perhaps the way up to that point was too complex so that I just couldn't
believe in such a simple solution.

Anyways, it seems to work. Thanks for your help, it made me see the
solution

Greetings,

Robert Kaiser