|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Cable Modem [really responsible engineering]
On Thu, 28 Jun 2001 15:48:42 -0400 (EDT) Greg A. Woods wrote: > Luckily not much of this thread has been polluting NANOG, so I'm not > 100% sure what your goal is here, but I will point out that: You restated my goal later in your message. In your words: "there are no doubt ways to cache this information and maybe even refresh a cache intelligently." That is exactly what we are after :) What is the best way to obtain this information? I have three goals for this information: 1) Customer traceability/accountability. For example, after the launch of a DDOS attack, child porn server, etc. Cable modems are attractive targets as launch pads. 2) Traffic accountability for statistical modeling, charging, etc. 3) Debug information. > The client-IP addresses active on any CPE interface of any cable modem > compliant with the DOCS-CABLE-DEVICE-MIB (rfc2669) can easily be > discovered with SNMP. > From there it's very simple to find the client > MAC in your dhcpd.leases file (though I don't know why the IP#s wouldn't > be sufficient for most needs). This doesn't help in a number of common cases. For example, most connectivity support problems manifest themselves as a failure to get an IP address from the DHCP server in the first place. Another example is tracing a MAC when a client, either through customer error (usual case) or malice, gets an IP not allocated by a valid DCHP server. So we really need to have that MAC in cases where the DHCP lease file can not be counted on for accurate information. > Note too that this same table should > also act as a filter to lock static addresses to a given modem if its > entries are assigned by the operator. Ick. > The only problem of course is that you've got to SNMP-scan all your > modems to find which customer's using a given IP# (I did that a couple > of times just this morning! ;-). There are no doubt ways to cache this > information, and maybe even refresh a cache intelligently. There may > even be a better, proprietary, way do do such searches in well > implemented head-end systems (doesn't seem to be in Terayon's though). Exactly. I found doing such scans got old years ago. Not to mention, it doesn't scale well :) Let n be number of customers, then finding a particular MAC is order O(n) where "O is something unsavory" because of individual queries of cable modems which may or may not time out... People turn the damn things off! Likewise, searching through different Cisco UBR tables to find which MAC was associated with which IP, then trying to painfully trace that MAC to a particular node, then customer, etc. really sucks.... Been there, done that, rotted out the tee shirt at the armpits. regards, fletcher
|