|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Cable Modem [really responsible engineering]
[ On Thursday, June 28, 2001 at 16:41:10 (-0400), Fletcher E Kittredge wrote: ] > Subject: Re: Cable Modem [really responsible engineering] > > 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. In the first case you should know the MAC and (private) IP of the modem. Go nuts -- it should be trivial to debug from there. In the second case you'll note that docsDevCpeTable normally contains a list of all the IP#s the cable modem sees on the CPE interface(s). Besides the customer "error" scenario our modems get 169.254/16 addresses stuck in them whenever some junior admin does something stupid (eg. to the DHCP server). It's really not that hard to find them all and clear them all out (and of course once you've done it once you'll have already written a script to automate it, right?). You do have your modems locked down enough that CPE devices can't send to or spoof as a source the private addresses you use for the modems themselves, don't you? > So we really need to have that MAC in cases where the DHCP lease file > can not be counted on for accurate information. I don't think you really need the MACs of devices beyond the CPE interfaces. If you think you do then I think you're attacking the problem(s) from the wrong direction. > 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! Remember what I said about caching and updating the cache? That's how you handle the scaling issue (and improve the realtime accessibility of the information too). This really isn't a difficult problem to solve. You should quit running around like a chicken with your head cut off and instead just sit down and look at what's already sitting in front of you. I haven't really looked very hard at what SNMP traps the modem can send, but there may even be useful update information available that way. -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <[email protected]> Planix, Inc. <[email protected]m>; Secrets of the Weird <[email protected]>
|