dhcpd capacity

Wed Nov 7 22:05:03 UTC 2007

Thanks for a suggestion. I'll try that (just need to wait for an
apropriate window to reset the network :-) ).

> So it sounds like it's really the DHCP server that's not responding in a
> timely fashion.
> 
> Have you tried setting up DHCP on a different box, just to eliminate that as
> a concern?
> 
> -----Original Message-----
> From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
> Of fadey
> Sent: Wednesday, November 07, 2007 2:46 AM
> To: dhcp-users at isc.org
> Subject: RE: dhcpd capacity
> 
> Yes, I did that. In a lot of cases a timeout occurs before a cable modem
> receives an OFFER (and so a new DISCOVER is being sent again). Sometimes
> an OFFER comes through, but again a timeout occurs before a cable modem
> manages to receive an ACK. So the process repeats over and over.
> Occasionally (aprox. once per 1-2 minute) some lucky cable modem manages
> to get all the info and come online. So in an hour or so the network is
> online again.
> What I currently do to coop with the problem is restart the dhcpd once
> per 8-10 seconds when the total reset occurs. That helps. Just after the
> reset a couple of cable modems get their info. So resetting speeds up
> the total network bootup to 20 minutes or so.
> 
> 
> 
> 
> > Have you turned on debugging on your CMTS to make see if the DHCP replies
> > are at least getting processed there?  Have you been telneted into your CM
> > on the LAN port side to see if it's getting the DHCP replies, or if there
> is
> > any more information?  Ideally you would have a DOCSIS protocol analyzer
> > from Sigtek.
> >
> > Frank
> >
> > -----Original Message-----
> > From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
> Behalf
> > Of fadey
> > Sent: Tuesday, November 06, 2007 6:06 PM
> > To: dhcp-users at isc.org
> > Subject: Re: dhcpd capacity
> >
> > Thanks for your reply
> > I've set
> > ping-check off;
> > in the config file. Also now I'm running dhcpd with
> > dhcpd -d -f 2>/dev/null (I guess this way it will not write to disk on
> > every request). Yet what I see from a tcpdump trace is that the
> > situation has not improved:
> >
> > 0:42:31.941360 IP 192.168.0.2.67 > 10.2.0.1.67: BOOTP/DHCP, Reply,
> > length: 328
> > 00:42:31.990506 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0f:21:e7:50:bd, length: 436
> > 00:42:32.055564 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:70, length: 512
> > 00:42:32.311609 IP 10.2.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:16:17:aa:82:7a, length: 320
> > 00:42:32.374133 IP 192.168.0.2.67 > 10.0.0.1.67: BOOTP/DHCP, Reply,
> > length: 300
> > 00:42:32.672425 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:64, length: 512
> > 00:42:32.779738 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:34, length: 512
> > 00:42:33.004367 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:44, length: 524
> > 00:42:33.108238 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:2c, length: 512
> > 00:42:33.281421 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1b:e8, length: 524
> > 00:42:33.621956 IP 192.168.0.2.67 > 10.0.0.1.67: BOOTP/DHCP, Reply,
> > length: 305
> > 00:42:33.711499 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:1c, length: 512
> > 00:42:33.904487 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:11:e6:f2:39:26, length: 424
> > 00:42:34.010164 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:11:e6:f2:3c:cc, length: 424
> > 00:42:34.037943 IP 192.168.0.2.67 > 10.0.0.1.67: BOOTP/DHCP, Reply,
> > length: 305
> > 00:42:34.070474 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:68, length: 512
> > 00:42:34.153420 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:44, length: 512
> > 00:42:34.194339 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:48, length: 524
> > 00:42:34.199977 IP 10.0.0.196.1055 > 192.168.0.2.69:  35 RRQ
> > "SA-EPX2203-VODA-BASICA.cfg" octet
> > 00:42:34.418991 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0f:21:e7:4f:db, length: 436
> > 00:42:34.444522 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0e:5c:a9:5e:a0, length: 523
> > 00:42:34.481865 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:11:e6:f1:eb:6a, length: 436
> > 00:42:34.649512 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0f:21:e7:51:99, length: 436
> > 00:42:34.696330 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:11:e6:f1:ea:ea, length: 424
> > 00:42:34.761267 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0e:5c:a9:5e:b2, length: 523
> > 00:42:34.985876 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:11:e6:f1:eb:74, length: 424
> > 00:42:35.099862 IP 192.168.0.2.67 > 10.2.0.1.67: BOOTP/DHCP, Reply,
> > length: 300
> > 00:42:35.233276 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0f:21:e7:4f:23, length: 436
> > 00:42:35.595500 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:78, length: 512
> > 00:42:35.702524 IP 10.2.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1a:22, length: 484
> > 00:42:35.818158 IP 10.2.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0e:5c:a6:68:7c, length: 300
> > 00:42:35.991982 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:0f:21:e7:50:bd, length: 436
> > 00:42:36.138845 IP 192.168.0.2.67 > 10.0.0.1.67: BOOTP/DHCP, Reply,
> > length: 300
> > 00:42:36.281502 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1b:e8, length: 524
> > 00:42:36.709991 IP 10.0.0.1.67 > 192.168.0.2.67: BOOTP/DHCP, Request
> > from 00:14:f8:8d:1c:5c, length: 512
> > 00:42:36.776847 IP 192.168.0.2.67 > 10.2.0.1.67: BOOTP/DHCP, Reply,
> > length: 329
> >
> >
> > Just wondering if anyone has experienced this before. I've got just 200
> > cable modems in my network. I guess there are networks MUCH bigger then
> > that which are using isc dhcpd
> >
> >
> > > fadey wrote:
> > >
> > > >I'm experiencing a problem with dhcpd in a cable network. Once cable
> > > >modems are reset (I have about 200), a storm of packets is flooding
> > > >dhcpd and it can't serve the networking  information to all of cable
> > > >modems at once. For about every 5 DISCOVERs I see 1 OFFER (with
> > > >tcpdump). So, I guess that either some OFFERSs are being dropped or by
> > > >the time they reach a cable modem a timeout opccurs.
> > > >I'm wondering if there is something in the configuration that can
> > > >influence the responce time of dhcpd.
> > >
> > > Check the archives, there's been a number of threads about server
> > > performance over the last few months. A few tips :
> > >
> > > ping-before-offer : you can turn this off
> > >
> > > logging : is syslog configured to write logs synchronously ? If so,
> > > then this slows things down quite a bit (every log created results in
> > > a disk write). Setting this to async helps quite a bit.
> > >
> > > Also, some people have experimented with putting various things on
> > > ram disk - but it may not be safe against reboots.
> > >
> > >
> > >
> >
> >
> >
> >
> 
> 
> 
> 