single dhcp server with multiple subnets

José Queiroz zekkerj at gmail.com
Mon Jul 28 23:10:27 UTC 2014


I agree with Glenn, it seems that you have some problem with vlan
assignment.
You can make a test on it. Assign an static address to your notebook, and
plug it to any port on vlan 8. Then run "arping" from your dhcp server (I'm
supposing its linux) searching for the notebook's address.

If your vlan assignment is correct, arping cannot get any response.
If arping get any response, then your notebook is still on the same vlan
from the dhcp server, and that's why you're getting wrong results.


2014-07-28 18:32 GMT-03:00 Senko, Mike <Mike.Senko at seattle.gov>:

> Thanks for the replies,
>
> I changed the router addresses Glenn pointed out in the 'option routers'
> sections,
> for network 10.7.1.0, the option router is now 10.1.7.2,
> 10.1.8.0 > 10.1.8.2, etc.
>
> the network:
>
> I have a router connected to two switches via trunk ports to each switch.
> I have the dhcp server on one switch, a laptop with dhcp client requests
> on another switch.
> All vlans are trunked to both switches.
> The switches and router uses a command to pass dhcp traffic through the
> network.
>
> here's the syslog output after initiation a dhcp request from the laptop:
>
> Jul 28 11:44:36 ruggedcom kernel: Shorewall:FORWARD:REJECT:IN=switch.0009
> OUT=switch.0001 MAC=00:0a:dc:db:f9:ff:00:1e:4c:00:3d:75:08:00:45:00:00:54
> SRC=10.1.9.189 DST=192.168.0.241 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=11761 SEQ=1
> Jul 28 11:45:01 ruggedcom /USR/SBIN/CRON[18493]: (root) CMD
> (/sbin/logreaper --all)
> Jul 28 11:45:36 ruggedcom kernel: Shorewall:FORWARD:REJECT:IN=switch.0009
> OUT=switch.0001 MAC=00:0a:dc:db:f9:ff:00:1e:4c:00:3d:75:08:00:45:00:00:54
> SRC=10.1.9.189 DST=192.168.0.241 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=11836 SEQ=1
> Jul 28 11:46:36 ruggedcom kernel: Shorewall:FORWARD:REJECT:IN=switch.0009
> OUT=switch.0001 MAC=00:0a:dc:db:f9:ff:00:1e:4c:00:3d:75:08:00:45:00:00:54
> SRC=10.1.9.189 DST=192.168.0.241 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=11912 SEQ=1
> Jul 28 11:48:06 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:48:07 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:48:09 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:48:09 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:48:16 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:48:16 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:48:33 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:48:33 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:48:40 TestLabPC mate-screensaver-dialog: pam_ecryptfs: seteuid
> error
> Jul 28 11:47:36 ruggedcom kernel: Shorewall:FORWARD:REJECT:IN=switch.0009
> OUT=switch.0001 MAC=00:0a:dc:db:f9:ff:00:1e:4c:00:3d:75:08:00:45:00:00:54
> SRC=10.1.9.189 DST=192.168.0.241 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=11987 SEQ=1
> Jul 28 11:49:05 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:49:05 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:49:08 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:49:08 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:49:16 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:49:16 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:49:32 TestLabPC dhcpd: DHCPDISCOVER from b4:b5:2f:29:d1:c9
> (SCL2304L) via 10.1.6.2
> Jul 28 11:49:32 TestLabPC dhcpd: DHCPOFFER on 10.1.6.200 to
> b4:b5:2f:29:d1:c9 (SCL2304L) via 10.1.6.2
> Jul 28 11:48:36 ruggedcom kernel: Shorewall:FORWARD:REJECT:IN=switch.0009
> OUT=switch.0001 MAC=00:0a:dc:db:f9:ff:00:1e:4c:00:3d:75:08:00:45:00:00:54
> SRC=10.1.9.189 DST=192.168.0.241 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=12064 SEQ=1
>
> The output from tcpdump, activity on port 67, nothing on port 68:
>
> mike at TestLabPC /etc/dhcp $ sudo tcpdump -i eth0 port 67
> [sudo] password for mike:
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:00:53.378085 IP 10.1.6.2.43408 > 10.1.6.56.bootps: BOOTP/DHCP, Request
> from b4:b5:2f:29:d1:c9 (oui Unknown), length 303
> 13:00:54.379236 IP 10.1.6.56.bootps > 10.1.6.2.bootps: BOOTP/DHCP, Reply,
> length 300
> 13:00:56.378359 IP 10.1.6.2.48011 > 10.1.6.56.bootps: BOOTP/DHCP, Request
> from b4:b5:2f:29:d1:c9 (oui Unknown), length 303
> 13:00:56.378526 IP 10.1.6.56.bootps > 10.1.6.2.bootps: BOOTP/DHCP, Reply,
> length 300
> 13:01:04.381092 IP 10.1.6.2.34942 > 10.1.6.56.bootps: BOOTP/DHCP, Request
> from b4:b5:2f:29:d1:c9 (oui Unknown), length 303
> 13:01:04.381282 IP 10.1.6.56.bootps > 10.1.6.2.bootps: BOOTP/DHCP, Reply,
> length 300
> 13:01:19.388927 IP 10.1.6.2.59166 > 10.1.6.56.bootps: BOOTP/DHCP, Request
> from b4:b5:2f:29:d1:c9 (oui Unknown), length 303
> 13:01:19.389125 IP 10.1.6.56.bootps > 10.1.6.2.bootps: BOOTP/DHCP, Reply,
> length 300
> ^C
> 8 packets captured
> 8 packets received by filter
> 0 packets dropped by kernel
> mike at TestLabPC /etc/dhcp $ sudo tcpdump -i eth0 port 68
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> ^C
> 0 packets captured
> 0 packets received by filter
> 0 packets dropped by kernel
>
>
>
> I've tried turning off DHCP Relay agent on both switches, then one or the
> other, no effect on the problem.
>
> If I connect the laptop to the same switch as the dhcp server switch,
> vlan6 (10.1.6.0/24), the laptop picks up the address 10.1.6.200 - as
> expected
> IF I the laptop is connected to and in the same vlan as the dhcp server.
>
> The dhcp server is in vlan 6, 10.1.6.56. If I connect the laptop to the
> same switch and in vlan 6, it works.
> If I move the laptop to vlan8 on the dhcp server switch, it does not get
> an address for vlan 8 - 10.1.8.0/24.
>
> If I move the laptop from the dhcp server switch onto the laptop switch,
> with vlan 6 configured on the laptop switch, it does not work, but I can
> ping across the switches and vlans (subnets).
>
> Mike
>
>
> -----Original Message-----
> From: dhcp-users-bounces at lists.isc.org [mailto:
> dhcp-users-bounces at lists.isc.org] On Behalf Of Glenn Satchell
> Sent: Friday, July 25, 2014 9:06 PM
> To: Users of ISC DHCP
> Subject: Re: single dhcp server with multiple subnets
>
> Hi Mike
>
> You don't need to do anything special to detect the subnets. The way you
> have it in your config file is correct. The dhcp-relay inserts the IP
> address of the interface where the request came in (GADDR), and the server
> then knows which subnet the request came from.
>
> My guess is that one of your relay devices (likely the switches) is
> putting the wrong info in the packet it forwards to the server.
>
> To check this have a look at the syslog files (/var/log/messages is a
> likely default place) and see what the relay device. It will be something
> via something. Perhaps post the log lines here,
>
> You could also run tcp dump, listening on udp ports 67 and 68 and see what
> options are set in the dhcp packets.
>
> Another possibility is that you have the different subnets all on the same
> physical network. If  so, then this is a shared-network, and any IP from
> the ranges would be ok. If so you need to wrap the subnet definitions in a
> shared-network statement. See the dhcpd.conf man page for the details.
>
> One other thing is that you also need to specify the correct IP on the
> local subnet for the router. This will never work because the client on
> 10.1.7.x does not know how to get to 10.1.6.2:
>
> subnet 10.1.7.0 netmask 255.255.255.0 {
>   option routers 10.1.6.2;
>
> Should be like this (or whatever the interface is on that subnet):
>   option routers 10.1.7.2;
>
> regards,
> -glenn
>
> On Sat, July 26, 2014 1:24 pm, Daniel Hoffmann wrote:
> > Greetings, Mike
> >
> > You could use classes in order to mach the correct subnet to the
> > requesting Client.
> > The Client does not know it's subnet, until it got an IP address.
> > For my own, i separate the classes depending on the relay address.
> >
> > Best regards,
> > Daniel
> >
> > Gesendet mit AquaMail für Android
> > http://www.aqua-mail.com
> >
> >
> > Am 26. Juli 2014 00:17:49 schrieb "Senko, Mike" <Mike.Senko at seattle.gov
> >:
> >
> >> I've gone through the archives, but haven't found a solution to using
> >> a single dhcp server to service multiple subnets.
> >>
> >> The subnets are set up on a router (non-cisco) that uses dhcp-relay
> >> to pass dhcp requests through the configured switch interfaces. The
> >> switches are layer 2 and also are configured for dhcp relay.
> >>
> >> The dhcp request packets show up at the server.
> >>
> >> The dhcp server then assigns and address and sends it to the router's
> >> address.
> >>
> >> The problem I've run into is the server is always sending the first
> >> dhcp address in the first configured subnet regardless of the subnet
> >> the request comes from.
> >>
> >> In other words, dhcp ip address assigned is always 10.1.6.200 even if
> >> the request comes from 10.1.8.0 subnet.
> >>
> >> If the dhcp request comes from the 10.1.6.0 subnet, all is fine.
> >>
> >> I think the problem is in the dhcp server configuration:
> >>
> >> option domain-name "TestLab.NSC";
> >> default-lease-time 600;
> >> max-lease-time 7200;
> >> authoritative;
> >> log-facility local7;
> >>
> >> subnet 10.1.6.0 netmask 255.255.255.0 { option routers 10.1.6.2;
> >> range 10.1.6.200 10.1.6.254; option subnet-mask 255.255.255.0; }
> >>
> >> subnet 10.1.7.0 netmask 255.255.255.0 { option routers 10.1.6.2;
> >> range 10.1.7.200 10.1.7.254; option subnet-mask 255.255.255.0; }
> >>
> >> subnet 10.1.8.0 netmask 255.255.255.0 { option routers 10.1.6.2;
> >> range 10.1.8.200 10.1.8.254; option subnet-mask 255.255.255.0; }
> >>
> >> subnet 10.1.9.0 netmask 255.255.255.0 { option routers 10.1.6.2;
> >> range 10.1.9.200 10.1.9.254; option subnet-mask 255.255.255.0; }
> >>
> >> subnet 10.1.5.0 netmask 255.255.255.0 { option routers 10.1.6.2;
> >> range 10.1.5.200 10.1.5.254; option subnet-mask 255.255.255.0; }
> >>
> >> This is the entire configuration, there must be something missing.
> >> I'm not using dns, just trying to get addresses assigned to the right
> >> vlan/subnet. The server is attached to 10.1.6.0/24.
> >>
> >> Thanks, ms
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20140728/5adf9d05/attachment-0001.html>


More information about the dhcp-users mailing list