thousands of discovers from a single MAC

[Marc Perea]

Thanks for the replies!

>From: Alex Bligh <alex at alex.org.uk>
>If you just see (your side of the access shelf) DODODODO (and nothing else)
>this might simply be that connectivity is unidirectional (upstream
>only) between the access shelf and the customer - at least at an IP
>level. There's a million reasons why that could happen, including broken
>CPE.
A modem reboot fixes it, implying 2 way was available from access - indeed, we are looking hard at the CPE.
>From: "Ingen Schenau, Jeroen van (ICTS)"
>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"?
Nope, no sniffing capability - at least none that anyone at my company is aware of. It's possible (likely?) that the vendor engineers can turn that on, but we haven't been provided the privileged commands to do so. All they have available are counters representing TX/RX on the bridge interface that's converting ethernet frames from our core into ATM cells at the customer edge (and vice versa). The access vendor sees about a 1 counter / sec increment on both TX and RX while in this broken state, implying that it is passing traffic both ways (DISCOVER - OFFER) - and since it's a bridge, it _shouldn't_ be fussing with the data.

>Basic troubleshooting question, but are you only using one model of RG?
>Have you tried duplicating the behaviour with a RG from a different
>vendor?
For ease of troubleshooting and standardization, we actually do have only a single vendor for our RG. We are currently attempting to reproduce with other gear.
 
>And the Belkin router has its own DSL interface? Or is it connected to a
>RG in bridging mode?

I'm not aware of any Belkin ADSL equipment, so that particular customer must not have "upgraded" to our new modem that we sent him in L3 mode instead of L2.

>This sounds like a nasty and time-consuming problem...
 
Indeed. We just found out that one of our compulsive trouble circuits appears to have been fixed by removing a bridge-tap. Hmmm...

>From: Blake Hudson blake at ispn.net 
>The swap to bridging mode makes me think that it's something at the
>shelf (assuming it never happens in bridging mode and it's not a reset
>between modes that temporarily fixes the problem). Is your access shelf
>performing any type of DHCP secured ARP or similar IP spoofing
>protection or even bridged/routing against the CPE which could be
>interfering with the new DHCP transaction? Another thought would be DHCP
>transaction limits (flood protection) on the access shelf, or a device
>limit per access port that works via IP address instead of MAC.

The access shelf does offer several protections as well as option 82 insertion, but it's _almost_ a dead horse, we've beaten it so.
 
Anyway, thanks for the responses and ideas all! It sure is sounding like bad L1 or CPE, or both.
 
--Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110524/1f3aa4dd/attachment.html>