[BusyBox] Cisco switches allergic to DHCP client "storm"

Brett Stewart brett.stewart at acumera.net
Thu Sep 4 10:48:47 UTC 2003


I chimed in on this too, and now I have something additional to report.

The initial behavior on the client appears to be allergic to a common
Cisco switch feature, or the other way around.  In any case, this
behavior of the client makes it difficult to get a lease when connected
to the DHCP server via certain Cisco switches unless the client port is
set to a nondefault mode on the Cisco box.

http://www.cisco.com/en/US/products/hw/switches/ps679/products_configuration_guide_chapter09186a008007ef24.html#xtocid25861

explains the 'Cisco spanning tree portfast' mode.  With the client
behaving the way it does, it cannot get a lease if connected via this
type of switch UNLESS this portfast mode is enabled.

I don't pretend to have a deep understanding of this, but another guy
who appears to understand it better than I do suggests that the
requirement to change these Cisco port modes arises from impatience on
the client side - in other words the opinion I heard was that if the
client were willing to wait slightly longer for the reply to the
DHCPDISCOVER, rather than repeating it quickly, or better yet, to not
even perform the DHCPDISCOVER until say 30 seconds after power up, the
default mode would work, and the ports would not have to be in this
'portfast' mode.

So, if anybody is planning to use these udhcpc clients in an enterprise
likely to have newer Cisco switches, it is probably worth filing away in
the back of your head that you might need to change the default behavior
of the Cisco box to get a lease.

I personally experienced this yesterday on one of our appliances, which
attempts to autonegotiate up to full duplex 10/100 with the other end of
it's link.  We could not get a lease until we set the port into this
'portfast' mode, at which point things began to work properly, or rather
to work as previously documented in this small 'dhcp storm' discussion
thread.

I heard the opinion that what was occuring was an unfortunate
interaction between ethernet phy autonegotiation, the cisco spanning
tree strategy, and this aberrant behavior of the udhcpc client. In any
case, enabling 'portfast' mode made the problem go away.  An additional
opinion was that if we waited longer (maybe 30 seconds!) after power-up,
the cisco/autonegotiation part of this unholy triad would have ended,
and things would have worked normally.

All this occurred at a customer site - we dont actually have at our site
a Cisco switch with this feature where we could hook up a sniffer and
dig into this in greater detail.  But someone on the list might.  And it
is probably better to get the udhcpc client to work with Cisco boxes in
default modes rather than require reconfiguration.

On Thu, 2003-09-04 at 00:27, Joshua Jackson wrote:
> On Tuesday 02 September 2003 3:02 am, Russ Dill wrote:
> > On Mon, 2003-09-01 at 22:24, Joshua Jackson wrote:
> > > Whenever the DHCP client goes to renew an address, I get the following in
> > > the system log.
> >
> > can you be more specific as to versions involed, actual lease times,
> > etc?
> 
> Yes and I should have known better... must have been really tired when I wrote 
> that :)
> 
> I am using the CVS code from just a couple of nights ago. It has been behaving 
> that way for quite some time with the 1.0-pre tree.  The lease time is set to 
> 7200 sec.
> 
> The log entries showed several proper lease renewals, but the initial attempt 
> to renew the lease was repeated several times in rapid succession.
> 
> The kernel is 2.4.21 with a full glibc 2.2.93.
> 
> Josh
> 
> _______________________________________________
> busybox mailing list
> busybox at mail.busybox.net
> http://busybox.net/mailman/listinfo/busybox
-- 
Brett Stewart <brett.stewart at acumera.net>
Acumera, Inc.




More information about the busybox mailing list