thousands of discovers from a single MAC

Ingen Schenau, Jeroen van (ICTS) j.vaningenschenau at
Fri May 20 16:16:02 UTC 2011

Hi Marc,

> I have a pretty strange scenario occurring that I don't expect to get
> any responses on, but it's worth a try and I can hope, right?
> Unfortunately, the access shelf is Ethernet on one side, ATM on the
> other, providing ADSL service to our customer, so we can't sniff
> between the shelf and the RG in order to determine who's causing the
> problem. 

So, if I understand correctly, the "access shelf" is the ADSL DSLAM
itself? And it doesn't provide any means of packet capture / debugging
on the DSL ports to verify "what comes in" and "what goes out"?

> Additionally, when we convert the RG which is doing both bridging and
> routing/NAT into two separate boxes, so that we can have an ethernet
> sniff point between them, it doesn't seem to break anymore.

Basic troubleshooting question, but are you only using one model of RG?
Have you tried duplicating the behaviour with a RG from a different

> Finally, a modem reboot will fix the problem - DORA will complete when
> the RG comes back up just fine. We also encouraged the RG vendor to
> develop and implement a firmware feature whereby if the modem sees a
> down/up on it's ATM interface (ADSL retrain), it would re-DHCP, much
> like an ethernet interface would. A down/up from the access shelf side
> does indeed also fix the problem.

So even though the RG doesn't currently re-DHCP upon retraining, forcing
a retrain from the DSLAM fixes the problem? That's weird... Still,
forcing the retrain might clear stuff on both sides, so it doesn't give
a definitive answer as to which side of the link causes the problem.

> We've had tickets open for every vendor from the edge to the core and
> haven't been able to isolate further than what I've explained here. A
> ticket remains open for the RG vendor, but it doesn't appear very
> promising now that I've also seen the problem occur on a Belkin router
> too.

And the Belkin router has its own DSL interface? Or is it connected to a
RG in bridging mode?

This sounds like a nasty and time-consuming problem... if you can't find
a means to do packet dumping between the access shelf and the RG/CPE,
the best way forward (imho) would be to do extended tests with various
RG/CPE combinations and, if possible, (lab) tests with other access
equipments or other software versions on your access gear.

In the past, we've had a nasty issue with Ethernet<->ATM on a box where
(iirc) specific broadcast packets were dropped going from the Ethernet
to ATM side. ARP still worked, but DHCP clients requesting a broadcast
response didn't receive the offers that our servers sent out. This
happened once every couple of months and when it started, it impacted
all DHCP customers that didn't have their CPE or client on 24/7. The
only workaround was to reload the switch doing the Ethernet<->ATM...


Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

More information about the dhcp-users mailing list