DHCP worked perfectly when I had a flat (one subnet) network. But now I've moved to a more structured and secure network design.

My Cisco router creates several VLANs on sub-interfaces to separate my server VLAN from my client VLANs. The idea is to not getting infected by the poor managed PC of my son. Although the network side works perfect I can not receive a DHCP managed IP address. To provide a better picture I'm posting some configuration details here:

Router:
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.249
description Simon's VLAN
encapsulation dot1Q 249
ip address 172.31.249.1 255.255.255.0
ip helper-address 172.31.254.10
!
interface FastEthernet0/0.254
description Server VLAN
encapsulation dot1Q 254
ip address 172.31.254.1 255.255.255.0

The router's FE0/0 is forming a VLAN trunk with the FE0/24 of a Catalyst2924:

Switch:
interface FastEthernet0/24
port network
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,249-255,1002-1005
switchport mode trunk

The Server is connected to switch port FE0/14:
interface FastEthernet0/14
description Debian Server
switchport access vlan 254
spanning-tree portfast

The DHCP-Client (WinXP) is connected to switch port FE0/2:
interface FastEthernet0/2
description Simon's PC
switchport access vlan 249
spanning-tree portfast

The Server's interface config (/etc/network/interfaces):
auto lo eth0 br0
iface lo inet loopback
iface eth0 inet manual
up ifconfig eth0 0.0.0.0 promisc up
iface br0 inet static
address 172.31.254.10
netmask 255.255.255.0
network 172.31.254.0
broadcast 172.31.254.255
gateway 172.31.254.1
bridge_ports eth0
bridge_fd 1
bridge_stp off
bridge_hello 1
down ifconfig br0 down

The Server's DHCP config (/etc/dhcp3/dhcpd.conf):
# Simon
shared-network Simon {
authoritative;
allow client-updates;
allow unknown-clients;
ddns-updates on;
# Simon's Data VLAN
subnet 172.31.249.0 netmask 255.255.255.0 {
authoritative;
option ntp-servers 172.31.249.1;
option domain-name-servers 172.31.254.10;
option broadcast-address 172.31.249.255;
option subnet-mask 255.255.255.0;
option routers 172.31.249.1;
allow client-updates;
allow unknown-clients;
ddns-updates on;
range 172.31.249.10 172.31.249.255;
}

So far so good...

Now, when requesting an IP address from subnet 172.31.249.0/24 the router picks up the request and forwards it to the server. By using the router gateway address 172.31.249.1 the server nows from where the request originated. The DHCP server takes an IP address from its 249-pool and sends the answer. However, it never arrives at the DHCP-client.

I already tried to solve the issue with dhcp-relay (usr/sbin/dhcrelay -i eth0 127.0.0.1) but it didn't help.
Here's the syslog:

Dec 28 19:16:42 mydebiansvr dhcpd: DHCPRELEASE of 172.31.249.17 from 00:07:50:ca:fb:bb (simon-dell) via br0 (found)
Dec 28 19:16:42 mydebiansvr dhcrelay: ignoring BOOTREQUEST with giaddr of 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcpd: DHCPDISCOVER from 00:07:50:ca:fb:bb via 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcpd: DHCPOFFER on 172.31.249.17 to 00:07:50:ca:fb:bb (simon-dell) via 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcrelay: packet to bogus giaddr 172.31.249.1.
Dec 28 19:16:42 mydebiansvr dhcrelay: ignoring BOOTREQUEST with giaddr of 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcpd: DHCPREQUEST for 172.31.249.17 (172.31.254.10) from 00:07:50:ca:fb:bb (simon-dell) via 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcpd: DHCPACK on 172.31.249.17 to 00:07:50:ca:fb:bb (simon-dell) via 172.31.249.1
Dec 28 19:16:42 mydebiansvr dhcrelay: packet to bogus giaddr 172.31.249.1.


Any idea or solution on hand?

Thanks, Simon

personally I would fire up a sniffer on the 249 subnet and take a look at the dhcp negotiation, view the request and response to see why it failed..
this would also verify that the router is passing the response back to the client.

Does your recommendation mean that at least on the Linux side everything is configured correctly and from that perspective you do not see why it doesn't work?

A simple soln would be to run the dhcp server off the cisco router. I would also not eat up a lot of cpu cycles.

If you want i can churn up the cisco configs for you.

Nitin

My recomendation means that by viewing exactly what is going across the wire (packet capture ethereal by chance ? ) it will be very apparent what is working and what is not.

If you see the DHCP request go from the workstation see if it is forwarded by the route to the other subnet.
did the DHCP server reply properly ? it did ?
OK did the reply get passed back through the router ?
OK did the workstation accept the Address it did ?
OH wait ANOTHER DHCP server from somewhere sent a NACK and told the PC NOT to use that IP ....

Just follow it a step at a time viewing both subnet and the progress of the DHCP negotiation.. basic network troubleshooting.

I've moved back from the idea of running DNS and DHCP server on my Linux box. Now these functions are provided again by my router for the different subnets (still 802.1q trunking).

Nitin, thanks for offering your help in writing the Cisco conf but I am able to do it on my own.

My Linux box is now just working as a file server and as an Asterisk PBX for VoIP (SIP) while my router provides DNS, DHCP, NTP, and Firewall (IDS/IPS) services.

Thanks again for your ideas.

Simon