Bridge and dhcpd problem

I have two networks set up which I've connected with an linux ethernet
bridge (using bridge-utils). I have almost the same thing working in
another location and it is great. It allows our customers who need
public IP's to utilize them behind our private network. Here is the
setup:

192.168.5.0/24 network <==> eth1 of bridge / eth0 of bridge <==>
172.0.0.1/24 (actually public IP address network)

Inside the 192.168.5.0 network there is a DHCP server based on
OpenBSD, but I cannot touch the settings on this box. When the bridge
is turned on and some system requests a dhcp address, I get the
following error message over and over: dhcpd Abandoning IP address:
192.168.5.XX declined (where XX is is in the DHCP range, each time a
new one out of the pool). I have to flush these leases out of my DHCP
leases list. This happens until I shut off the bridge (with "ifconfig
bridge-name down"). The bridge has stp turned on.

I haven't even had the chance to set up my ebtables and iptables rules
until I can get around this issue. Is there something that I am
missing?

Please no suggestions to not use RFC 1918 networks, that is not an
options because my bosses tell me so.

support@isotech-inc.com wrote:
> I have two networks set up which I've connected with an linux ethernet
> bridge (using bridge-utils). I have almost the same thing working in
> another location and it is great. It allows our customers who need
> public IP's to utilize them behind our private network. Here is the
> setup:
>
> 192.168.5.0/24 network <==> eth1 of bridge / eth0 of bridge <==>
> 172.0.0.1/24 (actually public IP address network)

Well, systems connected to your eth1 need to have IP addresses in the
range 172.0.0.1/24 and definitely not in the range 192.168.5.0/24
because your bridge won't route them through its eth0.

Why not set up another DHCP server on the eth0 side, like on your
bridge, allocate addresses in another public range (like 192.168.6.0/24
or 172.16.1.0/24) and add the range to the routing table of your bridge?

Robert

>
> Inside the 192.168.5.0 network there is a DHCP server based on
> OpenBSD, but I cannot touch the settings on this box. When the bridge
> is turned on and some system requests a dhcp address, I get the
> following error message over and over: dhcpd Abandoning IP address:
> 192.168.5.XX declined (where XX is is in the DHCP range, each time a
> new one out of the pool). I have to flush these leases out of my DHCP
> leases list. This happens until I shut off the bridge (with "ifconfig
> bridge-name down"). The bridge has stp turned on.
>
> I haven't even had the chance to set up my ebtables and iptables rules
> until I can get around this issue. Is there something that I am
> missing?
>
> Please no suggestions to not use RFC 1918 networks, that is not an
> options because my bosses tell me so.
>

On Jul 13, 2:51 pm, Robert Harris <robert.f.har...@blueyonder.co.uk>
wrote:

> Well, systems connected to your eth1 need to have IP addresses in the
> range 172.0.0.1/24 and definitely not in the range 192.168.5.0/24
> because your bridge won't route them through its eth0.

Huh?! Of course his bridge won't route, it's a *bridge*. It will,
however, bridge them to its eth0. So your suggestion makes no sense.

> Why not set up another DHCP server on the eth0 side, like on your
> bridge, allocate addresses in another public range (like 192.168.6.0/24
> or 172.16.1.0/24) and add the range to the routing table of your bridge?

Because the eth0 side and the eth1 side are *bridged* together. Why
would he want to add things to the routing table of his bridge since
it's bridging the two networks together, not routing them?

DS

On Jul 13, 2:00 pm, supp...@isotech-inc.com wrote:

> I have two networks set up which I've connected with an linux ethernet
> bridge (using bridge-utils). I have almost the same thing working in
> another location and it is great. It allows our customers who need
> public IP's to utilize them behind our private network. Here is the
> setup:
>
> 192.168.5.0/24 network <==> eth1 of bridge / eth0 of bridge <==>
> 172.0.0.1/24 (actually public IP address network)

This is a very advanced configuration that requires extensive
knowledge to properly handle.

> Inside the 192.168.5.0 network there is a DHCP server based on
> OpenBSD, but I cannot touch the settings on this box. When the bridge
> is turned on and some system requests a dhcp address, I get the
> following error message over and over: dhcpd Abandoning IP address:
> 192.168.5.XX declined (where XX is is in the DHCP range, each time a
> new one out of the pool). I have to flush these leases out of my DHCP
> leases list. This happens until I shut off the bridge (with "ifconfig
> bridge-name down"). The bridge has stp turned on.
>
> I haven't even had the chance to set up my ebtables and iptables rules
> until I can get around this issue. Is there something that I am
> missing?
>
> Please no suggestions to not use RFC 1918 networks, that is not an
> options because my bosses tell me so.

What's most likely happening is that the DHCP server is assigning the
host an address, the host is verifying that the address is not in use,
and concluding that it is in use. Something is reply to an ARP query
for the IP addresses in the DHCP range inside the same broadcast
domain as the DHCP server and its clients. This is a no-no.

This sounds like proxy-ARP gone wild. Since you're bridging, there is
no reason to use proxy-ARP and it will just cause clients to decline
the IP address that's being assigned to them (because they think it's
already in use).

Ping one of the addresses in the DHCP range that has not been assigned
to any device (try it from each side of the bridge with a different IP
address) and make sure you do not see any ARP relies in the ARP cache.
If you do see an ARP reply, whatever device replied is misconfigured.
See what other entries in the APR cache have the same MAC address and
you've found your culprit.

If this doesn't make sense to you, you're not qualified to maintain
this network.

DS

Thank you, I have found the device that is causing this problem. Now
it's time to figure out why it's doing that.